VB Developers that came from VB6...

[hellswraith]

I have been doing a huge conversion project on a VB.Net app to C#. Yes I know, there isn't much functional difference, but we are standardizing this project before we go further.

While porting, I have been finding things like this:

        If e.KeyCode = 46 Then
            'Do something...
        End If

That was obviously from a old VB6 programmer bringing their old habbits to .Net. Look at the readability of it. Instead do this for readablity and (possibly in the future) portability.

        If e.KeyCode = Keys.Delete Then
            'Do something...
        End If

I find things like this everywhere. Another example is 'vbCrLf'. Use the Environment.Newline in your code in place of that. It helps readability, and again, if they ever ported the framework, you would know that your code is calling a .Net framework class, which should be ported correctly instead of some obscure thing that may not be related on another system. I know this is a big if, but just look at the readablity of it, that alone is the biggest reason.

Sorry for the rant, I am just pretty frustrated at the moment, and thought I would share what the other side of the fence feels sometimes.

Just to note, I am a VB.Net/C# developer, so I have no biases against VB developers, I just don't like the habbits that are carried over from VB6.

[nemaroller]

ah... the most prevelant being

Msgbox("something")

I'll open some project and find a reference to VisualBasic runtime... and then you have to remove the reference, and see where it breaks..

[Edneeis]

I'm all for readability and using native .NET but I think its a misconception that Msgbox and similiar items somehow aren't using the .NET framework. Calling Msgbox does not create any dependencies that are not included in the Framework. There is no hidden call to the VB6 runtimes just because the syntax is the same. It does use the VB Compatibility namespace but that is still part of the .NET Framework. Syntax is what differentiates a language. This does not resolve the issue of porting to C# but I doubt that C# programmers are not using things specific to C# (like With or xml documentation). I'm really not trying to cause a stink or anything just representing a difference of opinion.

[hellswraith]

Originally posted by Edneeis
I'm all for readability and using native .NET but I think its a misconception that Msgbox and similiar items somehow aren't using the .NET framework. Calling Msgbox does not create any dependencies that are not included in the Framework. There is no hidden call to the VB6 runtimes just because the syntax is the same. It does use the VB Compatibility namespace but that is still part of the .NET Framework. Syntax is what differentiates a language. This does not resolve the issue of porting to C# but I doubt that C# programmers are not using things specific to C# (like With or xml documentation). I'm really not trying to cause a stink or anything just representing a difference of opinion.

I understand that the languages are different. Don't get me wrong, I am not complaining about that at all. When using VB, our standard is to use the With/End With feature if we can. In C# it doesn't exist. But what does exist in C# is the using keyword to dispose of a resource when you are done with it right away. VB.Net doesn't have that. It is give and take with both languages.

What I am mad about was the readability, and just the lack of trying to understand the other parts of the framework. With this post, I was just trying to show that there are alternatives to the vb6 ways in .Net, and to look out for them because they may help readability, and if it EVER happens, possibly portability.

[nemaroller]

Originally posted by Edneeis
Calling Msgbox does not create any dependencies that are not included in the Framework. There is no hidden call to the VB6 runtimes just because the syntax is the same. It does use the VB Compatibility namespace but that is still part of the .NET Framework. .

All good points Ednessis.

The question to me is IF and WHEN .Net ports to Unix/Linux platforms, will anyone bother porting the VB Compatibility namespace, whose sole purpose was to help VB6 programmers move to .Net.

To me it seems a temporary and transitionary library that was added because VB6 programmers complained on how much VB changed.

Same with the VB6 File commands in .Net, when they should be using the System.IO library (which sparked a whole internet buzz of VB.Net performing poorly on IO compared to C#, because the .Net newbies were using 'VB6 compatible' file functions instead of system.io).

[wossname]

Left$() Left()
Len()
on error goto...resume next
Gosub (ptoooiieee!)


Jesus, how did we ever manage?

[MrNorth]

Anyone that has a link to a page which list most of these standard "faults" made by old vb6 programmers?

And also not to forget that an integer in vb6 and an integer in vb.net isn't the same thing... its a short, right?


The reason Im asking is that I *shame on me* used "&vbcrlf" in a project today... Im aware of allthe other things you have metioned, like string ops, IO, msgbox etc etc


kind regards
Henrik

[Andy]

if you're pretty new to most of this in general, how do you know when you are using an old vb6 command? I have a post that I asked about strconv(). I think that's an old vb6 command, right? Does the namespace system.visualbasic make it automaticaly vb6?

And, is it considered acceptible to use vb6 commands when one doesn't exist in .net? (such as the strconv, of which I didn't find a .net equivalent)?

[MrNorth]

Well most of the commands one learned when migrating from vb6 to vb.net, like string class instead of the old len(), Ucase(), instr() etc etc... The reason I was interested in a list was that it would be interesting to see if there was anything one might have missed...

Like hellswraith I have to spend a few hours on every project correcting mistakes made by programmers who have not used vb.net more than a few months.. I see vb6 commands all over the place... and we have some "common practicies" that forbid the use of vb6 commands in all vb.net apps we develop (an effort from our boss to force our devs to learn vb.net)

I have read lots of books on vb.net and asp.net and nowhere I have read about the replacement for &vbcrlf Guess it must have fallen between the cracks...


kind regards
henrik

[Andy]

