shared assemblies and distribution

[Dan]

Here's a scenario I'd like to discuss in order to setup my VS.NET IDE
properly and be able to prepare a distribution:

a) I have a windows forms C# app using 3 shared assemblies I developed to
include various functions. The 3 shared assemblies are strongly named, and
some of them are also used by others of them. Let's call them A, B, and C:
now, B references A, while C references A and B.

b) there is a distinct solution for each of the assemblies (A,B,C) and
another for the client application (let's call it D). Each shared assembly
solution has a post-build event in its project so that gacutil is first
called to uninstall from the GAC any previous version and then to install
the new one.

c) to be able to debug into the referenced assemblies (A,B,C), each
project referencing the shared assemblies has a reference to the DEBUG
version of the DLL, with "copy local" set to false (as the DLL will reside
in the GAC). Thus:

-- A (strongly-named assembly) references nothing
-- B (strongly-named assembly) references A-debug
-- C (strongly-named assembly) references A-debug and B-debug
-- D (client EXE) references A-debug, B-debug, C-debug

My questions are:

1) is it possible to differentiate the post-build event for debug and
release versions? It seems this is not possible, but this carries the
disadvantage that whenever I build a release version of a shared assembly
this is also installed into the GAC, so that I can no more debug into it (it
is the RELEASE version) and the client program does not longer start, as its
references to the DEBUG version seem broken. Or is there a more correct way
of handling references so that they are not affected by such debug/release
changes?

2) given a relatively complex scenario with 3 shared assemblies A,B,C and
a client D, where B references A, C references A and B, and D references
A,B,C, whenever I want to build a release to be distributed I'll have to
manually replace all the references so that they are linked to the RELEASE
version instead of DEBUG, then recompile all, then restore all the
references to the DEBUG versions and recompile so that I can continue
developing and debugging... This does not seem very smart! I suppose this is
my fault, but then, what's the correct way of doing these things?

Thanks to all!

 

[Nicholas Paldino [.NET/C# MVP]]

Dan,

See inline:

1) is it possible to differentiate the post-build event for debug and
release versions? It seems this is not possible, but this carries the
disadvantage that whenever I build a release version of a shared assembly
this is also installed into the GAC, so that I can no more debug into it (it
is the RELEASE version) and the client program does not longer start, as its
references to the DEBUG version seem broken. Or is there a more correct way
of handling references so that they are not affected by such debug/release
changes?

I don't believe that it is possible. The post build step doesn't have
access to the flags passed to the C# compiler (I believe, or I don't know or
they are undocumented), so you can't differentiate between setup
configurations.

2) given a relatively complex scenario with 3 shared assemblies A,B,C and
a client D, where B references A, C references A and B, and D references
A,B,C, whenever I want to build a release to be distributed I'll have to
manually replace all the references so that they are linked to the RELEASE
version instead of DEBUG, then recompile all, then restore all the
references to the DEBUG versions and recompile so that I can continue
developing and debugging... This does not seem very smart! I suppose this is
my fault, but then, what's the correct way of doing these things?

I think that to make this easier, you can always have two separate
solutions, one for debugging, and one for building. Then, you can set the
post build steps on each to unregister/register as you wish, as long as you
have the correct solution file open. You would just have to add all the
projects to each solution, and make sure you don't change the properties on
the solution.

Hope this helps.