"Marc Gravell" <ma**********@gmail.comwrote in message
news:OJ**************@TK2MSFTNGP05.phx.gbl...
Pin the assembly version numbers? As long as the key (assuming strong
named), version, name and culture of each match what is expected, then the
app should be happy to use the old version of A, and A should be happy to
use the new version of B.
Hi Marc, thanks for the reply. I just gave it a try using 3 test projects.
It all works fine by standard anyway with the only side effect I can notice
that it gives a warning when compiled. This on it's own is probably an
acceptable solution as I can put up with the warnings during developement
and then compile everything before release. In this regard it's probably
good even to leave it as it is so i've got the warnings to reming me.
But I can help tinkering .... I've given B a strong name, compiled it and
re-added B to both A and the exe. From the 4 things you mentioned, strong
name, name and culture remain the same but I would like the version to
change which is still causing the warning to appear. Is there any way to
resolve that but allow the version to still increment?
If GACd you can also use policy to forward the versions, but that can get
very complex and messy. You can always just use version numbers in the
AssemblyFileVersion (IIRC), which means you can pin the assembly version
(e.g. 1.2.0.0) while the file-version can change to suit.
All of the dlls are not in the GAC.
Michael