yeah, my bosss too said "no vb6 stuff, Only native .net!!" I also have read TONS of books on vb.net and haven't seen that about vbcrlf. I personally like environment.newline easier to understand .

If you find a list, I'd like a copy of it

[techgnome]

Originally posted by Andy
if you're pretty new to most of this in general, how do you know when you are using an old vb6 command? I have a post that I asked about strconv(). I think that's an old vb6 command, right? Does the namespace system.visualbasic make it automaticaly vb6?

And, is it considered acceptible to use vb6 commands when one doesn't exist in .net? (such as the strconv, of which I didn't find a .net equivalent)?

I *think* but not 100% sure but it's, myvariable.tostring

TG

[Edneeis]

Ooppps I meant Using not With. My intent for posting wasn't to say anything against the original post more to present another part to it. I think (and I could be wrong) that it is a misconception that the VB Compatiblity classes offer worse performance or are some how not native .NET. The differences between the .NET languages has to be with their intended purpose and finding the best syntax for that purpose. C# is meant for more Enterprise Framework development, the real meat, and VB was made for RAD, putting it out there fast. I think the Compatiblity namespace fits in this intent. If the Framework ever gets completely ported I don't see any of that being helped along by Microsoft. In fact I can only see incentive for them to not port to Linux. I mean right now the fact that you are developing in .NET means that the end user must have a Microsoft OS, and a newer one at that, which builds dependency on more Microsoft products. I'm also sure that they are making more money on the OS then on the Dev Tools. If you take away this need for a Microsoft OS then they could be pouring money into Dev Tools just so you can write better Linux apps and I don't see that happening. Also if Microsoft doesn't get involved in the port then it will always be far behind the current version of the Framework. So by time Mono gets to Framework 1.0 then MS will be on 1.3 and all your code written for 1.3 probably wont be backwards compatible with 1.0. So I don't see the Compatiblity namespace really needing to go away for some reason. In fact from what I've seen of Whidbey VB.NET looks more like VB6 (in IDE features not syntax). Of course this is all just my personal opinion and as such isn't really worth much but I'm just saying write 'more .NET like' code for readability or because the syntax is better (this is my reason) not because it is some how worse code.

[Edneeis]

Actually after further investigation I retract some or most of what I said. I don't know for sure that the code generated by the Compatibility namespace is bad per say and it is still .NET or compiled to IL but it is a hell of a lot MORE IL code than using the more 'native' namespaces. In fact about twice as much and twice that stack space. Oh well I've been wrong before and I'll be wrong again although I'm still not holding my breath for a Linux .NET Framework (although it'd be nice).

[nemaroller]

That's alright Edneesis, you've been right about a whole bunch of other things

As a sideways venture from the original topic, I think Microsoft will need to more acceptance to compete with Java, and that means seeing .Net running on other platforms.

As of right now, they may not be financially helping the mono project, but from reading the mono logs, it appears its mostly Windows developers porting the framework, and much of the outside help comes from employed MS employees who worked on the framework.

Whether or not 'executive MS' wants it, the framework will see its way over... because the developers want it. Heck, even Novell is helping the cause.

[hellswraith]

Originally posted by Edneeis
Actually after further investigation I retract some or most of what I said. I don't know for sure that the code generated by the Compatibility namespace is bad per say and it is still .NET or compiled to IL but it is a hell of a lot MORE IL code than using the more 'native' namespaces. In fact about twice as much and twice that stack space. Oh well I've been wrong before and I'll be wrong again although I'm still not holding my breath for a Linux .NET Framework (although it'd be nice).

I have always thought there was more going on under the hood with those methods. At the very least you are adding another layer to the call stack because the namespace in turn calls a native .Net class (in the System namespace).

[Andy]

so, to sum it up, VB.net is simply a tool to get something created quickly. And, while it DOES a good job of solving problems, a serious developer would use c# or c++? Is that the moral here?



I enjoy VB very much but I'm wanting to take my skills to a higher level. Problem is, I enjoy the GUI presentation of VB. Is this kept with VC++ and c#? I haven't done any REAL work with those two (yet).

And, to keep this thread on topic, if a project is intended for long-term use, should c# of c++ be used in the beginning?

[nemaroller]

C# will not gain you any more performance. Don't be mistaken. It does offer better support for unmanaged code, that does not make it better.

C++ will. But good luck with pumping out an enterprise application in a couple weeks with that.

We have developed a $20,000 (base, $2k per additional client) enterprise web application using VB.Net.

So you tell me its not a serious development language.

[hellswraith]

This thread is quickly becoming a debate about VB vs C#. That isn't what this is about.

I was just trying to remind people who are migrating to .Net that the framework is vast, and offers a lot. Some of it offers readability to you development. As Edeenis mentioned, using the VB namespace produces more IL than native System namespace calls. This should also be taken into account when you are developing your applications.

VB.Net can do 99% of what C# can do, and C# can do 99% of what VB.Net can do. It works both ways. Both have features that are not present in the other.

The best thing from my perspective is that C# salaries tend to be higher than VB.Net, but that isn't because of functionality.

[MikkyThomeon]

BTW: I think there is an experimental open source Limux project that aims to create an implementation of .Net on Linux...

I can't remember what its name was. Anybody know about this..?

[hellswraith]

It is the Mono project..
http://www.go-mono.org/