Visual Studio runs like a dog with more than 30 projects

Hi,

Not exactly related to VS SDK, but don't know where else to post, looking for thoughts from people with a deep understanding of the VS IDE.

Over the past few years of developing with VS, each time I add a new c# project, VS seems to get a little slower to do things, to the point that it sometimes takes 5 mins to just load a form in designer mode in the IDE when I have over 100 C# projects in my system.

It only takes me a couple of months of full time development to get to 100 projects (99 projects compile to individual DLLs that contain 3 or 4 Winforms typically, one project contains the main exe) and then the whole thing runs like a dog.

One of the projects is also a used by all other projects as having the base classes for all the forms and controls in the system.

Would really love to finish the VS SDK integration and launch the framework that sits behind it commercially.

I would like to know if it means we have to add some facility for projects to be switched in and out of the solution (automatically replace references etc) due to this shortcoming

Regards

Andrew McGrath

Hi Tom,

It can be slow when I add a new project or form, when I go to open a form in the IDE, when I save a form, when I add a control, when I delete a control, even when I go to create a data set with the Data Set Designer.

As the solution gets very big (100 projects plus) it can take 5 minutes to stop freezing. I have experienced this on different machines running XP, W2K3, and Vista machines, typically with 2GB RAM. The RAM usage of the IDE doesn't go ballistic or anything during this time. It just looks like it is twiddling its thumbs.

Typically I only have 3 forms in each DLL:

New Record (mainly Textbox and ComboBox

Edit Record (mainly Textbox and ComboBox)

View All Records (Data Grid)

The datagrid is bound with a Visual Studio created Dataset. The New and Edit forms get all their data only at runtime as I have built my own databinding framework (based on the name of the control).

I had just hoped to keep modularised at the DLL level so that DLLs could be plugged in and out for clients with similar systems, without having to do it at the source code file level, and require a rebuild for each new iteration.

I posted to a dotnet mailing list in Australia on Friday, and the suggestion coming back was that I should stick the similar files into Folders within one project. While that works at one level it takes away the DLL modularity I was hoping to achieve.

I am going to try another suggestion I also got from that Forum, which is to disable the setting at Tools | Options | Debugging | Enable property evaluation and other implicit function calls.

However I am not with that system today, and won't be until Tues/Wed.

I will post back with more info then.

I would be happy to send a copy of a solution to someone at MS to diagnose if all else fails. I have created a number of these systems over the past few years.

Regards

Andrew

Hi Boban,

We haven't been using any source control on these projects.

The main project (the exe) does have an internal reference to each of the other projects (100+ references) that are in the same solution. Otherwise references are kept to a minimum. If that were a problem then I could probably dynamically load the modules at runtime via a lookup table. Apart from one or two, the references are not otherwise required at design time.

We also have one project that contains our own versions of each of the base forms (NewRecordForm, EditRecordForm, ViewRecordForm as well as a derived DataGridView and derived TextBox, ComboBox and other controls including Labels), all dervied directly from System.Windows.Forms.* namespace.

Thanks

Andrew

Tom,

I have had limited success by reducing the number of active projects, however my experience when initially putting each of these systems together is that I quickly get back over 30 projects again - got it down to 28 last week, now back to 46 as I go through the stage of applying cross module link code.

During this upcoming weekend, I will send you a solution so you can take a look at the problem, with some examples of where I hit bottlenecks.

Just had a 2 min+ wait duplicating a textbox on a WinForm by doing Ctrl+C, Ctrl+V. - it freezes after I do the Ctrl+C.

Yesterday I picked up a new significant project that will use this style of development. So I will be keen to get you to take a look.

Regards

Andrew