HELP!! I'm having "DLL Hell" in .NET

[malcolm]

Hello,

We have a small team building a project that involves some 30 or so c#
assembly dlls. It is a client server application with 1 exe as the
starting point. The dlls and exe are sharing an assemblyinfo file that
has a strong name and version assiciated with it. We are having
problems in the way we have been developing. We have made two attempts
at this.

Attempt 1) In our first attempt, we basically had 1 folder that
contained all the output assemblies. This used to be the way we did
things in COM, but this causes us to have to re-compile every
dependant project when we make changes. I thought .NET was supposed to
solve this? On top of this, every dll get's locked by Visual Studio.
This means it becomes difficult to open more than one Visual Studio
project at once (another thing we used to do frequently in COM with no
problems). We had all "copy local = false" set for all references
since they all pointed to one output directory. We even tried
variations of the copy local settings depending on whether the project
was the starting main exe or a referenced assembly. We just couldn't
get it right so we did some research on the web and switched to
Attempt 2.

Attempt 2) Now we have each assembly pointing to it's own output
directory in a hierarchy format. The exe is the root directory with
all the supporting assemblies in directories in the root. We have
been very conscious that the reference paths are all in the corect
order to make sure the correct asssemblies are being referenced. This
means that each assembly has (in it's output folder) a copy of the
assemblies it needs. This is accomplished because we set copy local =
true for each reference in these assemblies. The exception is the main
executable. In here we have all the assembly references set to copy
local = false. We found this approach on the web and it seemed that
this was the nirvana we were seeking. But the reality is that we were
still having problems. We cannot compile any core assembly without
having to re-complile every dll that references it. In COM, there was
the concept of binary compatibility which allowed us to compile core
dlls as long as it didn't break the Interface (i.e. we could do
internal changes and/or add methods and properties). I'm thinking .NET
should be at least this good if not better. On top of this, we now
have to manage our reference paths hiarchy. Since the main executable
points to each output folder, the order of the reference paths is
crucial since core dlls show up several times (from the perspective of
the main exe). We are also very consious of the project build order
settings which are set correctly.

So in short, both methods yield COM like results (if not worse). And
many times we won't find the errors until run-time which is even
worse. We'll get assembly IO errors due to assembly manifests
version's not matching. We also occasionally get dll locking issues
caused by a number of reasons such as User Controls and having
multiple Visual Studio's open.

I'm convinced that there is a correct way to do this. Is there a 3rd
way that we should be developing or is one of our first two attempts
close but not exactly right?

Any help would be greatly appreciated.

Thanks,
Dave

[malcolm]

Ahhhh!

Finally, we got everything working. The problem was we were trying to
get too cute. Here is a list of problems we were doing wrong which
compounded our problems, so if you're having similar problems please
advise:

1) Use the default Build Paths Microsoft provides in each of your
projects. This is extremely important and in fact, Microsoft has a
huge known bug if you don't do this (and your dlls are larger than
64kb). Check out this article for more details:
http://support.microsoft.com/?id=313512. We were getting bit by this
one big time.

2) Very related to #1, leave CopyLocal = true for all referenced
projects.

3) All references should be done by project rather than by dll (unless
of course it is a 3rd party dll). This yields several advantages and
has no down sides (that I know of). One of the biggest advantages is
that Visual Studio can determine your build order.

4) What this allows you to do is basically have every project open in
1 solution. Then, Visual Studio will figure out what needs to be
compiled and when. This is a movement away from the way I remember
teams developing in COM. In otherwords, the dlls are now arbitrary and
the heart of everything is the code.
ch********@yahoo.com (malcolm) wrote in message news:<4f**************************@posting.google. com>...

Hello,

We have a small team building a project that involves some 30 or so c#
assembly dlls. It is a client server application with 1 exe as the
starting point. The dlls and exe are sharing an assemblyinfo file that
has a strong name and version assiciated with it. We are having
problems in the way we have been developing. We have made two attempts
at this.

Attempt 1) In our first attempt, we basically had 1 folder that
contained all the output assemblies. This used to be the way we did
things in COM, but this causes us to have to re-compile every
dependant project when we make changes. I thought .NET was supposed to
solve this? On top of this, every dll get's locked by Visual Studio.
This means it becomes difficult to open more than one Visual Studio
project at once (another thing we used to do frequently in COM with no
problems). We had all "copy local = false" set for all references
since they all pointed to one output directory. We even tried
variations of the copy local settings depending on whether the project
was the starting main exe or a referenced assembly. We just couldn't
get it right so we did some research on the web and switched to
Attempt 2.

Attempt 2) Now we have each assembly pointing to it's own output
directory in a hierarchy format. The exe is the root directory with
all the supporting assemblies in directories in the root. We have
been very conscious that the reference paths are all in the corect
order to make sure the correct asssemblies are being referenced. This
means that each assembly has (in it's output folder) a copy of the
assemblies it needs. This is accomplished because we set copy local =
true for each reference in these assemblies. The exception is the main
executable. In here we have all the assembly references set to copy
local = false. We found this approach on the web and it seemed that
this was the nirvana we were seeking. But the reality is that we were
still having problems. We cannot compile any core assembly without
having to re-complile every dll that references it. In COM, there was
the concept of binary compatibility which allowed us to compile core
dlls as long as it didn't break the Interface (i.e. we could do
internal changes and/or add methods and properties). I'm thinking .NET
should be at least this good if not better. On top of this, we now
have to manage our reference paths hiarchy. Since the main executable
points to each output folder, the order of the reference paths is
crucial since core dlls show up several times (from the perspective of
the main exe). We are also very consious of the project build order
settings which are set correctly.

So in short, both methods yield COM like results (if not worse). And
many times we won't find the errors until run-time which is even
worse. We'll get assembly IO errors due to assembly manifests
version's not matching. We also occasionally get dll locking issues
caused by a number of reasons such as User Controls and having
multiple Visual Studio's open.

I'm convinced that there is a correct way to do this. Is there a 3rd
way that we should be developing or is one of our first two attempts
close but not exactly right?

Any help would be greatly appreciated.

Thanks,
Dave