Reference assembly version mismatch

Question

I am trying to do a demo for Fusion Log Viewer, wanting to view the Assembly Bind Logs in a custom directory.

I just created a small demo application for this as follows:

A small class library project containing just one method GetString() and set assembly version as 1.0.0.0

namespace ClassLibrary1
{
    public class Class1
    {
        public static string GetString()
        {
            return "yes";
        }
    }
}
[assembly: AssemblyVersion("1.0.0.0")]
[assembly: AssemblyFileVersion("1.0.0.0")]

A small console application project referencing the above library and having the following code:

References ClassLibrary1.dll Version 1.0.0.0

namespace ConsoleApplication1
{
    class Program
    {
        static void Main(string[] args)
        {
            Console.WriteLine(ClassLibrary1.Class1.GetString());
            Console.ReadLine();
        }
    }
}

I build this console application and close the visual studio and then run the executable. It prints 'yes' as expected.

Then, I upgrade the ClassLibrary1's AssemblyInfo as follows to change its version number to 2.0.0.0:

[assembly: AssemblyVersion("2.0.0.0")]
[assembly: AssemblyFileVersion("2.0.0.0")]

After replacing the library inside console application with this version 2.0, and running the executable again, it still works and prints 'yes'.

Why is it still working when the referenced DLL doesn't exist in it? The expectation should be creation of an Assembly Bind Log failure inside the Fusion Log Viewer's custom directory.

Can any one explain, why is it still working?

If I just delete the ClassLibrary1.dll from ConsoleApplication's bin though, then I get a new entry for its bind failure log in Assembly Bind Log Viewer. — , Apr 03 '14 at 12:02
As a test, change the string to "no" in v2. Also try with different .NET versions, I believe it might be something new in .NET 4.5. Lastly, try the reverse, compile with v2 and reference v1. http://msdn.microsoft.com/en-us/library/2fc472t2(v=vs.110).aspx — leppie, Apr 03 '14 at 12:03
You have to be careful that the console app doesn't get rebuilt. It will if you have both projects in one solution. If you keep it in a separate solution then the .dll file will not get copied to the console app's bin\Debug directory. Something you can see with Fuslogvw.exe if you log all the binds :) — Hans Passant, Apr 03 '14 at 19:30
What is the need of rebuilding the Console Application, I have built it just once referencing 1.0 version of the DLL, and then without touching console app solution, I create a new version of the referenced dll and replace the bin\debug of console with my new version, while it's project file must still be referencing the old one. It should now not work, but it works. — , Apr 04 '14 at 04:52
Possible duplicate of [Assembly Loading Version Mismatch: Why is it loading?](https://stackoverflow.com/questions/5883489/assembly-loading-version-mismatch-why-is-it-loading) — riQQ, Jun 25 '18 at 19:07
I think specific versions are only enforced for strong named assemblies. — vyrp, Nov 23 '20 at 11:28

score 0 · Answer 1 · edited May 23 '17 at 10:31

... copying my answer for essentially the same question here: Assembly Loading Version Mismatch: Why is it loading?...

I've faced the same thing and tried to look into the msbuild logs:

msbuild /v:detailed /t:build

The following lines looked interesting:

Unified Dependency "Newtonsoft.Json, Version=8.0.0.0, Culture=neutral, PublicKeyToken=30ad4fe6b2a6aeed". Using this version instead of original version "7.0.0.0" in "C:\src\BindingTest\Lib1\bin\Debug\Lib1.dll" because AutoUnify is 'true'.

Additionally, If you check out resulting app.config file after the build, you would probably see automatic binding redirect there that your app.config did not initially have.

So the behavior we observe has to do with "automatic assembly unification" and "automatic binding redirection" msbuild processes.

Here is what documentation says about AutoUnify parameter:

When true, the resulting dependency graph is automatically treated as if there were anApp.Config file passed in to the AppConfigFile parameter. This virtual App.Config file has a bindingRedirect entry for each conflicting set of assemblies such that the highest version assembly is chosen. A consequence of this is that there will never be a warning about conflicting assemblies because every conflict will have been resolved.

When true, each distinct remapping will result in a high priority comment showing the old and new versions and that AutoUnify was true.

Finaly, if you want to observe the "failure" you can call msbuild with following arguments:

msbuild /v:d /t:build /p:AutoUnifyAssemblyReferences=false;AutoGenerateBindingRedirects=false

Reference assembly version mismatch

1 Answers1