I just upgraded to Castle Core v4.2.0 and I am getting an assembly binding error

[ghost]

I just upgraded Castle.Core from v4.1.1 to v4.2.0 and got an assembly binding error. Why is this happening?

[ghost]

This is because Castle Core changed the AssemblyVersion attribute to only include major version numbers only so that we can avoid assembly binding errors with future releases/upgrades of Castle Core.

Why is the assembly binding error happening then?

This is because FakeItEasy have to release a version compiled against the new AssemblyVersion strategy, they are on it! :)

What do I do in the meantime? I want Castle Core bug fixes.

You can apply this following assembly binding redirect in your App.config.

 <dependentAssembly>
    <assemblyIdentity name="Castle.Core" publicKeyToken="407dd0808d44fbdc" culture="neutral" />
    <bindingRedirect oldVersion="0.0.0.0-999.999.999.999" newVersion="4.0.0.0" />
  </dependentAssembly>

Are you using Castle Core features directly?

If not and you are using the latest version of Visual Studio (15.3.5) then you should probably remove the NuGet reference altogether along with it's assembly bindings. This means Castle Core becomes a transitive dependency which you should not have to worry about.

Are you guys versioning properly at all?

Yes we are, we just use the AssemblyFileVersion instead.

I am still having issues.

Please post to this issue and we will try to help you.

[ghost]

castleproject/Core#306

[thomaslevesque]

@fir3pho3nixx thanks for the information. I don't think this is a problem for FakeItEasy when using the net40/net45 assemblies, because for .NET Framework, Castle.Core is ILMerged into FakeItEasy. It could be an issue when using the .NET Standard version, though. We'll need to release a new version that references Castle.Core 4.2.0.

Keeping the AssemblyVersion unchanged for the whole life of a major version is probably the right thing to do; JSON.NET has been doing this for a while, which greatly reduced assembly binding issues. We should probably consider doing the same in FakeItEasy. However, although I understand @jonorossi's desire to "keep v5 for something meaningful", I think this change should have been made in a major version, because it's a breaking change.

[ghost]

@thomaslevesque - I understand. Started a discussion with the coreclr team to understand if the conditions under which a file load exception gets thrown will be relaxed in the future. Hopefully it will go somewhere. Want me close this out?

[thomaslevesque]

@fir3pho3nixx yes, I saw this discussion and subscribed to it. Let's see what comes from it.

I'll close this issue. Thanks!