467,132 Members | 1,149 Online
Bytes | Developer Community
Ask Question

Home New Posts Topics Members FAQ

Post your question to a community of 467,132 developers. It's quick & easy.

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

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

Jun 4 '07 #1
  • viewed: 1689
Share:
1 Reply
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

Jun 6 '07 #2

This discussion thread is closed

Replies have been disabled for this discussion.

Similar topics

23 posts views Thread by assaf__@walla.com | last post: by
reply views Thread by Angela | last post: by
1 post views Thread by StevenBarnes | last post: by
2 posts views Thread by Pinnguy | last post: by
6 posts views Thread by andrewbb@gmail.com | last post: by
1 post views Thread by Claire | last post: by
3 posts views Thread by Tawfiq | last post: by
By using this site, you agree to our Privacy Policy and Terms of Use.