in

ASP.NET Weblogs

Russell Pooley's .NET Blog

.NET Tools, Source and Research

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

Published Jul 30 2003, 08:45 AM by russell@vsdotnet.co.uk
Filed under:

Comments

 

TrackBack said:

July 30, 2003 5:32 AM
 

Brenton House said:

Here is another one I found a while back. It is called BabbelFisken and although it is not in English, the ui is easy enough to use.
http://w1.311.telia.com/~u31115556/desc/programs.htm#BabbelFisken
July 30, 2003 8:00 AM
 

Stephane Rodriguez said:


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.
July 31, 2003 2:56 PM
 

John Cavnar-Johnson said:

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.
July 31, 2003 3:08 PM
 

Eddy Recio said:

Just so you know, I recently got a glimpse at Whidbey, the next Visual Studio, at a local user's group I attend (Http://www.onetug.org). In either case the MS group responsible for VB showed up after VSLive (Orlando) and showed us the new IDE. At first glance I thought "Wow, these guys most have the latest laptops with Super insane hyper threading". The IDE opened up faster than MS Word on my 2.8 GHz Machine with 1G Ram. Then after the crowd was speechless the project manager says "Did anyone see that?"... he added " we have made many performance improvements on the IDE". And let me tell you VB was fast!!! I wont bore you with the rest of the demo, but be aware that the next version of VB will have some amazing language additions like the "My" namespace and great performance. This from a guy who is doing 60% C# and 40% VB. So until the next version convert away.
September 15, 2003 8:37 PM
 

George said:

I am looking for a tool to convert c# in vb.net project?
Do you know any?

January 7, 2004 10:42 AM
 

Beth said:

You may want to check this out:
http://www.panopticoncentral.net/PermaLink.aspx/8f42c52c-aa31-4829-8448-f7f6ed3a98d4

MSTF is offering to test your project with Whidbey so we can all benefit. FWIW, we do all of our enterprise development in VB.NET and I have not noticed a problem with VS-2003, though I may only have 999 classes ;-).
March 9, 2004 7:59 PM
 

Euan said:

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. :)
June 9, 2004 5:06 PM
 

Farore said:

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.
July 22, 2004 3:33 PM

Leave a Comment

(required)  
(optional)
(required)  
Add
Terms of Use