Assembly Versions
Packaging assemblies is always a pain in the rear. More so when you are doing it without being one of the developers. On the #debian-mono channel, I got into a discussion about how to handle breaking stuff. One of the things that came out of that inclusive thing is how to map versions to other versions.
The main part is if you have version 1.2.9 and 1.2.10. Files linked to 1.2.9 won't work if you uninstall it for 1.2.10. You can create a policy file to get around this, though, which works out very nicely.
<assemblyBinding xmlns="urn:schemas-microsoft-com:asm.v1"> <dependentAssembly> <assemblyIdentity name="bob" publicKeyToken="0499830f33a4a9f7" /> <bindingRedirect oldVersion="1.2.9.0-1.2.9.9" newVersion="1.2.10.0" /> </dependentAssembly> </assemblyBinding>
This basically has anything in the 1.2.9.* range actually use 1.2.10.0. Obviously, you need to version your file when you do this. To create the policy, you do this:
al /link:b.policy /out:policy.1.2.bob.dll /keyfile:bob.snk gacutil /i policy.1.2.bob.dll
The "1.2" is important. "1.2.9" won't work and "1" won't work either. Of course, that means you have a couple nasty options. As an assembly writer, you really should have breaking changes be in the first two version numbers (x.y) because you can't easily create a policy that changes half-way. If version 1.2.9 has a policy for 1.2.0.0 to 1.2.8.9, then 1.2.10 breaks things, then later you have 1.2.12 that replaces .10, then you'd have to have two policies.
Now, you can get around this by changing SNK files every time you break something. The policy is based on that, but it would require you do remember to actually test for breakage, then change your key, if you insist on doing a x.y.z breaking change. If you stick with x.y breaking changes (or my preference of x), then the package builders can do something easily (without changing the key).
Metadata
Categories:
Tags: