I have a .NET application that seems to have some of its dependency versions change between debugging and running as an installed release app. I'll just focus on the Castle.Core assembly for my details, but the same issue occurs with a couple others as well. A NuGet package I'm using requires Castle.Core as a dependency (all cases of my issue are related to assemblies originating from NuGet, in case it matters).
In Visual Studio, when I install the NuGet package with the Castle.Core dependency, everything runs just fine, both in Debug and Release configurations. I can see that the Castle.Core project reference is referencing version 3.3.0.0. However, when I package everything generated by the Release configuration using InstallShield and install the application (with all assemblies living in the same program dir), I get this runtime error:
Could not load file or assembly 'Castle.Core, Version=3.2.0.0, Culture=neutral, PublicKeyToken=407dd0808d44fbdc' or one of its dependencies. The located assembly's manifest definition does not match the assembly reference. (Exception from HRESULT: 0x80131040)
The NuGet package lists its dependency on Castle.Core as (≥3.2.0.0 && < 4.0.0.0). Both 3.2.0.0 and 3.3.0.0 satisfy those conditions.
If I manually downgrade Castle.Core to 3.2.0.0, my project's reference shows that it has indeed downgraded. But when I run the project in Visual studio, I get:
Could not load file or assembly 'Castle.Core, Version=3.3.0.0, Culture=neutral, PublicKeyToken=407dd0808d44fbdc' or one of its dependencies. The located assembly's manifest definition does not match the assembly reference. (Exception from HRESULT: 0x80131040)
with an inner exception of:
Could not load file or assembly 'Castle.Core, Version=3.2.0.0, Culture=neutral, PublicKeyToken=407dd0808d44fbdc' or one of its dependencies. The located assembly's manifest definition does not match the assembly reference. (Exception from HRESULT: 0x80131040)
However, if I then package it into an installer and launch it as an installed application, it works.
To me, it feels like the act of packaging the assemblies into an installer is causing the dependency versions to change. I can't imagine that to be the case, but I'm having trouble coming up with a better explanation.
Can anyone explain what's happening here and how I might fix it?
Ok, figured it out. First, facepalm
The assembly added via NuGet has a specific version dependency on Castle.Core 3.2.0. However, because that assembly can still work with Castle.Core 3.2.0-4.0.0, an assembly binding redirect got added to App.config that indicates to the assembly loader that any assemblies requiring a version in that range should try to load Castle.Core 3.3.0, which is the version that gets packaged in my app installer. I didn't realize that I had failed to include the config file in my installer, so the config got loaded in by Visual Studio without issue, while the installed app was missing that file in the app dir.
I had same issue, I just downgraded to least Moq version available and it worked.
来源：https://stackoverflow.com/questions/30944260/assembly-dependencies-change-after-installation