Friday, November 04, 2005

 

VS2005 annoyances, part 1

As I may have mentioned, I do a fair bit of work in C#, and one of my big jobs is to maintain a pretty large image processing system in C#. I moved this sytem to VS2005, mostly because we wanted some of the new UI features. When moving a system from 2003, VS2005 has some most amusing bugs. Namely, my app has one main form where just about everything happens. The different parts of this form are written as user controls. All the user controls load fine and can be edited with no problems. When I start VS2005, I can load the mainform, and edit it. If I navigate away from that screen and go back, I get a message box that says 'Parameter is incorrect', and the IDE closes. Now, here's the fun bit. If I reload the IDE, it remembers that this form is open, so it opens it, but does not start with it visible. So, if I forget and click on it, the IDE crashes AGAIN. I need to go to the windows dialog, close the window from there, close the IDE and start it again in order to edit my main form.

Isn't that just brilliant. Just to add insult to injury, I did not notice this at first, and I told someone on the Microsoft forums that they needed to look into their own code before blaming Microsoft. So, I look like an idiot. Again.

Comments:
Ouch, nasty bug. I haven't run into anything like that yet. Are you doing anything odd or relying on conditions (i.e. some variable being non-null...) inside your user control constructors? That would be my only guess as to why its bombing.
 
Hey CG, check this out, it's sure to generate some traffic for you. Your blog got mentioned on the (in)famous mini-microsoft blog. Check it out here.
 
Oh it's not good when this happens. Two things:

1) Go to your project directory, list the hidden files and look for one ending in .suo. Delete that file. This file just tracks what you had open, so you won't lose anything important.

2) You should now be able to start VS. Start two instances of VS, attach one to the other (Debug >> Processes >> devenv.exe).

3) Choose Exceptions >> CLR Exceptions >> Break when exception is thrown

4) Go the the other version of VS (the one that's being debugged) and open your form.

You'll start breaking on exceptions. Hit continue until you see an exception of type ArgumentException.

Look at the stack, and post it here. If it's something in your code you can fix it but in either case the designer shouldn't crash there, so the stack will tell us where we're letting an exception sneak through. We did a bunch of work to catch all of those, but there's a lot of possible nooks and crannies.

SB
 
Moving the user controls into separate DLLs fixed this for me in VC++ Express Beta. Feels like some overcautious code path in the new designer that marks all components in the same project as changed.
 
This comment has been removed by a blog administrator.
 
Anyone else notice that if you create even a simple win form using the new bindingsource and bindingnavigator, half the time for no apperent reason you will get a concurrency violation if
you create a new record, save it, and then try to delete it ?

Turns out that when you hit the new record button, it creates fields with nulls. I had to fill all the fields with defaults and that fixed it. Only took me 8 hours to figure it out.
 
Post a Comment



<< Home

This page is powered by Blogger. Isn't yours?