Update AssemblyVersion with each release

[mlsiebert]

I use Autofac in projects that are loaded into a host application as plug-ins, and there are other plug-in vendors who also use Autofac.

The host application doesn't isolate plug-ins into separate AppDomains, and since Autofac's AssemblyVersion doesn't get updated with each release (and hence the assembly's strong name doesn't change) we run into problems when different plug-ins depend on different versions of Autofac.

Any chance you could change your versioning strategy so that the AssemblyVersion gets updated with each release?

[tillig]

The intent of the slow-changing assembly versioning was actually to avoid situations like this - where assembly binding redirection can be a pain.

That said, I could potentially see switching slightly such that for a 0.0.1 level change (backwards-compatible bug fixes) we leave the assembly version as-is, but for a 0.1.0 or 1.0.0 level change (new functionality or breaking changes) we update the assembly version accordingly. Still fairly slow version changes, but fast enough that issues like this could be (mostly) avoided.

[mlsiebert]

That should work fine. The key is that if the assembly version doesn't change then it should be backwards compatible, and if it's not backwards compatible then the version must change.

Is there any chance this could be changed soon? I've been working on a new project and I'm hoping to deploy it next week with an Autofac build that won't have issues with other plug-ins that are already out in the wild.

[tillig]

I think we could change it for the next release, but I don't think we'd release all new packages just for the sake of changing the assembly version number; you'd see the changes roll out as fixes for things get published.

[mlsiebert]

I understand, but I would argue that it's not just for the sake of changing the assembly version number - it's to resolve an issue (albeit for a very specific scenario).

[alexmg]

Do you have some examples of the kinds of issues you have run into? If we change the assembly version on minor releases the result will be binding redirects and they can also cause plenty of problems.

[mlsiebert]

I've created a sample project that demonstrates my scenario (download from here).

There's a host application that loads two plugins. In the real scenario the host application is from another vendor and I have no control over it. It uses XML files to discover plugins at runtime. The plugins would also be from different vendors. One of the plugins depends on Autofac 3.1.5 and the other depends on 3.3.0.

If 3.1.5 is loaded first, then when the 3.3.0 plugin's code is executed we get a TypeLoadException: Could not load type 'Autofac.ModuleRegistrationExtensions' from assembly 'Autofac, Version=3.0.0.0, Culture=neutral, PublicKeyToken=17863af14b0044da'.

If 3.3.0 is loaded first, then when the 3.1.5 plugin's code is executed we get a MissingMethodException: Method not found: 'Void Autofac.RegistrationExtensions.RegisterModule(Autofac.ContainerBuilder)'.

[tillig]

I've run into similar issues myself with slow-versioning assemblies. I think a decent compromise is the "only-change-for X.Y level changes, but not for X.Y.Z". With NuGet handling assembly binding redirects in the config now, resolving that stuff is much more automated than it used to be.

[tillig]

Updated PackageVersions.proj so the assembly version will match the major/minor of the semantic version but file version will still be exactly the semantic version (major/minor/patch). This should be out for next time we release each package.

[tillig]

Looks like we have to issue new 0.0.1 versions for everything due to this change anyway since releasing one package will require, in many cases, a later version of a dependency to be available than has previously been published (e.g., Autofac 3.3.0.0 will be required but only Autofac 3.0.0.0 will be available).

Found this during research on issue #508.

[tillig]

I just pushed all new packages with the updated assembly versions.

[cecilphillip]

I might be missing something here, but this is what's happening to me recently. Have an internal nuget repo with packages that depend on 3.1.1. Installed packages into a project and updated project to autofac 3.3.1. Nuget added:

 <assemblyIdentity name="Autofac" publicKeyToken="17863af14b0044da" culture="neutral" />
 <bindingRedirect oldVersion="0.0.0.0-3.3.0.0" newVersion="3.3.0.0" />

and now I'm getting

[MissingMethodException: Method not found: 'Void Autofac.RegistrationExtensions.RegisterAssemblyModules(Autofac.ContainerBuilder, System.Reflection.Assembly[])'.] 

Reverting back to 3.1.1 and removing the redirect fixes the issue. Could this be related?

[tillig]

In this case, no, the problem you're seeing is due to the resolution of issue #474. Between 3.1.1 and 3.3.1 we changed where some extension methods were for module registration, which means stuff compiled against an older version (before the switch) needs to be recompiled so the extension methods can be located. No actual code change required, just recompile.

That issue was sort of a learning experience around what constitutes a breaking change when it comes to extension methods. It's not quite as "dynamically wired up" as I thought it was.

Anyway, recompile and you'll be fine; it's not the assembly versioning getting you.