VB.NET enterprise development whims and code conversion

If anyone is attempting to create an enterprise system in VB.NET, or thinking about, then let me tell you this, DON'T. After creating an enterprise project consisting of over 1000 classes, VB.NET is beginning to look a little weak Now you may ask whats the problem with VB.NET or may come to the conclusion that I'm one of those developers that are anti VB, well I'm not. I like VB and C#, they both have there strengths and weaknesses but when it comes to enterprise development I believe Microsoft made a big mistake with the IDE for VB.

The biggest problem with using VB for large projects is the IDE insists on checking your code for any errors as you type (Background code compilation), now this is great for checking for errors before compile time but the problems come when your projects reach a significant size for the background compilation to gradually slow down your productivity. We have a core data access layer which I believe is quite complex and if we wish to add a new method to any class within the project it will take approximately 30 seconds for the cursor to allow any typing after pressing the return key.

Now I must say I wasn't happy with this so I contacted Microsoft regarding the problem through my MSDN account, they acknowledged it as a bug and I therefore assumed that it would be fixed in Visual Studio .NET 2003 (Everett), after receiving the CD's for the Everett beta I tried the same projects on that. Admittedly it was quicker, but it was still as far as I was concerned too slow, Microsoft logged this same problem as a bug on Everett and after speaking to Microsoft again they said the problem with the background compilation was too deep rooted into the IDE that the possibility of being able to switch it off would not be possible, so the bug still stands in the release of Visual Studio .NET 2003.

Now my day consists of avoiding my VB.NET projects like the plague, I was unhappy, I wanted C# code. Easy I'll just convert it!!!!!!

So my journey began to look into VB.NET to C# code converters and I ended up building a resource of links that I thought would be of some use, they weren’t to me since the majority of the tools that were freely available didn't seem to perform particularly well. I found two commercial applications that claimed to convert the code and since trial versions weren't available it was quite hard to tell what they will do until I stumbled upon a Japanese web site that claimed to have a VB.NET to C# converter for free, called strangely enough VBCS (the same name as the commercial application produced by www.immunicode.com ).

After downloading and running the converter, which currently is at version 1.1 it became obvious the application was built for the Japanese as there are no English instructions for it, and the user interface is for a Japanese culture but it is pretty simple to use.

Does it work? This was my biggest test and surprisingly it does very well, it’s probably the best converter I have seen so far and I will be using it for converting any of my VB code to C#, so my tip for today is if you need to convert VB.NET code then check this tool out as it really does work and its free.

Japanese free VBCS
ImmuniCode VBCS
CodeProject GBVB


  • Not sure if this will help, but I also had this problem with large C++ workspaces. In fact, that was the .ncb file and .opt files which were growing like crazy. A few megabytes. As soon as I decided to erase them, everything returned to normal, that is fast and with no sleep time. I know erase those files from time to time. I of course lose my breakpoints along the way, but why should I care such a detail.

  • Why do you equate a project with 1000 classes with enterprise development? I've designed enterprise applications for years and I've never had a need for a project with anywhere near 1000 classes. In fact, in my experience reviewing architectures of existing applications, a high ratio of classes to deployment units (DLLs, Assemblies, is usually, but not always, indicative of a poorly designed application. Although there are times when I wish I could turn off the IDE's background compilation, on the whole, I like the feature.

  • I am looking for a tool to convert c# in vb.net project?

    Do you know any?

  • Enterprise?

    I ported a small-ish serial protocol test app, that had arrays of controls. About 120 buttons, 240 labels, and 120 text boxes, plus about another 40 standard vb6 controls. After fixing the 300 on_changed event handlers for the stupid "is initialising" flag, and some unicode to asci conversion it compiles and runs. However it now takes 30 seconds to load (used to be 5 seconds) a

    1 MB config file, and it runs can easily see the app drawing the controls sequentially (usually only 20 of the array are present at any one time.

    Now the great part is, if I decide to modify the project simply clicking on the form design window causes the IDE to disapear in to a world of it's own. It takes about 1 minute to display the design form. If I click on a control the cursor goes crazy, and after about 4 minutes the default event handler code appears. Even if I don't use it. Stupid. Buggy. Broken. Useless.

    PS yes there are better ways than arrays of controls, but it was easy, and quick in VB6. :)

  • A 1MB config file may be insane. If it comes down to it it I may suggest alternative configuration methods.

    One method I like is to create a settings structure, and serialize-deserialize it to a file. Binary loading should be faster than plain text XML and smaller even. It's more fragile than XML though, but often that's our trade-off.

    If you bother to use the manual offset attributes for structures you can reduce the fragility for a complexity increase.

    Note sure why the GUI elements are acting as they are.

Comments have been disabled for this content.