Strong name key version required

[sawilde]

Do you have (or intend) to strong name the assembly - it would really help its adoption as quite a few places have strong naming as a requirement?

[gimelfarb]

Hi @sawilde,

Thanks for the suggestion - I must say I didn't consider it. You are right it can help with projects where strong naming is a requirement.

I know there are issues with strong-named assemblies and NuGet. Mainly because changing a version number is a pain. Log4net users found out about it the hard way. So did Json.NET.

I considered an approach mentioned here, which creates a strong-named parallel package. But that means 2 different versions out there doing the same things .... Doesn't seem very DRY to me.

Guess my only option to support strong names is to fix the assembly version to some number, which shall only change on a backward-incompatible release.... Let me marinate on this for a little bit.

What are you doing right now? Something like this?

[sawilde]

What are you doing right now? Something like this?

we did look at that package but instead we are using ildasm (3 line script) and saving the assembly to one side - not very nuget-ty but it suffices whilst we spike.

... which shall only change on a backward-incompatible release.... Let me marinate on this for a little bit.

That is what we do and when we have strong name issues but the assembly if backwardly compatible we have used assembly redirection in the config files.

I'd say fix the assembly version until you make a breaking change then only change the minor version if backward compatible, change the major version number if not backward compatible and keep the file/nuget versions in sync (helps with diagnosing issues - also installers use file version for comparison)