VB.NET - BUGS    

The following is a list of bugs, quarks, and behaviors that I found while working with VB.NET v1.1 (Visual Studio 2003).  Microsoft or others may say that these things are "features" or "enhancements" to previous versions of VB.   However, after programming with VB 5 & 6 for seven years I found that these things are annoying, confusing, frustrating, slow me down, or get in my way in some way or another.

    = This is a BUG!
    = This is functionality or a feature that SHOULD be there
    = Could this be user preference, or something new to learn... maybe.

     

Bug Name: Bug Description: What This Means:
VS.NET IDE crashes if you try to add an ICON to the .EXE If you select your project in the "Solution Explorer" window, then go to the "Project" menu and select the "Properties" menu item, the Project Property Page will come up.  If you select the "Build" item under the "Common Properties" section... you'll see an "Application Icon" drop down with a button (with the caption set to "...") next to it.  If you click the button to browse for an ICON, then select a valid ICON file and click the "Open" button... the entire IDE crashes. What this means is that if you don't know how to get around this, you may loose some of your work, and you will definately get frustrated with the IDE bombing on you

The work around for this is to add the ICON file to your project as a file, then select it from the drop-down list.  But you wouldn't think to do that unless you were guessing (which is what I was doing trying to figure this problem out).
No run-time "on the fly editing" allowed with VB.NET You can't pause the execution of your program at run-time, edit your code, and continue. VB.NET forces you to either ignore the changes you made and continue, or restart the program!  This is a step backwards with VB if you ask me.

I've heard that Microsoft has said that they will come out with a version that allows you to do this at a later date... WE'LL SEE.

 What this means is that if you're in the middle of a very complex process or function, and you spot a bug that will throw your program off or crash your application, you can't just pause the execution, fix it, and continue... like you CAN in Visual Basic 5 and 6.  This means you'll be wasting time stopping and starting your program to edit problems as you find them in your code at run-time.
Splitting the code window causes all #REGION's to collapse If you're in the middle of coding and you'd like to refer to another section of your code, you can split the code window by grabbing and dragging the little button above the code window vertical scroll bar.  The problem is, when you do this, all of your code contained within any #REGION collapses automatically. This makes you loose your place in the code and costs you more time looking for where you were and getting back into what you were doing.
Copy/Paste doesn't work within JavaScript blocks in HTML pages If you are in a JavaScript block within an HTML/ASP page and you copy and paste... you will be kicked out of the JavaScript block and thrown down to another part of the page instead... making Copy/Paste functionality useless within web pages Ugh!  Bug... quick get it... before it starts to multiply.
VB.NET forces you to go to the default event code when you double click on a Form or control, even when you don't want to In Visual Basic 5 and 6, if you double click on the Form or any other control for the first time, it would bring you to the "Default Event" which is "Load" for the Form, and "Click" for most controls.  However, if you were to put code behind another event like "KeyDown" and delete the default event code that was created for you when you first double clicked on it... then double click on the Form or control again, it brings you to the newly created event, NOT the default. This makes sense because if you never use the "Click" event but always use the "KeyDown" event, you don't want to be forced to constantly delete event code you'll never use and then find your way manually to the one you will.

In VB.NET, double clicking on a Form or control will ALWAYS bring you to the default event... even if you have code behind other events and never use the default event!

 This bug makes getting at the code behind the interface in VB.NET time consuming.

Time is money.

Ironically, Microsoft's biggest push for VS.NET is that it will save you SO MUCH time.  Heh... I wonder if the marketing guys that came up with that have ever tried to program anything with VS.NET.
Cut & Paste doesn't quite work right When you past multiple lines of text into the code window, it will put your cursor at the BEGINNING of the last line, instead of at the end like every other Windows application (including VB5 & VB6) does. If you're in a hurry and do a quick cut/paste into the IDE and then hit enter a few times and start typing... the last line of your cut/paste will be stuck behind your cursor.  Not the functionality you'd expect.
IDE does not correctly handle strings with NULL characters When you have a string that contains NULL characthers ( vbNullChar ), intellisense shows the value of the string ONLY up to where that NULL character is.  It clips the rest.  So if you have a NULL character as the first character of 100 characters in a string... intellisense will show the string's value as BLANK ( vbNullString ) when it should represent the vbNullChar as a BLOCK character in intellisense (just like in VB5 and VB6).

