views:

798

answers:

4

With small projects, I can switch to design view almost instantly (< 1 sec).

I have a large project that takes about 60 seconds to open a control or form in design view - for the first time only. After this 60 second delay, I can open any control in the project in design view almost instantly - until I recompile the project.

If the exe built by this project is referenced in another (small) project, the small project instantly becomes as sluggish as the large project. Similarly, if I add all the files from the large project to the small project individually, the small project becomes as sluggish.

The large project references a large Managed C++ project, but if I add the same reference (and call a function from the reference to make sure it is loaded) to the small project, the small project is still fast.

My large project uses SandDock. If my small project uses SandDock, it's still fast.

My large project has about 60 user controls that appear in the toolbox. If I add 60 user controls to the small project, the small project is still fast.

If I make the user controls hidden from the toolbox with [System.ComponentModel.ToolboxItem(false)], the large project is still slow.

The problem occurs in both vs2005 and vs2008.

What could be making the large project so slow to open design view for the first time? Some other reference? The large number of controls? The large number of classes? Some other cause?

One thing I've noticed (though possibly a red herring) is that the ProjectAssemblies folder (C:\Documents and Settings\tim.gradwell\Local Settings\Application Data\Microsoft\VisualStudio\9.0\ProjectAssemblies) is huge (> 1GB) and most of the folders in here have a copy of my Managed C++ dll! These folders appear to get recreated every time the design view is re-opened (after a recompile). Could this have anything to do with the slowdown?


Further Info:

A toolstrip in the user control or form makes the form take 60 seconds to load. Removing the toolstrip (but still having several other different controls on the form) makes the switch to design view instant.

That's not the whole story though... A toolstrip in a brand new project doesn't cause massive slowdown - so there must be something in my big project which is affecting toolstrips. Also, certain other forms/controls that don't have toolstrips on them are still taking 60 secs to display the design view, so whatever it is that is affecting toolstrips is also affecting other controls too. I'll keep trying to nail down precisely which controls and maybe even what it is that's causing it!

A: 

The same similar thing is happening with my 2005 in additon to that the devenv.exe hangs randomly

and even after "building" sometimes the custom controls tend to corrupt the main form

have you recently virus scanned and defragged?

Jim
It happens on a brand new machine (as in fresh install of windows). On an older machine it takes several minutes to open the design view.
Tim Gradwell
+5  A: 

Even though you have marked the classes to not appear in the Toolbox, Visual Studio still needs to scan all of your open projects to discover that. To speed things up, you need to turn off the setting to automatically populate the Toolbox. It can get a bit annoying if you do lots of work with the toolbox, but it will speed up things a lot.

The setting is in Tools -> Options -> Windows Forms Designer, set "AutoToolboxPopulate" to false.

Ch00k
Thanks for the suggestion - but it still happens, even if AutoToolboxPopulate is set to false :(
Tim Gradwell
Even after restarting and cleaning, etc.? Thats annoying. We had the exact same situation, and that setting fixed everything up nicely. Good luck!
Ch00k
+1  A: 

The first answer: "The setting is in Tools -> Options -> Windows Forms Designer, set "AutoToolboxPopulate" to false" worked for me. The designer used to hang for at least a minute when trying to get focus on a control on a form when first looking at a form in design view. Now, it takes only a few seconds. (I didn't have enough reputation points to directly comment on that answer)

A: 

That seems to have worked a treat. I was about to go through the whole ordeal of re-installing visual studio to see if it would fix it. Many thanks.

Phil