Dynamic Proxy integration 4.3.0 doesn't work with Castle.Core 4.2.1

[MonkSoul]

No description provided.

[tillig]

Can you provide a bit more info here? Is there an error message? Some reproduction you can show to illustrate the problem?

[hikalkan]

I'm getting this exception for registrationBuilder.EnableClassInterceptors() method.

Message: System.IO.FileNotFoundException : Could not load file or assembly 'Castle.Core, Version=4.1.0.0, Culture=neutral, PublicKeyToken=407dd0808d44fbdc'. The system cannot find the file specified.

I'm using Castle.Core v4.2.1 as shown in the image above.

[tillig]

You may need to add an assembly binding redirect to your app.config. NuGet sometimes misses that.
https://docs.microsoft.com/en-us/dotnet/framework/configure-apps/redirect-assembly-versions

[hikalkan]

I've already <AutoGenerateBindingRedirects>true</AutoGenerateBindingRedirects> in my csproj file.

[hikalkan]

Even adding this didn't help:

  <runtime>
    <assemblyBinding xmlns="urn:schemas-microsoft-com:asm.v1">
      <dependentAssembly>
        <assemblyIdentity name="Castle.Core" publicKeyToken="407dd0808d44fbdc" culture="neutral" />
        <bindingRedirect oldVersion="0.0.0.0-4.2.1.0" newVersion="4.2.1.0" />
      </dependentAssembly>
    </assemblyBinding>
  </runtime>

Getting the exception on runtime, it's not a build problem. So, it may not be related to nuget.

[tillig]

Binding redirects are a runtime thing (note the runtime element).

Is there a small repro project I can see?

[tillig]

Also, have you tried clearing cached items like the .vs folder? That can sometimes help.

[hikalkan]

Yes, I cleared it. I also published it and run under IIS to see the difference. Result is same.

Is there a small repro project I can see?

No, but nice idea, I can try with a simpler test project when I have time.

[tillig]

I was able to repro this in a small console app. Unclear why it's popping up yet or what to do about it, but at least I see it.

[tillig]

OK, it turns out this is a Castle.Core problem. TL;DR: They wanted to switch from changing their assembly version strategy so it's pinned at 4.0.0.0... but they did that after having released 4.1.0.0. As of Castle.Core 4.2.0, the Castle.Core package version changes but the assembly version doesn't. And they chose to go backwards to 4.0.0. assembly version instead of stopping at 4.1.0.0 and pinning there... or restarting at 5.0.0.0.

• Castle.Core having minor and patch level version in AssemblyVersion castleproject/Core#288
• I just upgraded to Castle Core v4.2.0 whilst using Moq v4.7.127 and I am getting an assmbly binding error castleproject/Core#307

What a nightmare.

I guess the right way to handle this is to update to 4.2.1 here so the bound assembly version lines up...? This is going to be a nightmare of trickle down problems. Sigh. But I can't see any way around it. Really wish they hadn't done that without incrementing the major version.

[hikalkan]

OMG! Then upgrading dependency to 4.2.1 seems the best way.

[tillig]

I released v4.4.0 of Autofac.Extras.DynamicProxy that uses Castle.Core 4.2.1. I also added docs about this issue. That's the best I can do from this end.

For folks hitting this in the future, I recommend taking it up with the Castle.Core crew. This is out of the control of Autofac.

[hikalkan]

Thank you @tillig for fast reaction. I just tested and it worked :)

[alexmg]

Nice work @tillig. I've updated Autofac.ServiceFabric to this new release. 👍