Also, if you call Debug.WriteLine(YourString) and YourString contains vbNullChar as the first character of 100 characters... the Immediate window will show the value of YourString as being a BLANK string ( vbNullString )... which is incorrect.   It should represent vbNullChar as a SPACE (just like it does in VB5 and VB6)

 Because of this functionality, during debugging you may think that your string variables have be misassigned or messed un when in fact it has not... the IDE is simply reporting false values.
VB.NET makes finding things EXTREMELY hard With VB.NET as it stands now, there are usually many ways to accomplish a single task and they are all buried within some object where you'd never expect it.  For example, if you want to get the current application's Major Version number, you have to call the following:

intMajor = System.Reflection.
Assembly.GetExecutingAssembly.
GetName.Version.Major

With Visual Basic 5 and 6, all you have to do is call the following:

intMajor = App.Major
 

Having everything buried under so many layers and objects is the SINGLE BIGGEST problem I have with VB.NET!!   It makes everything very hard to find, and makes VB.NET very frustrating to work with.  I spend 35% of my time hunting for the objects and interfaces I need, and the other 65% coding with them once found.
Forms FREEZE when in debug mode When you debug your code and are stepping through it... any open Forms are FROZEN and can't be moved, can't be refreshed, can't be minimized... nothing!  They just sit there in your way so you can't see your code as your debugging it. What this means is that you will have a hard time debugging code behind Forms.

The reason this happens is the .NET environment HEAVILY sub-classes that form (in order to offer all the "cool new features" that Windows Forms offer in .NET), and when you debug a form that is subclasses in VB5, VB6, or VB.NET... you can't do anything to that form... it freezes.
VB.NET makes working with GDI API's and objects hard The "System.Drawing.Font" object has a "ToHfont" method that returns a handle to the font, and a "ToLogFont" method that returns a GDI or GDI+ "LOGFONT" structure.  This is very handy when working with Win32 API calls.

However, the "System.Drawing.Brush" object doesn't have a "ToHbrush" or "ToLogBrush" method.

The "System.Drawing.Pen" object doesn't have a "ToHpen" or "ToLogPen" method.

The "System.Drawing.Imaging.ColorPalette" object does not have a "ToHpalette" or "ToLogPalette" method.

 This makes working with Win32 API's that deal with Brush, Pen, or Palette objects within VB.NET very hard if not impossible

Inconsistencies are no fun to work with.

However, compatibility to the old style Win32 GDI is not what VS.NET is going for.  They want you to use GDI+ 100% of the time.  It's newer... it's better... or so they say.  However, I'm sure I'm not alone when I say I don't want to rewrite every line of existing code that deals with the old Win32 GDI interface.
VB.NET makes working with complex API's  hard or impossible .NET wants to get you away from the Win32 API's and get you onto the CLR code instead.  The problem with this is the CLR does not always make accessing the data or Windows information you need easy or even possible in some cases.  So you go to make a good ol' Win32 API call to get the data as you have in the days of VB5 and VB6.  However, .NET does not support certain things required to make some of the more complex API calls... like fixed length strings within structures (very common in the Win32 API).  So what can you do?!   I have no idea.  I've tried <STRING>.PadLeft and <STRING>.PadRight and they don't work.  I've tried passing a byte array with the correct size instead of a structure and had a little success, but not much (no work around to be found there). All you can do is simply cross your fingers and hope that you never need to make any complex Win32 API calls to get the data or information you need.  And if you do, hope that Microsoft has a CLR equivalent... and if they don't... pray someone else has found a workaround to get the data or information you need.
MouseDown event eats the DoubleClick event The problem is that the first click of a double click may be caught by the datagrid (and used to activate the cell) while the second click goes to the TextBox for the columnstyle object. This means the TextBox thinks this is a singleclick, and does not fire its doubleclick event. One solution is to mark the time of the click caught by the datagrid. Then look at this time in the TextBox's mousedown handler to see if in fact the single click being looked at by the TextBox is part of a double click. You can download a sample (C#, VB) that illustrates how this might be done. This is simply incorrect functionality and may cause problems when working with a DataGrid.

