Huge project - long build time

[cody]

We have a huge project, the solutuion spans 50 projects growing. Everytime I
want to start the project I have to wait nearly over 1 minute for the
compiler to complete building. This is unaccaptable.

I thought about loading only the project I need into visual studio and not
the whole solution. The problem is that the compiler tells me it cannot find
the referenced dlls (project references) although they are all lying in
their bin and obj folders.

To get around that problem I have the idea that I could replace the project
references with dll references.
But this would introduce more problems: When I have to make a complete
rebuild, I have to manage the build order manually since the compiler cannot
see which project is dependend from which.
Thr second thing is what is if I switch from debug to release build? Do I
have to change all paths from all referenced dlls from .\debug to .\release?
Would it work this way or is there another/better solution?

 

[Steve McLellan]

Hi,

Try http://www.codeproject.com/macro/fastsolutionbuild.asp

Never used it myself, but it's supposed to greatly improve depedency
checking time.

Steve

 

[cody]

But this is for C++ only - but we are using C#.

 

[cody]

Additionally it doesn't work. I installed it and it didn't show up in visual
studio macros. I also tried regsrv32 register it manually and it also didn't
show up in visual studio.

 

[Charles Law]

Hi Cody

Are you working on all 50 projects at the same time? If not, I would
personally build those projects that you are not changing and then remove
them from the solution, referring just to the dll where necessary. You could
perhaps reduce your solution to only ten projects, which would obviously
build a lot more quickly.

HTH

Charles

 

[cody]

Are you working on all 50 projects at the same time? If not, I would

personally build those projects that you are not changing and then remove
them from the solution, referring just to the dll where necessary. You could
perhaps reduce your solution to only ten projects, which would obviously
build a lot more quickly.

It was my suggestion to only use one project at the same time but then in
case of a complete rebuild I have to take care of the build order manually
and that can be very very tricky.

 

[Ken Dopierala Jr.]

Hi Cody,

Try creating two seperate solutions. One is your working solution where you
just pull in the projects you are working on. The other solution is your
full build solution that has all the projects in it. Never tried that but
it might work. Good luck! Ken.

 

[cody]

Try creating two seperate solutions. One is your working solution where
you

just pull in the projects you are working on. The other solution is your
full build solution that has all the projects in it. Never tried that but
it might work. Good luck! Ken.

What does that help? The information wheather dll references or project
references are used are stored in each project separately, so if I use one
solution for building the whole stuff I still have to take care of the build
order manually.

I cannot believe that nobody else here has experience with large projects.

 

[Ken Dopierala Jr.]

Hi Cody,

You could try to do what I do. My current web app has over 130 seperate
projects and I'm having no problems whatsoever. Here is what I do.

My solution contains what I'm currently working with. For example, right
now it has the web app itself (that is always there), over a dozen web
services and about 20 class libraries that are consumed by the web services.
As I finish web services and class libraries I remove them from my solution.
For every single project in my solution I reference the DLL directly, not
the project. The only time I have a hassle is when I need to go modify a
class library. Sometimes more than one of my web services reference these
libraries and I need to go back and recompile those web services so they all
have the correct version of my DLL. This is really simple though, I just
browse to the web service, load it up, and recompile.

Yes it is a hassle but when you develop large applications you need to
realize that planning and architecture are the most important things. I
know that when I need to go through that hassle it is due to a failure on my
part and not the IDEs problem. I either didn't debug my class well enough,
or I didn't architect it well enough because I had to go back and make
changes. That is my failure and my frustration is due to my mistake. It
sounds like you didn't do any planning and are frequently going back to
modify projects that projects built on top of them rely on. That is just
inefficient and short-sighted on your part. Sit down, map out your
solution, build it from the ground up and you should see things go a lot
more smoothly for you. Good luck! Ken.

--
Ken Dopierala Jr.
For great ASP.Net web hosting try:
http://www.webhost4life.com/default.asp?refid=Spinlight
If you sign up under me and need help, email me.

Try creating two seperate solutions. One is your working solution where you
just pull in the projects you are working on. The other solution is your
full build solution that has all the projects in it. Never tried that but
it might work. Good luck! Ken.

What does that help? The information wheather dll references or project
references are used are stored in each project separately, so if I use one
solution for building the whole stuff I still have to take care of the build
order manually.

I cannot believe that nobody else here has experience with large projects.

--
cody

[Freeware, Games and Humor]
www.deutronium.de.vu || www.deutronium.tk

 

[cody]

It

