M
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
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