Visual Studio has gotten very slow recently. It takes approximately 30s to more than a minute after a select a control before VS is ready to let me do anything. As you can imagine, this has tanked my productivity. I've taken to directly modifying the designer file, because that is way faster. I'm also getting an error every time I close VS.



It definitely seems to be a size issue. The form I'm working on is large and complex (~180 controls/components). On smaller forms it's not a problem.



I've done a repair on VS (reinstalled and then reapplied SP1). It helped for about 30 minutes.



Any ideas on how to fix this?



Thanks!

You're going to laugh, but we've discovered that the more tool windows you have open, the slower VS operates.  Most of the tool windows tie into VS IDE events and update any time the code/designer changes.  If you have any sort of refactoring tool (like DevEx Refactor!), you might try uninstalling it; we've had some of those tank before, too.  Also, with VB.NET, since it has the design-time compiler, it helps if you keep your solution size small.  The bigger the solution, the more VS has to try and compile each time the code changes.  Just a few suggestions...

Does the tool windows include windows like errors, output, Find window(s), command window, etc? I typically have the control window (toolbox) and the document outliner open plus the solution explorer.



Also, any recommendations on how to organize the solutions to increase responsiveness and how to then debug/test the app as you go with the more limited solution? (I know this was covered in class, but I don't quite have it yet )

Out of those windows you mentioned, the two most likely to cause problems are the Errors window (an absolute necessity) and the Document Outline (one of my personal favorites).  The reason being that these two track any and all changes to the code to repopulate themselves from the CodeModel of the document.  So, you're being slowed down by the real-time compiler and the building of these windows.  I think the Document Outline might be sluggish when you get to having 100+ controls on a single form.  But the true root of all slugishness in VB is that stupid design-time compiler.  Some of the problems with the compiler can be avoided by replacing project references with references to the DLL of that project (which in VB kinda negates the use of keeping them in the same solution since you won't get the new intellisense for changes to the DLL until you build it... bah) since the compiler won't have to reach as far each time you make a simple change in code.  My only suggestion would be to try closing a window or two at a time and see if it speeds up.  If you close everything except the code editor and the solution explorer and it runs really fast, then, well, one of those windows is probably causing a problem.

I tried closing all of them and it's still sluggish (plus now I don't have the errors and document outline windows :,( ).



Is there any sort of coding you'd do to deal with the vb design time compiler issues? I know there is that property to determine if the code is doing the design time thing (IsDesigner I think). Where do you get the most bang for the buck? Constructors? property setters? Finally, it sounds like C# doesn't do this, is that right?

No, there is not a setting that you can use to turn off the design-time compiler in VB.  Also, there is no way to mitigate what it covers (i.e. through the DesignMode property or anything like that).  As for C#, you are correct, it doesn't check at design-time (it does do simple syntax checking, like missing semi-colons and such, but no type/compiler checking).  That's probably my biggest issue with VB is the stupid compiler.  I can only hope that they allow you to turn it off in VS2008 (which will be out before the end of the year... Beta 2 has already been out for quite some time).

Ben Hyatt been bugging me (in a friendly way) to try out VS2008. Maybe its getting to be time



And maybe I need to get proficient enough in C# too



Thanks Ben!

Yeah, I've glanced at VS2008, too, but not for anything that is ready for production.  I like the graphical changes to it, but the silly "fuzzy text" in the WPF kills me.  You'd think they would work that one out  

I woke up this morning with dread. Working on forms has been agonizingly slow. Selecting a control can take a minute. Setting the Text on a label can take 10-15 seconds. Ugly.



A Bit of Background:

For more than a month I've been doing dev that doesn't really use the BO mapper or the security dialog or any thing that directly involves the StataFrame db (some of you are seeing where this is going, I'm sure ). Earlier this summer I move the StrataFrame db from my local environment to the corp office so a another developer could start using SF and helping me do the dev work.



The Light Bulb Goes Off (and the SF Connection Manager):

Well, this morning, when I started up VS, I get prompted for a connection to the SF db . Yesterday, as part of the work I was doing, I deleted the cached connection file used by the Connection Manager, so today I get the prompt. It must have been failing silently for a couple of months now. So, I open my VPN so my computer can access the SF DB and viola, it's speedy again.



So, once you have installed the SF framework, make sure you can connect to the SF db!

LOL....I am not laughing at you...but with you.  The DTE is aweful about purpressing errors.  We have fought this from the beginning.  I thought that the connection would throw an exception though....at any rate, I am glad that you have it going and it is speedy again....it is like getting a Christmas present in the middle of the summer