I'm not clear on what you mean "follow the rules and information on
versioning of .Net assemblies". All the rules I've seen on versioning refer
to versioning changing in conjunction with changes to the assembly's code.
These changes are generally catagorized as major or minor changes based on
changes to code and/or interfaces etc. I'm not aware of versioning rules
that might apply to compiling open source with your private/public key.

I should make clear that I would also be trying to make currently deployed
assemblies with references to the previous assembly version bind to my
new "version". Everything should function properly during run-time as no
code actually changed in a re-compiled and re-signed version.

If a newly compiled assembly's version is left the same as the previous
assembly's version an existing dependant assembly already deployed to a
server that has been bound against the existing "version" of the open
source assembly should not succeed. The public key will be different than
the open source original assembly's key. This is why I wonder if a binding
redirect based on a new/different key can be used in this scenario.

As far as I know, without an explicit binding redirect, GAC'd assemblies
will only load the exact version they were built against. I assume this
applies to key too. Further, binding redirects are dependant upon: 1. The
policy assembly's name must embed the redirected assembly's name. 2. The
policy assembly's major and minor versions must match the version of
the "redirected to assembly". 3. The "redirected to assembly's" public key
which is specified in the redirect's config must match the "redirected to
assembly" key.

e.g.
Policy.1.0.OpenSourceLibrary.dll

As far as I know (without mucking with the assembly's IL) I can't resign it
with the open source's private/public key.

Can you elaborate? Am I making this too hard? What I'm I missing?

===================================
This list is hosted by DevelopMentorĀ®  http://www.develop.com

View archives and manage your subscription(s) at http://discuss.develop.com

Reply via email to