Visual Studio 2005 February CTP
I have been working with the latest "publicly" available (that is, if you have an MSDN subscription) release of Visual Studio 2005.
There are some great new features, both in Visual Studio and in the .NET Framework 2.0. As a Visual Basic.NET developer (mostly), the feature that I like the most is that VB developers finally have access to build events.
I have been filing several bugs in recent days, but still, overall the product is workable. I have converted a major development project from VS 2003 to VS 2005. I did it mostly because I wanted to see how many changes would be necessary. It's manageable, and if you follow good coding practices, it shouldn't be a headache at all. Even ASP.NET projects seem to convert just fine. I was a bit worried about that, because there are significant architectural changes to ASP.NET.
The one thing that bugs me the most about the new VB.NET compiler is the warnings about using unassigned variables.
Take this example:
Dim obj As Object
If (Not obj Is Nothing) Then
obj.DoSomething()
End If
(Sorry, I have yet to figure out how to format code properly).
This will result in a compiler warning (error in C#, by default) because the object has not been assigned a value yet. It seems to me that this warning can be avoided, because that's exactly the scenario I am testing for. Of course, the code above would not make much sense in the first place. A similar scenario is where you check for an object reference in an exception handling routine, as in the case below:
Dim obj As Object
Try
obj = CreateObject()
obj.DoSomething()
Catch ex As Exception
throw ex
Finally
If (Not obj Is Nothing) Then
obj.Dispose()
End If
End Try
This case is valid, because it tests in the Finally clause for an object reference. It could be that the exception was thrown while the object was being initialized (by CreateObject() in this case, could be a constructor too).
The solution is to assign Nothing (null) to the object at declaration or somewhere else before you try to use it. Unfortunately, it seems that this solution can make matters worse. I hope a fix will be found for this before the final release.
BTW: This is bug #FDBK22915 in the MSDN Product Feedback Center.