Optimal Workstation for Visual Studio .NET 2003 and 2005

[karlag92]

We have a very large C# winforms client application that is constructed
as a single solution currently with 75 projects. We're currently using
VS 2003 but will upgrade to 2005 some time next year.

We've noticed that Visual Studio is terribly inefficient about a lot of
things, and my testing with 2005 seems to indicate those problems may
actually be worse there.

On average, it can take 3 to 5 minutes to simply open the solution
while bound to source control (Visual Source Safe). The first build of
a session can take 10 - 15 minutes. Subsequent builds vary depending
on how deep in the dependencies the code we've just modified resides.
Not only that, even browsing the web while it is building is quite
difficult.

We're looking at getting new hardware and I'm a big fan of throwing
hardware at a performance problem when feasible. Does anyone have any
suggestions on what to look for in a workstation to optimize it for
Visual Studio?

Here are my deductions so far:

At LEAST 1GB of RAM -- of course almost all machines qualify for this
now.

VS seems VERY disk intensive so I'm thinking that the faster the IO the
better. Maybe even consider a RAID 5 set-up if we can afford it.

Do the dual core processors help VS out any? How about machine
useability while VS is building?

Any suggestions would be greatly appreciated!

Thanks!!!!!

 

[Frans Bouma [C# MVP]]

We have a very large C# winforms client application that is
constructed as a single solution currently with 75 projects. We're
currently using VS 2003 but will upgrade to 2005 some time next year.

I think it's wise to split up the solution in a couple of smaller
solutions. I dont think you're working on 75 different projects at
once, so if you break up the solution in a couple of smaller solutions,
and reference assemblies from the projects which are in a different
solution, you'll get better response times and a more responsive IDE.

That's also how I've done it with my project which is also very huge:
every subsystem has its own solution, and with a couple of post-build
event scripts I can copy the latest build of one project into a folder
where another project expects the latest build to reference.

Also compiles are much faster now.

We've noticed that Visual Studio is terribly inefficient about a lot
of things, and my testing with 2005 seems to indicate those problems
may actually be worse there.

On average, it can take 3 to 5 minutes to simply open the solution
while bound to source control (Visual Source Safe). The first build
of a session can take 10 - 15 minutes. Subsequent builds vary
depending on how deep in the dependencies the code we've just
modified resides. Not only that, even browsing the web while it is
building is quite difficult.

with that number of projects I'd compile on the command line. You'll
notice that compiling on the command line is much faster.

We're looking at getting new hardware and I'm a big fan of throwing
hardware at a performance problem when feasible. Does anyone have any
suggestions on what to look for in a workstation to optimize it for
Visual Studio?

fast disks. That's about the best investment you can make. But first,
please splitup your solution. I'd suggest 10-15 projects max in a
solution, but that also depends on the size of a project of course.

My workstation uses a RAID0 scsi diskrack and buildtimes and vs.net
response is OK. My CPU is a xeon 3Gz and I use just 1GB of ram, but
almost never run out of it even with 4 vs.net instances open for
example. Also CPU isn't the bottleneck, the disks are, even with scsi
raid0.

Here are my deductions so far:

At LEAST 1GB of RAM -- of course almost all machines qualify for this
now.

VS seems VERY disk intensive so I'm thinking that the faster the IO
the better. Maybe even consider a RAID 5 set-up if we can afford it.

raid0 with a proper backup system is ok. Get good quality disks, so
you won't have the risk of failing parts of a raid0 setup. If you keep
the sourcecontrol and other important stuff on a server with raid1
disks for example, you can rebuild quickly after a diskfailure if you
ever have one.

Do the dual core processors help VS out any? How about machine
useability while VS is building?

dualcore doesn't help much. It's a bit more responsive but you won't
solve the bottlenecks which really cost you time: disk activity.

VS.NET isn't using disk very efficiently: various parts of the system
will parallel access the disk and this causes disk trashing: the disk
heads are stepping a lot back and forth, which cause useless delays.


FB


--
------------------------------------------------------------------------
Lead developer of LLBLGen Pro, the productive O/R mapper for .NET
LLBLGen Pro website: http://www.llblgen.com
My .NET blog: http://weblogs.asp.net/fbouma
Microsoft MVP (C#)
------------------------------------------------------------------------

 

[karlag92]

How do we solve the dilema of project references vs. dll references if
we break up the solution?

We often change code in a base dll and need the change reflected when
we debug.

When you debug with VS, do you build at command line and then attach to
the application via Debug/Processes?

Are there any good reference threads about how to build from command
line with lots of projects?

Thanks!!!!!

Karl

 

[Guest]

How do we solve the dilema of project references vs. dll references if
we break up the solution?

There are probably lots of ways of doing this. The way we do it where I work
is that everyone has a folder called something like C:\SharedAssemblies which
is set as a network share, and then you have a network drive mapped such as
N:\ to that folder. You then drop all your DLLs into the folder and reference
them using N:\ComponentName.dll in the project.

This also allows you to work with only your particular changes and not worry
about bad code other people have checked into other DLLs affecting your
testing, so you know any change in behaviour is due to your changes. If you
need the latest build of another project, you just do a getlatest and run the
build file (as long as you have the build target set to C:\SharedAssemblies).

HTH