Hi Wen Yuan,
In VS Marco/Add-in, post build event fires after VS compiled each project
in solution explorer. Thereby, you can check if the project outputs any
file, and do some tasks. If you are interested in this method, I could do
some research, and give detailed information on this.
Before we go there, let me explain the larger problem that I'm trying to
solve. I'm lost in the .Net equivalent of "DLL Hell". I have a solution
that contains a main program and a bunch of library assemblies. At the core
of this is a singleton exposed via "remoting". I have a handful of other
programs that reference the library assemblies. And I have a whole bunch of
native (C++, Fortran, and Ada) programs that, until recently, were
completely oblivious of the managed assemblies.
I recently modified the native libraries that are called by the native
programs so that they call directly into the singleton. Now I need to
provide a way for all of my native programs to locate the managed
assemblies. I decided that the easiest way to do this is to strong name
sign my assemblies and install them in the GAC. This works great when I
install this whole mess on a customer's computer, but this opened up a
Pandora's Box of problems in my development environment.
My first thought was to modify all of the programs that reference my
newly-signed assemblies so that they don't get local copies of the
assemblies. Then I could just install my assemblies in the GAC whenever I
compile a new version of them. Unfortunately, this scheme requires Admin
privileges (to install in the GAC), which I don't normally have enabled.
Plan B was to provide an application configuration file for every program I
run in my development environment, using a codeBase element to point the CLR
at the assembly DLLs created by my library solution. This works great, but
it has one major problem: The codeBase element requires a specific version
number. Each time I monkey with my version numbers I'd need to go back and
modify all of the app config files to teach them about the new version
number.
Plan C was to go back to the way VB works out-of-the-box. I removed the app
config files and went back to having my managed apps make local copies of
referenced assemblies. In my signed library assemblies, I use a fixed
assembly version (I don't use the "*" syntax that generates version numbers
on the fly). I hoped that once I had built my signed libraries, then built
all of the referencing programs, I could then come back and rebuild the
libraries *without* having to rebuild the referencing programs. The strong
named references held by the programs would still work (since the assembly
names, versions, and public key tokens are unchanged), and, as long as the
code changes are limited to code that runs in the singleton, the referencing
apps shouldn't care that the assembly that they bind to differs from the
assembly that the singleton binds to.
Unfortunately, it turns out that Plan C doesn't work. If I don't rebuild
the referencing apps, I get a variety of fatal errors when I try running
them, ranging from straightforward binding failure ("can't load assembly xxx
or an assembly that it references") to more bizarre confusion about what
types implement what interfaces.
So... I've settled on Plan D, which is to set things up like Plan C and to
rebuild all of the apps (or at least to copy the library assemblies to the
app folders) each time I rebuild the library assemblies.
Does this story make sense? Is there an easier way to work with multiple
solutions in a development environment where one of the solutions includes
strong named assemblies?
This gets me back to the original question. I have a command file that
builds all of my solutions. Whenever I build my library project and the
build process modifies any of the signed assemblies then I want to kick off
that command file after the build completes.
So, if you agree that I'm on the right track then I'd greatly appreciate
details on how to do this using VS macros. If there is an easier way to
lash up my signed libraries and the referencing applications then I'm happy
to do that instead!
TIA - Bob