sounds like you didn't do any planning and are frequently going back to
modify projects that projects built on top of them rely on. That is just
inefficient and short-sighted on your part. Sit down, map out your
solution, build it from the ground up and you should see things go a lot
more smoothly for you. Good luck! Ken.

Yes you aqre completely right, we didn't do any planning at all!
When the project started nobody realized that it would grow so far and would
makes things so complicated. To make things more complicated, most of us are
newbies.
However, your suggestion is similar to what I planned so we will try it and
hope it will work for us,
obviously it works for you

Thanks for your suggestion.

 

[Budtse]

Hi,

What we usually do is make a directory tree with separate solutions that
contain related projects (e.g. a solution with all serial interfaces, a
solution with all data-access functions, ...). All these solutions build to
the same BIN directory (use separate build directories for Release and Debug
versions).

For a complete build, we use batch files.

You can also look in to NAnt (http://nant.sourceforge.net/), which is an
open source build tool for .NET, kind of like the make tools for C++.

Hope this helps,

Budtse

 

[Jay B. Harlow [MVP - Outlook]]

Cody,
In addition to the other comments.

rebuild, I have to manage the build order manually since the compiler
cannot
see which project is dependend from which.

You should be able to use "Project - Project Dependencies" to indicate which
projects depend on which other projects, that will then set the build order.
If you use Project References the Project Dependencies are set
automatically, if you use DLL References, then you can manually create the
dependencies needed...

Hope this helps
Jay

 

[cody]

I now changed all project references into dll references in one central
folder where all assemblies are located.
The problem is if I delete all assemblies and do a complete rebuild I get
compile errors.

The build order is correctly set: for example first project A then B. But it
gives me an error that it cannot compile B because A is missing. But in the
build order it should compile A first but it seems to compile B first. I
cannot see A.dll in output folder and it doesn't output any compile errors
concerning A, only errors stating that it cannot compile B.

--
cody

Freeware Tools, Games and Humour
http://www.deutronium.de.vu || http://www.deutronium.tk

Hi Cody,

You could try to do what I do. My current web app has over 130 seperate
projects and I'm having no problems whatsoever. Here is what I do.

My solution contains what I'm currently working with. For example, right
now it has the web app itself (that is always there), over a dozen web
services and about 20 class libraries that are consumed by the web services.
As I finish web services and class libraries I remove them from my solution.
For every single project in my solution I reference the DLL directly, not
the project. The only time I have a hassle is when I need to go modify a
class library. Sometimes more than one of my web services reference these
libraries and I need to go back and recompile those web services so they all
have the correct version of my DLL. This is really simple though, I just
browse to the web service, load it up, and recompile.

Yes it is a hassle but when you develop large applications you need to
realize that planning and architecture are the most important things. I
know that when I need to go through that hassle it is due to a failure on my
part and not the IDEs problem. I either didn't debug my class well enough,
or I didn't architect it well enough because I had to go back and make
changes. That is my failure and my frustration is due to my mistake. It
sounds like you didn't do any planning and are frequently going back to
modify projects that projects built on top of them rely on. That is just
inefficient and short-sighted on your part. Sit down, map out your
solution, build it from the ground up and you should see things go a lot
more smoothly for you. Good luck! Ken.

--
Ken Dopierala Jr.
For great ASP.Net web hosting try:
http://www.webhost4life.com/default.asp?refid=Spinlight
If you sign up under me and need help, email me.

Try creating two seperate solutions. One is your working solution

where
you

just pull in the projects you are working on. The other solution is your
full build solution that has all the projects in it. Never tried that but
it might work. Good luck! Ken.

What does that help? The information wheather dll references or project
references are used are stored in each project separately, so if I use one
solution for building the whole stuff I still have to take care of the build
order manually.

I cannot believe that nobody else here has experience with large projects.

--
cody

[Freeware, Games and Humor]
www.deutronium.de.vu || www.deutronium.tk

 

[Guest]

Hi Cody

We too are having terrible speed problems with VS.NET.

Our solution contains 10 VB.NET projects, but they're quite big: the
solution as a whole contains 500K lines of code.

Response time in the VB IDE has long been a problem for us. You can type a
line, press return and it's 30 seconds to a minute before the IDE responds.
And this is on a high-end machine with 2GB RAM! I understand that this is
because the VB compiler recompiles behind the scenes every time you leave a
line, and this behaviour is too tightly bound into the VB IDE to be removed.

It really does make VB.NET unsuitable for enterprise application
development. C# doesn't seem to have the same problem, but unfortunately
VB.NET is a corporate standard here, so we're stuck with it.

But a slow response time isn't our biggest problem: compile speed is.

Until the middle of last week, build times were reasonable and the compiler
seemed to be able to do dependency checking ok. Then, one by one, each
developer on the team started seeing build times lengthen dramatically. It
now takes 20 minutes to rebuild the system.

Also, all concept of dependency checking seems to have been lost. You can
change one line in one project, press the Start Debugging button, and VS
rebuilds the entire solution.

When you build, it takes ages even to start. Then as it does each project,
it says "Building satellite assemblies" and then just waits. I have no idea
what satellite assemblies it might be building.

The best we can do at the moment is do a Get Latest Version in the morning
to get everything out of SourceSafe, then each of us spends 20 minutes doing
a full rebuild. Then we use Configuration Manager to switch the building of
all the projects off except the one each of us is working on.

When any of us is ready to test, they build only the project with their
changes, then use Configuration Manager to switch all projects off before
doing Start Debugging.

Even then, there's a long pause before text appears in the Output window to
say that nothing needed building!

Having searched the 'net I found a suggestion that unplugging your network
cable might help. Tried it but no luck, and in any case we can't debug like
that as we need access to our database server.

As a workround, messing with Configuration Manager isn't ideal, and given
that the projects are a mixture of ASP.NET, web services, business layer and
data layer code, we frequently need to make changes in several projects when
we implement a new use case. Back to a 20 min wait each time.

This really is a serious problem for us and will shortly impact our
deadlines. So if anyone at Microsoft knows what is going on, please could we
have some advice.

thanks

 

[Guest]

It's been suggested we might have a circular dependency between projects...

....which might explain why each developer hit the problem one by one, i.e.
as each did a Get Latest Version

 

[Charles Law]

Hi Cody

Microsoft confirm that there is a problem when using dll references for
projects within the solution, such that it is not always possible to resolve
dependencies correctly. This can result in compile errors for phantom
errors, and all projects being rebuilt when only one changes. The current
recommendation is to use project references only.

HTH

Charles

I now changed all project references into dll references in one central
folder where all assemblies are located.
The problem is if I delete all assemblies and do a complete rebuild I get
compile errors.

The build order is correctly set: for example first project A then B. But
it
gives me an error that it cannot compile B because A is missing. But in
the
build order it should compile A first but it seems to compile B first. I
cannot see A.dll in output folder and it doesn't output any compile errors
concerning A, only errors stating that it cannot compile B.

--
cody

Freeware Tools, Games and Humour
http://www.deutronium.de.vu || http://www.deutronium.tk

Hi Cody,

You could try to do what I do. My current web app has over 130 seperate
projects and I'm having no problems whatsoever. Here is what I do.

My solution contains what I'm currently working with. For example, right
now it has the web app itself (that is always there), over a dozen web
services and about 20 class libraries that are consumed by the web services.
As I finish web services and class libraries I remove them from my solution.
For every single project in my solution I reference the DLL directly, not
the project. The only time I have a hassle is when I need to go modify a
class library. Sometimes more than one of my web services reference
these
libraries and I need to go back and recompile those web services so they all
have the correct version of my DLL. This is really simple though, I just
browse to the web service, load it up, and recompile.

Yes it is a hassle but when you develop large applications you need to
realize that planning and architecture are the most important things. I
know that when I need to go through that hassle it is due to a failure on my
part and not the IDEs problem. I either didn't debug my class well enough,
or I didn't architect it well enough because I had to go back and make
changes. That is my failure and my frustration is due to my mistake. It
sounds like you didn't do any planning and are frequently going back to
modify projects that projects built on top of them rely on. That is just
inefficient and short-sighted on your part. Sit down, map out your
solution, build it from the ground up and you should see things go a lot
more smoothly for you. Good luck! Ken.

--
Ken Dopierala Jr.
For great ASP.Net web hosting try:
http://www.webhost4life.com/default.asp?refid=Spinlight
If you sign up under me and need help, email me.

Try creating two seperate solutions. One is your working solution where
you
just pull in the projects you are working on. The other solution is your
full build solution that has all the projects in it. Never tried
that but
it might work. Good luck! Ken.


What does that help? The information wheather dll references or project
references are used are stored in each project separately, so if I use one
solution for building the whole stuff I still have to take care of the build
order manually.

I cannot believe that nobody else here has experience with large projects.

--
cody

[Freeware, Games and Humor]
www.deutronium.de.vu || www.deutronium.tk