Setup projects cause very slow perfomance in large .NET 2005 solut

[=?Utf-8?B?RG91Zw==?=]

We have a very large code base and use the partitioned solution model for
development and deployment. The problem is that in .NET 2005 the setup
projects cause severe performance problems when working with the master build
solution in the .NET IDE. Currently we have about 300 projects with another
150+ going to production in the coming months. The build server we use is a
Windows 2003 server with quad Intel Xeon processors and 2GB memory.

When I load the master solution on this machine, it takes about 20 minutes
to come up when the setup projects are included in the solution. The setup
projects are quite large (some have 40+ primary outputs). Simple changes
(such as adding new projects to the solution) can take several minutes
causing the CPU's to spike and the IDE to stop responding. When I manually
remove the setup projects from the solution, it takes about 1.5 minutes to
load and the performance improves dramatically when making changes.

It appears to me that the problem is that the setup projects are caching
events when changes are made in the solution and then subsequently refresh
their detected dependency lists. The current performance is so bad that I am
considering using multiple build solutions. Splitting into muliple solutions
is very undesirable as it creates unnecessary complexity for the development
team.

I have searched MSDN and Google extensively looking for hacks, workarounds,
fixes to resolve this problem. We are running VS.NET 2005 (with SP1). I
have also implemented the performance fix outlined in the following Microsoft
KB article: http://support.microsoft.com/kb/917452

Any help you can offer would be greatly appreciated!

Regards,

Doug Long
Technical Lead
BBS

[PlatinumBay]

Doug,

If I may make a couple (IMHO) suggestions:

1. Componetize as much as possible. If you have common data code, controls,
or whatnot, make them their own project in their own solution. Then
reference the compiled libraries in your main projects. In a sense, some of
the core libraries will be 'precompiled', saving the overhead during the
master build.

2. You can build in Visual Studio from the command line, for example:
devenv "solution path" /build release
to view all the command line options:
devenv /?

3. And yes, in my experience, setup projects are very slow.

Hope this helps,
Steve

"Doug" <Do**@discussions.microsoft.comwrote in message
news:B0**********************************@microsof t.com...

We have a very large code base and use the partitioned solution model for
development and deployment. The problem is that in .NET 2005 the setup
projects cause severe performance problems when working with the master
build
solution in the .NET IDE. Currently we have about 300 projects with
another
150+ going to production in the coming months. The build server we use is
a
Windows 2003 server with quad Intel Xeon processors and 2GB memory.

When I load the master solution on this machine, it takes about 20 minutes
to come up when the setup projects are included in the solution. The
setup
projects are quite large (some have 40+ primary outputs). Simple changes
(such as adding new projects to the solution) can take several minutes
causing the CPU's to spike and the IDE to stop responding. When I
manually
remove the setup projects from the solution, it takes about 1.5 minutes to
load and the performance improves dramatically when making changes.

It appears to me that the problem is that the setup projects are caching
events when changes are made in the solution and then subsequently refresh
their detected dependency lists. The current performance is so bad that I
am
considering using multiple build solutions. Splitting into muliple
solutions
is very undesirable as it creates unnecessary complexity for the
development
team.

I have searched MSDN and Google extensively looking for hacks,
workarounds,
fixes to resolve this problem. We are running VS.NET 2005 (with SP1). I
have also implemented the performance fix outlined in the following
Microsoft
KB article: http://support.microsoft.com/kb/917452

Any help you can offer would be greatly appreciated!

Regards,

Doug Long
Technical Lead
BBS