[visual studio 2003 build system] incremental build not optimal?

[Thorsten Ottosen]

Dear all,

I work on a major system written in C# in visual studio 2003.

Our solution has 10+ projects and all projects are compiled with
/incremental.

In a C++ world, non-incremental builds aren't used for development...it
would simply take too
long to compile an update. So we would naturally expect that incremental
builds for C# would
work great too.

However, we have been experiencing problems in ouy C# project which has lead
us to
disable dependencies between certain projects in our solution.

I can come up with 2 reasons for our slow build times:

1. The dependency analysis carried out by visual studio for C# is buggy
causing more recompilations
than necessary
2. Link times are simple huge due to our big project. (But shouldn't linking
be at run-time/load-time?)

Has anyone else experienced such problems?

Thanks in advance

Thorsten

 

[Johann Blake]

Thorsten,

Linking is never a part of the .NET Framework concept. Code is compiled
to CLR format.

Is your project divided up into various projects? If so, you only need
to recompile what you change. A total recompile of all projects is
never necessary. Dependencies shouldn't be a problem if you put your
common DLLs into the GAC and turn off automatic versioning.

Best Regards
Johann Blake

 

[Thorsten Ottosen]

Thorsten,

Linking is never a part of the .NET Framework concept. Code is compiled
to CLR format.

ok, but some kind of linking must happen at some point, right?

Is your project divided up into various projects?

yes. we have one solution with 10+ projects.

should we just have one gigantic project?

If so, you only need
to recompile what you change.

right. that's what I thought.

by "what you change", do you then mean

1. only the files with changes, or
2. files with changes and all files that have imports elements from those
files

?

A total recompile of all projects is
never necessary.

no. agree.

Dependencies shouldn't be a problem if you put your
common DLLs into the GAC and turn off automatic versioning.

when I speak of dependencies I mean the ones defined
from with visual studio. you don't mean that we should
put those often changing dll's into the GAC, do you?

best regards

Thorsten

 

[Johann Blake]

Thorsten, see my commens below...

Linking is never a part of the .NET Framework concept. Code is compiled
to CLR format.

ok, but some kind of linking must happen at some point, right?

JB: There is no such thing as linking in .NET, at least not the way it
is done using old Visual C++. Only compiling is ever done. During
runtime, .NET Framework attempts to locate and load dependent
assemblies. In fact yesterday I accidently sent someone a compiled
version of my application without the dependencies. When they ran it,
it looked normal until of course the dependencies got accessed at the
point in code where they are used. This so-called run-time locate/load
is the equivalent of the old linking method.

Is your project divided up into various projects?

yes. we have one solution with 10+ projects.

should we just have one gigantic project?

JB: You should always use multiple projects broken down into reusable
components. 10 projects really isn't that gigantic. I've worked on
projects where hundreds of projects made up the product. In fact, most
of your projects should probably be DLLs.

If so, you only need
to recompile what you change.

right. that's what I thought.

by "what you change", do you then mean


1. only the files with changes, or
2. files with changes and all files that have imports elements from
those
files


JB: If designed correctly, you should be able to recompile only the
module that changes. For instance, if you have a C# DLL that is used by
multiple clients that you have written, it normally would not be
necessary to recompile those clients provided that the interface in
your DLL retains backward compatibility. There is a gotcha however. It
has to do with versioning. Versioning under .NET is one of the most
misunderstood and difficult things to get right. If you modify a DLL
that causes a major version number change (although I believe any
version change), your client will not run with the changed DLL. To
avoid this, you need to manually force the versioning number to remain
the same. Alternatively, you can register the DLL to indicate that it
is to work with any version of any client. It's been a while since I've
done that and can't remember exactly how its done, but there is a tool
that ships with Visual Studio .NET that lets you mark your components
versioning to indicate that it is compatible with all clients using a
certain version of your DLL or earlier. I believe this information is
stored in some XML configuration file that you can either manually
modify or use the tool I mentioned.

A total recompile of all projects is
never necessary.

no. agree.

Dependencies shouldn't be a problem if you put your
common DLLs into the GAC and turn off automatic versioning.

when I speak of dependencies I mean the ones defined
from with visual studio. you don't mean that we should
put those often changing dll's into the GAC, do you?

JB: I am referring to the DLLs that you create. If these are intended
to be used among various applications, they really should be installed
in the GAC, especially if they change a lot. If you don't put them into
the GAC, you will be forced to copy the updated DLL to all the
directories where the client applications are installed, and if they
are installed all over the place, lots of fun updating them.

Thorsten

 

[Thorsten Ottosen]

Thorsten, see my commens below...



ok, but some kind of linking must happen at some point, right?

JB: There is no such thing as linking in .NET, at least not the way it
is done using old Visual C++. Only compiling is ever done. During
runtime, .NET Framework attempts to locate and load dependent
assemblies.

right...that's dynamic linking

In fact yesterday I accidently sent someone a compiled
version of my application without the dependencies. When they ran it,
it looked normal until of course the dependencies got accessed at the
point in code where they are used. This so-called run-time locate/load
is the equivalent of the old linking method.




yes. we have one solution with 10+ projects.

should we just have one gigantic project?

JB: You should always use multiple projects broken down into reusable
components. 10 projects really isn't that gigantic. I've worked on
projects where hundreds of projects made up the product. In fact, most
of your projects should probably be DLLs

they are.
..

right. that's what I thought.

by "what you change", do you then mean


1. only the files with changes, or
2. files with changes and all files that have imports elements from
those
files


JB: If designed correctly, you should be able to recompile only the
module that changes. For instance, if you have a C# DLL that is used by
multiple clients that you have written, it normally would not be
necessary to recompile those clients provided that the interface in
your DLL retains backward compatibility.

I perfectly understand that...my question is if visual studio is
smart enough to figure this out? Or if visual stodio just uses "naive"
file dependency analysis.

There is a gotcha however. It
has to do with versioning. Versioning under .NET is one of the most
misunderstood and difficult things to get right. If you modify a DLL
that causes a major version number change (although I believe any
version change), your client will not run with the changed DLL. To
avoid this, you need to manually force the versioning number to remain
the same. Alternatively, you can register the DLL to indicate that it
is to work with any version of any client. It's been a while since I've
done that and can't remember exactly how its done, but there is a tool
that ships with Visual Studio .NET that lets you mark your components
versioning to indicate that it is compatible with all clients using a
certain version of your DLL or earlier. I believe this information is
stored in some XML configuration file that you can either manually
modify or use the tool I mentioned.

Ok, I might loo at it.

when I speak of dependencies I mean the ones defined
from with visual studio. you don't mean that we should
put those often changing dll's into the GAC, do you?

JB: I am referring to the DLLs that you create. If these are intended
to be used among various applications, they really should be installed
in the GAC, especially if they change a lot. If you don't put them into
the GAC, you will be forced to copy the updated DLL to all the
directories where the client applications are installed, and if they
are installed all over the place, lots of fun updating them.

Actually I think they are only copied once because we only have one
application.

Thanks for your help

-Thorsten