C# vs VB2005 new features

[MrPolite]

First off my apologies if a zillion threads are already around about this.
I'm not asking to compare the languages as a whole... I'm just wondering about the new features comparison.

Some new things were added to C# and some to vb.net. Which features specificly were added to C# and not vb.net, and vice versa?

[penagate]

Here is a complete comparison.

Specifically, point 7, which compares the new features in both languages in the 2005 versions.

[Shaggy Hiker]

Of the comparison of new features, I find number 8 to be the most interesting. It seems like this should allow for the creation of some interesting collection classes that can be strongly types at compile time. That's a feature I have often found lacking in 2003. Though you can get around it, I expect this will make for more intuitive constructs.

[kleinma]

Of the comparison of new features, I find number 8 to be the most interesting. It seems like this should allow for the creation of some interesting collection classes that can be strongly types at compile time. That's a feature I have often found lacking in 2003. Though you can get around it, I expect this will make for more intuitive constructs.

and faster code

[wossname]

As long as C# has pointers it will always be faster than VB Ohhhhhh soooo much faster.

[Shaggy Hiker]

Pooh!

However, if .NET2005 is significantly faster, that would be interesting. I hadn't heard that.

How difficult will the upgrade be? If I have a smallish program (a few thousand lines) in VB2003, how tough would it be to move to 2005? There is no DB work associated with this, it is nothing but forms, classes, and code. However, it is a model, and the last test I ran took a bit over four days to complete. When your runtime is measured at over 50 hours, a ten percent performance boost would be excellent.

Now, before anybody tells me to switch to C++, let me just say that I'm not going to do it. No change will bring 50 hours down to 50 minutes. In fact, if the conversion to 2005 requires a change similar to the change from VB6 to VB.NET, I'm not going to do that either. However, if the change is as simple as installing 2005, and opening the project in 2005 (with a few minor tweaks), then I'd do it for a performance boost.....or a tasty fish.

[kleinma]

conversion should be pretty minimal, just open the sln file in 2005 and it will warn you its an OLDER .net solution, but will open it and give you anything that may need to be changed to work in 2005.

Its nothing like moving a VB6 app to .NET

There may be SOME work involved, but if its a pretty small app you could probably have it up and running in 2005 in no time.

You may at some point recode some parts that you may have done one way, that there is now a faster/more efficient way to do it in the new 2005 syntax/classes

[Shaggy Hiker]

Good, I'll probably make the change. I'm not sure that any of the 2005 changes in syntax will make a difference for this, it's pretty tight as it is....except for that one bug I haven't tracked down yet.

[MrPolite]

well in my case (using the beta) I found out that conversion wasnt THAT straight forward. I have a 32000 line project btw
everything got converted fine, but there were many other issues popping up every now and then, and those related to changes to the framework. I really cant remember any of the issues except the threading issue. I was accessing the main form's controls from another thread and apparently cross threaded operations are not allowed in .NET 2.0.
I didnt get any warnings during the conversion so the only way for me to find out about it was to actually see the error in action

[jmcilhinney]

well in my case (using the beta) I found out that conversion wasnt THAT straight forward. I have a 32000 line project btw
everything got converted fine, but there were many other issues popping up every now and then, and those related to changes to the framework. I really cant remember any of the issues except the threading issue. I was accessing the main form's controls from another thread and apparently cross threaded operations are not allowed in .NET 2.0.
I didnt get any warnings during the conversion so the only way for me to find out about it was to actually see the error in action

Not to criticise because almost everyone would be in the same boat, but that is because VS.NET 2003 allowed you to get away with things that you shouldn't have been doing. Calling control members was never a thread-safe operation, but VS.NET 2003 just let you get away with it. Isn't that the sort of thing that VB always gets criticised for: allowing lax practices. VS 2005 will also warn you if you access a Shared or Enumerated member via an instance, which previously went by without fanfare. Properly written code will upgrade without issue in the vast majority of cases, but you'll () all be guilty of having imperfect code in some instances.

[Shaggy Hiker]

However, it appears that you can properly access shared members via the MyClass keyword in an instance.

[jmcilhinney]

MyClass is a slighly different kettle of fish. MyClass is supposed to be used to call methods of base classes that have been overridden in derived classes. It provides access to Shared members so that you can access the base implementation of a member from within an instance of a derived class. MyClass does not really refer to an instance in itself because even if you were to cast an object to its base class, calling an overridden member would still call the derived class's implementation, so it is a special case.

[Shaggy Hiker]

I have never used it, but it appears I may have been misled by my reading of the link posted by penagate.