Thanks for reporting this one, Onno.

(See Also: Windows Forms FAQ)
VB.NET makes #REGION's a good thing and a bad thing. #REGION's can be a good thing to help you organize, label, and compress your code in the IDE.  However, if you have #REGION's defined in your code and they are collapsed and you search for text... the collapsed regions are NOT searched unless you check "Search hidden text". That check box should be checked by default if nothing less.  If you're not careful, you could get false results from your search.
No more "Default" and "Cancel" events means trouble! The "Default" and "Cancel" properties that VB programmers are so familiar with are now GONE!  Microsoft thought it would be a good idea to move them I never thought to look.  I only found them by accident, and they act completely different.   "Default" has been changed from a property on the button, to a property called "AcceptButton" on the form.  "Cancel" has been changed from a property on the button, to a property called "CancelButton" on the form.   They think this was a good idea, I don't. Again... you don't want to make your development environment difficult to get around in.  Hiding functions, properties, and methods that are familiar to VB5 and VB6 programmers simply makes the VB.NET experience frustrating.
VB.NET doesn't have the ability to jump from function to function like VB5 and VB6 You can't press <CTRL> + <Up Arrow> or <CTRL> + <Pg Up> to jump from one Function or Sub to the next.  I use that ALL THE TIME to get around in my code. Taking that away forces me to scroll... scroll... scroll, or stop what I'm doing and fish through the object drop-downs to find the right function.  Such fun!
Indenting If...Then statements doesn't work quite right. If you are in the middle of a nested IF, or some other kind of statements that indent your code to the right... then type "If 1 = 1 Then" and press the DOWN ARROW (not ENTER)... it shifts your nested statements to the right as it should, but when you put the "END IF" where it should be, it doesn't always shift the code after the "END IF" back to where it should be The "Pretty Code" option is nice and all, but it needs a little work.
VB.NET makes stepping into your "Form_Load" code hard If you press "F8" to step into your code in the "Form1_Load" event, VB.NET will step into the "New" constructor of the Form instead and will not take you to the "Form1_Load" event... even if you have code there.

To stop in the "Form1_Load" event, you have to explicitly put a break there, or put the "Stop" statement in the "Form1_Load" event.

NOTE: I found that the reason for this is the "Form_Load" event is actually called from a process outside the scope of the debugger... so you can't step to it... at all.  All you can do is put a break-point there.

 I can see how this might be considered "by design"... but it's not the expected behavior for a former VB5 / VB6 programmer.
     


CONCLUSION:  Visual Studio .NET 2003 is a BIG improvement over the initial release of .NET... but still has a bit more to go until it's solid.  It does have a large selection of rich built-in controls that make your life a little easier, it's got a lot of neat built in technologies, and it's got some neat new features like translucent forms, and control anchoring.  It's BIGGEST downfall that I've seen is the HUGE 25 MB .NET Framework 1.1 redistributable that you have to push on people... even to execute a 1 KB .EXE compiled with VB.NET (not to mention the Windows service packs, the MDAC update, the Windows installer update, and the IE update that are a prerequisite for installing the .NET Framework).  Is it worth it to switch over to .NET?  It really depends on your project, it's scope, it's complexity, and it's target market.  ASP.NET is a definite winner in my book, but VB.NET still falls just a bit short... it's neat... but short.

WANT MORE?  Try this web site:  http://www.jelovic.com/dotnetbugs/   (Thanks Daniel)