Jason's Thoughts

I am a VB.NET developer, I have been for a long time thanks to my background with old VB3 and BASIC before that. However, I like C# and I use it whenever an opportunity arises but due to business requirements the primary language with both my last employer and my current employer is VB.NET. It shouldn't matter much though because, due to IL, the Framework library and the Common Language Runtime, both VB.NET and C# compile down to very similar results.

Sadly, the VB.NET developers experience differs from the C# developers experience even though they now share the same IDE. It seems more and more regularly that I find myself making the comment to my colleagues at work that some particular issue would be easier to deal with if we were using C#. Here are some that come to mind:

C# has the ternary operator (<condition> ? <trueresult> : <falseresult>). This is a minor difference but can simplify some otherwise verbose code. VB.NET has the IIF function but it always returns Object instead of the type of the result, thereby requiring a cast, and it is not short-circuited, making it less effective at avoiding NullReferenceExceptions. Apparently, in Orcas, the IIF function gets the same behaviour as C#'s ternary operator.

C# has automated refactoring included. Thankfully, Microsoft arranged for DevExpress to provide a free version of Refactor! for VB.NET so we don't miss out completely. Unfortunately, it doesn't completely bridge the gap. A notable omission is the "Generate Method Stub" refactor that C# includes.

At work, we are slowly adopting Unit Testing where we can to help detect issues sooner in the development cycle. Exposing your production code for unit testing also helps to refactor it for better maintainability. Sometimes you can't easily test internal code but luckily the framework includes the  InternalsVisibleToAttribute which can allow a separate (unit testing) project to call Friend/Internal methods in another project. You can apply this attribute to any VB or C# code but only the C# compiler looks for it meaning we would need to write our unit tests in C#. Again, apparently Orcas has updated the VB compiler to fully support this attribute to.

As well as adopting Unit Testing, we are trying to establish a Continuous Integration system to discover the full impact of changes as they are checked-in. Unfortunately, while the VB IDE is smart enough to infer references beyond the first level, the MsBuild tool used by most CI systems does not, and therefore all builds fail. We could manually add the second level references to each of our projects but any well-meaning developer who uses the Remove Unused References button will undo the hard work. C# requires the second level references to be specified for even the IDE build so it doesn't have this issue. Apparently Orcas changes the VB IDE behaviour to match C# and MsBuild.

VB doesn't completely lose out though. VB has background compilation which makes on-the-fly error detection and Intellisense much more productive. It can slow things down in large solutions and it tends to be the cause of most of the IDE's crashes but in C#, where there is no background compiling, it is sorely missed.

In Visual Studio 2003, VB was behind C# in other ways. The VB team at Microsoft ensured VB received all the missing bits in Visual Studio 2005, however the C# team bounded forward with even more features for C#, thereby still leaving VB behind. With Orcas in Beta 1, we can see that VB has caught up again with the features C# already had. And once again, C# in Orcas has even newer features.

No Sir, I don't like it.

My new home office machine has arrived and I am setting myself up for the most pain possible with my chosen configuration. Firstly I am installing Visual Studio 2005 on Vista Business Edition. Microsoft has only just released a patch for Visual Studio on Vista and it isn't perfect. Add to that running as a restricted user in Vista which introduces more problems. Finally I've chosen the 64-bit edition of Vista which complicates working with Visual Studio and software in general.

Reading the many articles and forum posts about problems with Vista and 64-bit will discourage most people from trying but so far I've found the experience to be quite pleasant. The first road-block is the need for new Vista 64-bit signed hardware drivers but Windows detected everything but the onboard sound and I was able to very easily find drivers on the HP web site for that. Two vital utilities, Daemon Tools and UltraMon, are already available with Vista x64 versions.

Vista has streamlined .zip file handling so I don't need any archiving software and the usual problems with new OS burning software are gone because Vista writes to CD and DVD out of the box. The small problem of burning disc images is solved by the free ISO Recorder, updated for Vista x64. I don't need MakeMeAdmin anymore because Vista's UAC temporary privilege elevation features have solved the problem. And, of course, Microsoft Office works beautifully.

I could rant for hours about the wonders of this new system but there were some issues. I managed to crash Visual Studio while setting the options for the first time but this is an easily avoidable documented issue (thanks Jim). I upgraded SQL Server 2005 to SP2 via Vista's built in AutoUpdate tool so I needed to run the User Provisioning Tool manually afterward to be able to connect. Also, a minor annoyance, Windows x64 has a separate Program Files folder for 32-bit and 64-bit applications and some installers were defaulting to the wrong folder.

I'm keeping a list of issues I encounter with Windows in general and developing with Visual Studio and SQL Server. I'll write about my experiences further on this blog as time passes and as I start pushing the boundaries of compatibility. At this point I have no regrets moving to Vista and 64-bit. I sure don't want to go back to either 32-bit or Windows XP and I'd recommend anyone with similar needs to my own to do the same.

At work we are currently developing a suite of applications that are expected to work on Windows XP and, I assume, eventually Windows Vista. The entire development team refreshed their workstations just after Vista went RTM and was available to MSDN subscribers. At the time Visual Studio 2005 wasn't fully supported in Vista and there were too many unknowns so an executive decision was made to stay with XP on the dev machines. I feel it was the right decision at the time.

However, there was one particular reason for staying with XP that I wasn't sure I could agree with. There was a concern that by developing under Vista we might lose touch with XP and find ourselves developing a product that has accidentally used facilities only available in Vista or that differ in Vista. The result, of course, is that we may lose compatibility with XP and discover the problem too late in development to solve it without large time, effort, or cost consequences.

I have decided to use my blog as a place of discussion for reasons why this concern is, or is not, valid. My bias is that the concern is unnecessary but I invite comments on anything I haven't considered.

Acceptance Testing

For each iteration of a product that we produce it goes to our testers to find bugs and usability issues before it can be considering for release. Our testers utilise a clean Windows XP environment inside Virtual PC to perform the suite of tests against the product. Any problems in our software that are specific to XP should be picked up here.

Visual Studio Limitations

Visual Studio 2005 was released well before Windows Vista was close to completion. As a result the IDE itself is not aware of any new features in Vista. In fact, it doesn't even fully support all the features introduced in Windows XP, one aspect that comes to mind is correct rendering of 32-bit icons. Any Vista specific features that are used will have be done so explicitly and presumably with prior consideration.

Framework 3.0

The new .NET Framework 3.0 features are included out of the box in Vista. Updates have been released for Visual Studio 2005 to provide project items and designers for the new WPF, WCF, and WWF components. However, just as we need to ensure that our XP clients need to install .NET Framework 2.0, version 3.0 is supported on XP and Server 2003, and is redistributable via the same methods as 2.0.

Features Lost

One of the primary focuses of Windows Vista has been to improve security. Many popular applications have required (or still require) an update to support Vista due to a change in the operating system's default behaviour. I believe there is a greater risk of utilising a Windows XP feature that will break under Vista because security has been tightened or the feature has been removed altogether (anyone still using WinHelp?).

Practice

With these points in mind I am in the process of building a Vista 64-bit development machine for the home office. With this configuration I intend to experience first hand what issues there are in terms of application compatibility and problems with the development process itself. Anything I find along the way that supports or disproves my beliefs above will help to decide when the development team should migrate to Vista, if at all.

If you have any experiences yourself with this situation I would appreciate your input.