I get a file loader exception (first chance) at the InitializeComponent-method or the debugger breaks at the x:Class attribute of the xaml-root of multiple WPF user controls. Everything works fine despite the fact that the exceptions slow down navigation by a lot.
This is the exception message:
Could not load file or assembly 'Company.Solution.UserInterface, Version=0.1.5568.25577, Culture=neutral, PublicKeyToken=45069ab0c15881ce' or one of its dependencies. The located assembly's manifest definition does not match the assembly reference. (Exception from HRESULT: 0x80131040)
This is the Fusion log:
Assembly manager loaded from: C:\Windows\Microsoft.NET\Framework\v4.0.30319\clr.dll
Running under executable D:\Development\Product\Main\src\Company.Product \bin\Debug\Product.vshost.exe
--- A detailed error log follows.
=== Pre-bind state information ===
LOG: DisplayName = Company.Product .UserInterface, Version=0.1.5568.25577, Culture=neutral, PublicKeyToken=45069ab0c15881ce
(Fully-specified)
LOG: Appbase = file:///D:/Development/Product/Main/src/Company.Product/bin/Debug/
LOG: Initial PrivatePath = NULL
Calling assembly : PresentationFramework, Version=4.0.0.0, Culture=neutral, PublicKeyToken=31bf3856ad364e35.
LOG: This bind starts in default load context.
LOG: Using application configuration file: D:\Development\Product \Main\src\Company.Product \bin\Debug\Product .vshost.exe.Config
LOG: Using host configuration file:
LOG: Using machine configuration file from C:\Windows\Microsoft.NET\Framework\v4.0.30319\config\machine.config.
LOG: Post-policy reference: Company.Product .UserInterface, Version=0.1.5568.25577, Culture=neutral, PublicKeyToken=45069ab0c15881ce
LOG: Attempting download of new URL file:///D:/Development/Product/Main/src/Company.Product/bin/Debug/Company.Product.UserInterface.DLL.
WRN: Comparing the assembly name resulted in the mismatch: Revision Number
ERR: Failed to complete setup of assembly (hr = 0x80131040). Probing terminated.
My project structure has a root project that references a module project (in which the exception occurs). The module project itself references the project that is the target of the above mentioned probing "Company.Product.UserInterface.dll" which contains some resources / controls / styles / primitives / converters and so on.
How can I get rid of the FileLoadExceptions?
Another more complete Fusion-log:
=== Pre-bind state information ===
LOG: DisplayName = Company.Product.UserInterface, Version=0.1.5577.18122, Culture=neutral, PublicKeyToken=45069ab0c15881ce
(Fully-specified)
LOG: Appbase = file:///D:/Development/Product/Main/src/Company.Product/bin/Debug/
LOG: Initial PrivatePath = NULL
LOG: Dynamic Base = NULL
LOG: Cache Base = NULL
LOG: AppName = Product.vshost.exe
Calling assembly : PresentationFramework, Version=4.0.0.0, Culture=neutral, PublicKeyToken=31bf3856ad364e35.
LOG: This bind starts in default load context.
LOG: Using application configuration file: D:\Development\Product\Main\src\Company.Product\bin\Debug\Product.vshost.exe.Config
LOG: Using host configuration file:
LOG: Using machine configuration file from C:\Windows\Microsoft.NET\Framework\v4.0.30319\config\machine.config.
LOG: Post-policy reference: Company.Product.UserInterface, Version=0.1.5577.18122, Culture=neutral, PublicKeyToken=45069ab0c15881ce
LOG: GAC Lookup was unsuccessful.
LOG: Attempting download of new URL file:///D:/Development/Product/Main/src/Company.Product/bin/Debug/Company.Product.UserInterface.DLL.
LOG: Assembly download was successful. Attempting setup of file: D:\Development\Product\Main\src\Company.Product\bin\Debug\Company.Product.UserInterface.dll
LOG: Entering run-from-source setup phase.
LOG: Assembly Name is: Company.Product.UserInterface, Version=0.1.5577.18123, Culture=neutral, PublicKeyToken=45069ab0c15881ce
WRN: Comparing the assembly name resulted in the mismatch: Revision Number
ERR: The assembly reference did not match the assembly definition found.
ERR: Run-from-source setup phase failed with hr = 0x80131040.
ERR: Failed to complete setup of assembly (hr = 0x80131040). Probing terminated.
At the moment the exception occurs the version of the assembly in the SolutionExplorer referenced is 0.1.5577.18123 (in all solutions that reference the ..UserInterface.dll. I have no idea who looks up 0.1.5577.18122, this version did never exist)
If I run a new rebuild all I get the same error, Fusion looks for (I never had this version number):
LOG: Post-policy reference: Company.Product.UserInterface, Version=0.1.5577.18465, Culture=neutral, PublicKeyToken=45069ab0c15881ce
the version found is:
LOG: Assembly Name is: Company.Product.UserInterface, Version=0.1.5577.18466, Culture=neutral, PublicKeyToken=45069ab0c15881ce
Visual Studio Version is 2013 Ultimate, and the project is build on .net4.5 and the assembly versions are auto generated in the build process.
I uploaded the build log to tinyupload as it was too big.
The full Fusion-log can be found here at pastebin.
Version=0.1.5577.18122
This auto-generated version number tells a tale, the last two parts of the version number are not arbitrary. They are based on the date and time the assembly was built. The build number is generated from the number of days since Jan 1st, 2000. The revision number is the number of seconds*2 since midnight without daylight savings correction.
So facts we know is that the 18122 assembly was built on March 30th at 2:12:34 in the afternoon. And then it got built again, 2 seconds later at 2:12:36 in the afternoon. After it was used as a reference assembly to build another project, that made the CLR spit bullets.
This should not happen, a project must be built only once in a single build session. Finding out why this happened requires digging through the MSBuild trace. You generate the one you need with Tools + Options, Projects and Solutions, Build and Run. Change the "MSBuild project build output verbosity" setting to Detailed. MSBuild now gets very chatty and tells you why it decided to build a project. If you get lost in the woods trying to decode its output (there's a lot of it) then copy/paste it in a paste-bin and link to it in your question.
There are otherwise not that many great explanations for a mishap like this. Older VS versions made it too easy to accidentally create a circular dependency between projects. You flush that out by using Build + Clean. Rebuilding the solution now fails and tells you which reference assembly is the troublemaker. You are using .NET 4 however, so at least VS2010. So not a fantastic lead, Microsoft added more checks to prevent this from happening without a warning. Not sure if it is reliable in all cases, it could be fooled if you don't depend on MSBuild alone for example. Not uncommon on build servers with "continuous integration" features.
We need the build trace to give you a reliable diagnostic.
Suggestion 1
Is there a cyclic reference causing an old version of the dll to be loaded? (this was proven not to be the point but I have left in for historical reasons).
Relating to this answer
Suggestion 2
Can you try creating a Publisher Policy?
Here is an example that needs to be added to your app.config file.
<runtime>
<assemblyBinding xmlns="urn:schemas-microsoft-com:asm.v1">
<dependentAssembly>
<assemblyIdentity name="Company.Solution.UserInterface"
publicKeyToken="45069ab0c15881ce"
culture="en-us" />
<!-- Redirecting to version 0.1.5568.25577 of the assembly. -->
<bindingRedirect oldVersion="0.0.0.0-0.1.5568.25577"
newVersion="0.1.5568.25577"/>
</dependentAssembly>
</assemblyBinding>
</runtime>
Explained in further detail here
Suggestion 3
Has anything changed with regards to the key that is being used to sign your assemblies?
Suggestion 4
As a slight adaption of my initial suggestion. You have stated that there are 3 projects that reference Company.Solution.UserInterface. Can you confirm that all 3 projects are referencing the same version of that assembly?
Related
We are having an issue related to starting a few in house developed .NET applications on Windows 10 Version 1607 machines. Sometimes starting an application doesn't succeed. This is because loading a dependent .NET assembly fails. The error message is:
System.IO.FileLoadException: Could not load file or assembly
'[assemblyname], Version=[version], Culture=neutral,
PublicKeyToken=[publickeytoken]' or one of its dependencies. The data
area passed to a system call is too small. (Exception from HRESULT:
0x8007007A)
The issue happens about 10% of the application startups in different .NET applications. It happens with 32-bit as well as 64-bit applications. During all the startups also many other applications start that start up OK. I wonder why we get the 0x8007007a error? Maybe it is collateral due to a heap corruption that happened before?
You can see related logging from FUSLOGVW below. The filepaths and assembly names are anonymised. The assembly that is attempted to be loaded has quite a long name (59 characters without the .dll postfix). As a test, we changed the name of the assembly to a shorter name. Unfortunately the issue remained. Adding a probing path in the exe.config also did not fix the issue.
Furthermore, there seems to be code of an older version of the Microsoft Assembly Resolver available at Github: https://github.com/fixdpt/shared-source-cli-2.0. I suspect there is something wrong in the ConstructCodeBaseList in adlmgr.cpp. But I can't figure out what triggers the issue.
*** Assembly Binder Log Entry (2020/01/30 # 13:48) ***
The operation failed.
Bind result: hr = 0x8007007a. The data area passed to a system call is too small.
Assembly manager loaded from: C:\Windows\Microsoft.NET\Framework\v4.0.30319\clr.dll
Running under executable C:\Program Files (x86)\XXX\XXX\XX.X.X.X\XXX\XXXXXXXXXXXXXX\ApplicationWeWantToStart.exe
--- A detailed error log follows.
=== Pre-bind state information ===
LOG: DisplayName = AnAssem.blyWi.th.AVeryLon.gNameAA.AAAAAAAA.AAAAAAAAAAA.AAAA, Version=13.0.0.0, Culture=neutral, PublicKeyToken=XXXXXXXXXXXXXXXX
(Fully-specified)
LOG: Appbase = file:///C:/Program Files (x86)/XXX/XXX/XX.X.X.X/XXX/XXXXXXXXXXXXXX/
LOG: Initial PrivatePath = NULL
LOG: Dynamic Base = NULL
LOG: Cache Base = NULL
LOG: AppName = ApplicationWeWantToStart.exe
Calling assembly : ApplicationWeWantToStart, Version=13.0.0.0, Culture=neutral, PublicKeyToken=XXXXXXXXXXXXXXXX.
===
LOG: This bind starts in default load context.
LOG: Using application configuration file: C:\Program Files (x86)\XXX\XXX\XX.X.X.X\XXX\XXXXXXXXXXXXXX\ApplicationWeWantToStart.exe.Config
LOG: Using host configuration file:
LOG: Using machine configuration file from C:\Windows\Microsoft.NET\Framework\v4.0.30319\config\machine.config.
LOG: Post-policy reference: AnAssem.blyWi.th.AVeryLon.gNameAA.AAAAAAAA.AAAAAAAAAAA.AAAA, Version=13.0.0.0, Culture=neutral, PublicKeyToken=XXXXXXXXXXXXXXXX
LOG: GAC Lookup was unsuccessful.
ERR: Error occurred constructing the probing codebase list.
ERR: Unrecoverable error occurred during pre-download check (hr = 0x8007007a).
Any change your startup issue may be related to this Microsoft Support Link
I have a WPF application that follows the MVVM pattern. We recently signed the app and now I am getting a lot of first chance exceptions on startup. I have traced the problem to the following:
In any view, if I reference another namespace with in the application when the view is initialized I get the error:
"Could not load file or assembly 'MyApplication, Version=3.0.5917.24348, Culture=neutral, PublicKeyToken=xxxxxxxxxxxx' or one of its dependencies. The located assembly's manifest definition does not match the assembly reference. (Exception from HRESULT: 0x80131040)":"MyApplication, Version=3.0.5917.24348, Culture=neutral, PublicKeyToken=xxxxxxxxxxx"
Its always looking for a version that is 1 behind the version that I'm actually running.
If I remove the references to the other namespaces from the views, the InitializeComponent() does not throw the error
View:
<UserControl x:Class="MyApplication.View.DiagnosticsView"
xmlns="http://schemas.microsoft.com/winfx/2006/xaml/presentation"
xmlns:x="http://schemas.microsoft.com/winfx/2006/xaml"
xmlns:mc="http://schemas.openxmlformats.org/markup-compatibility/2006"
xmlns:d="http://schemas.microsoft.com/expression/blend/2008"
xmlns:convert="clr-namespace:MyApplication.Converters" <!--Causes error-->
xmlns:behave="clr-namespace:MyApplication.Behaviors" <!--Causes error-->
xmlns:controls="clr-namespace:MyApplication.UserControls" <!--Causes error-->
If I remove these references, and move my converters and behaviors into another DLL and then reference them through the DLL there is no problem. The errors go away. Also If I don't sign the application I do not get the errors. I don't really want to have to reference these things in a different DLL, it seems like this should work fine. It also spends about 30 seconds throwing all of these errors as all of the views are created, so I am taking a hit on performance. I dont get why the application is trying to load itself, and why its trying to load an older version of itself. No matter how many times I build, the error is always 1 version behind.
Fusion Log:
*** Assembly Binder Log Entry (3/17/2016 # 10:30:11 AM) ***
The operation failed.
Bind result: hr = 0x80131040. No description available.
Assembly manager loaded from: C:\Windows\Microsoft.NET\Framework\v4.0.30319\clr.dll
Running under executable C:\tfs\Development\dev-feature\src\MyApplication\bin\Debug\MyApplication.exe
--- A detailed error log follows.
=== Pre-bind state information ===
LOG: DisplayName = MyApplication, Version=3.0.5920.15594, Culture=neutral, PublicKeyToken=xxxxxxxxxxxx
(Fully-specified)
LOG: Appbase = file:///C:/tfs/Development/dev-feature/src/MyApplication/bin/Debug/
LOG: Initial PrivatePath = NULL
LOG: Dynamic Base = NULL
LOG: Cache Base = NULL
LOG: AppName = MyApplication.exe
Calling assembly : PresentationFramework, Version=4.0.0.0, Culture=neutral, PublicKeyToken=31bf3856ad364e35.
===
LOG: This bind starts in default load context.
LOG: Using application configuration file: C:\tfs\Development\dev-feature\src\MyApplication\bin\Debug\MyApplication.exe.Config
LOG: Using host configuration file:
LOG: Using machine configuration file from C:\Windows\Microsoft.NET\Framework\v4.0.30319\config\machine.config.
LOG: Post-policy reference: MyApplication, Version=3.0.5920.15594, Culture=neutral, PublicKeyToken=7b0591cb18d2a932
LOG: GAC Lookup was unsuccessful.
LOG: Attempting download of new URL file:///C:/tfs/Development/dev-feature/src/MyApplication/bin/Debug/MyApplication.DLL.
LOG: Attempting download of new URL file:///C:/tfs/Development/dev-feature/src/MyApplication/bin/Debug/MyApplication/MyApplication.DLL.
LOG: Attempting download of new URL file:///C:/tfs/Development/dev-feature/src/MyApplication/bin/Debug/bin/MyApplication.DLL.
LOG: Attempting download of new URL file:///C:/tfs/Development/dev-feature/src/MyApplication/bin/Debug/bin/MyApplication/MyApplication.DLL.
LOG: Attempting download of new URL file:///C:/tfs/Development/dev-feature/src/MyApplication/bin/Debug/MyApplication.EXE.
LOG: Assembly download was successful. Attempting setup of file: C:\tfs\Development\dev-feature\src\MyApplication\bin\Debug\MyApplication.exe
LOG: Entering run-from-source setup phase.
LOG: Assembly Name is: MyApplication, Version=3.0.5920.15596, Culture=neutral, PublicKeyToken=7b0591cb18d2a932
WRN: Comparing the assembly name resulted in the mismatch: Revision Number
ERR: The assembly reference did not match the assembly definition found.
ERR: Run-from-source setup phase failed with hr = 0x80131040.
ERR: Failed to complete setup of assembly (hr = 0x80131040). Probing terminated.
Edit:
Did you use ProcessMonitor to see where Visual Studio is loading v 3.0.5917.24348 from? Visual Studio wants v3.0.5920.15596 so you have to put that DLL where its expected.
Edit 2:
Can you put in a binding redirect in your config file like this?
<dependentAssembly>
<assemblyIdentity name="xxxxxx" publicKeyToken="121fae78165ba3d4"/>
<bindingRedirect oldVersion="3.0.5920.15596" newVersion="3.0.5917.24348"/>
</dependentAssembly>
Ref: .Net picking wrong referenced assembly version
Original:
One reason you might get the error:
Could not load file or assembly 'MyApplication, Version=3.0.5917.24348, Culture=neutral, PublicKeyToken=xxxxxxxxxxxx' or one of its dependencies. The located assembly's manifest definition does not match the assembly reference.
Is when your assembly is signed and your reference to it has the Specific Version property set to True, resulting in FileLoadException.
Check you have Specific Version set to False:
Is it possible that you're trying to use strong-named URI references in your XAML? For example, by setting the AssemblyPublicKeyToken attribute your project file or by modifying the generated code-behind for the XAML?
If your XAML references are using a strong name and you use a constantly-changing version, then your XAML may end up using the previous version of the project, because the references are generated prior to the build being completed (and the new version being set).
To check, find your generated for your XAML under the obj directory and check for Uris (for example ~\obj\Debug\TestControl.g.i.cs):
System.Uri resourceLocater = new System.Uri("/T_Signing;V1.0.0.0;76005ee8ffcf5f2d;component/testcontrol.xaml", System.UriKind.Relative);
Above the URI has the full name and version. Whereas if you don't have strong named references, the uri would be more like:
System.Uri resourceLocater = new System.Uri("/T_Signing;component/testcontrol.xaml", System.UriKind.Relative);
Schema specified is not valid. Errors: (0,0) : error 0004: Could not
load file or assembly 'JIMSDAL, Version=6.0.5126.47, Culture=neutral,
PublicKeyToken=9054b539c49e6e2e' or one of its dependencies. The
located assembly's manifest definition does not match the assembly
reference. (Exception from HRESULT: 0x80131040)
Why I get this exception, I checked every dependent project of JIMSDAL and they are referencing the correct updated version 6.0.1.0.
I also checked with fuslogvw.exe and its not helping. It says
The operation failed.
Bind result: hr = 0x80131040. No description available.
Assembly manager loaded from: C:\Windows\Microsoft.NET\Framework64\v4.0.30319\clr.dll
Running under executable X:\yyyyy\Build\Debug\JIMS.vshost.exe
--- A detailed error log follows.
=== Pre-bind state information ===
LOG: DisplayName = JIMSDAL, Version=6.0.5126.47, Culture=neutral, PublicKeyToken=9054b539c49e6e2e
(Fully-specified)
LOG: Appbase = file:///X:/yyyyy/Build/Debug/
LOG: Initial PrivatePath = NULL
LOG: Dynamic Base = NULL
LOG: Cache Base = NULL
Calling assembly : EntityFramework, Version=6.0.0.0, Culture=neutral, PublicKeyToken=b77a5c561934e089.
===
LOG: This bind starts in default load context.
LOG: Using application configuration file: X:\yyyyy\Build\Debug\JIMS.vshost.exe.Config
LOG: Using host configuration file:
LOG: Using machine configuration file from C:\Windows\Microsoft.NET\Framework64\v4.0.30319\config\machine.config.
LOG: Post-policy reference: JIMSDAL, Version=6.0.5126.47, Culture=neutral, PublicKeyToken=9054b539c49e6e2e
LOG: GAC Lookup was unsuccessful.
LOG: Attempting download of new URL file:///X:/yyyyy/Build/Debug/JIMSDAL.DLL.
LOG: Assembly download was successful. Attempting setup of file: X:\yyyyy\Build\Debug\JIMSDAL.dll
LOG: Entering run-from-source setup phase.
LOG: Assembly Name is: JIMSDAL, Version=6.0.0.0, Culture=neutral, PublicKeyToken=9054b539c49e6e2e
WRN: Comparing the assembly name resulted in the mismatch: Revision Number
ERR: The assembly reference did not match the assembly definition found.
ERR: Run-from-source setup phase failed with hr = 0x80131040.
ERR: Failed to complete setup of assembly (hr = 0x80131040). Probing terminated.
There is no config file with this version too. I even removed the reference of this project and re added. But nothing works. Where am I going wrong?
That's not much to go by but the FSLogVw output shows the calling assembly to be EF. Are you using and edmx? If so, you may want to open it in XML view (not design view) and see if there are references to your assembly in there. You mentioned you've already checked the .config file, so that rules that out.
You are referencing JIMSDAL, Version=6.0.5126.47, but the calling assembly found JIMSDAL, Version=6.0.0.0. I've had this happen in the past when mixing project references with references to a compiled assembly, but there are other ways it can happen. Look for multiple references to JIMSDAL, and make sure they are all pointing to the same thing.
This question (https://stackoverflow.com/questions/5600904/net-dll-dependency-of-same-file) describes a similar problem, you might want to take a look.
And here's another question with some helpful suggestions: Project References DLL version hell
I'm having this weird revision mismatch error. All my NUnit test projects used to work with NUnit 2.5.7, but now that I switched them to using NUnit v2.5.10, I keep on getting the following error:
FileLoadException: Could not load file or assembly 'nunit.framework, version 2.5.7...
Note: I cleaned up, rebuilt, double checked the references, no problem there.
Using the Assembly Binder Log Viewer (see below), it seems to me that the trigger of this error is the Spring.Testing.NUnit.dll... which seems weird given that the Spring.Testing.Nunit 1.3.2 Nuget page says in its Dependency List: NUnit (≥ 2.5.7)
Any idea what I'm missing here?
Thanks in advance,
TB.
Assembly Binder Log Entry (02.07.2012 # 16:06:35)
The operation failed.
Bind result: hr = 0x80131040. No description available.
Assembly manager loaded from:
C:\Windows\Microsoft.NET\Framework64\v4.0.30319\clr.dll Running under
executable
F:\robin\4-Development\Workspace\3rdParty\NUnit\2.5.10\nunit-agent.exe
--- A detailed error log follows.
=== Pre-bind state information === LOG: User = Mth\tbourguignon LOG: DisplayName = nunit.framework, Version=2.5.7.10213,
Culture=neutral, PublicKeyToken=96d09a1eb7f44a77 (Fully-specified)
LOG: Appbase = file:///F:/robin/4-Development/Workspace/Application
LOG: Initial PrivatePath =
Rh.Robin.Common.Tests\bin\Debug;Rh.Robin.Service.Test\bin\Debug;Rh.Robin.Domain.Unit.Test\bin\Debug;Rh.Robin.Service.Unit.Test\bin\Debug;Rh.Robin.Web.UI.MVC.Unit.Test\bin\Debug
LOG: Dynamic Base = NULL LOG: Cache Base =
C:\Users\tbourguignon.Mth\AppData\Local\Temp\nunit20\ShadowCopyCache\4980_634768419945070499
LOG: AppName = Tests_29030132 Calling assembly : Spring.Testing.NUnit,
Version=1.3.2.40943, Culture=neutral, PublicKeyToken=65e474d141e25e07.
=== LOG: This bind starts in default load context. LOG: No application configuration file found. LOG: Using host configuration file: LOG:
Using machine configuration file from
C:\Windows\Microsoft.NET\Framework64\v4.0.30319\config\machine.config.
LOG: Post-policy reference: nunit.framework, Version=2.5.7.10213,
Culture=neutral, PublicKeyToken=96d09a1eb7f44a77 LOG: GAC Lookup was
unsuccessful. LOG: Attempting download of new URL
file:///F:/robin/4-Development/Workspace/Application/nunit.framework.DLL.
LOG: Attempting download of new URL
file:///F:/robin/4-Development/Workspace/Application/nunit.framework/nunit.framework.DLL.
LOG: Attempting download of new URL
file:///F:/robin/4-Development/Workspace/Application/Rh.Robin.Common.Tests/bin/Debug/nunit.framework.DLL.
LOG: Assembly download was successful. Attempting setup of file:
F:\robin\4-Development\Workspace\Application\Rh.Robin.Common.Tests\bin\Debug\nunit.framework.dll
LOG: Entering download cache setup phase. LOG: Assembly Name is:
nunit.framework, Version=2.5.10.11092, Culture=neutral,
PublicKeyToken=96d09a1eb7f44a77 WRN: Comparing the assembly name
resulted in the mismatch: Revision Number ERR: The assembly reference
did not match the assembly definition found. ERR: Setup failed with hr
= 0x80131040. ERR: Failed to complete setup of assembly (hr = 0x80131040). Probing terminated.
Did you gain anything from referencing a newer dot-version of NUnit? If not, the easiest thing you could do is go back and reference the older version of NUnit assemblies matching the version Spring is referencing in your code.
The other option is to modify your (Spring) application's configuration to use binding redirects to pick up the newer version of NUnit assemblies.
It makes me wonder if Spring's reference to NUnit's assembly had Specific Version set to true. Seems unlikely, though. Here's a reference on how .NET locates and binds assemblies at runtime.
Somehow I managed to solve this issue... but I still don't know what caused it. I did a major cleanup of the references, excluding all the NUnit references from my project, removing all the DLLs and reintroducing the new DLL only. I can only guess that a DLL was stuck somewhere and Spring was picking it up instead of the new one... wild guess though :(
When applying a binding redirect in the app.config of the test project. The runtime refuses to obey the redirect command and keeps searching for the old version of the assembly
<runtime>
<assemblyBinding xmlns="urn:schemas-microsoft-com:asm.v1">
<dependentAssembly>
<assemblyIdentity name="Msdcc.Common" publicKeyToken="9d9c15280f7f1425"/>
<bindingRedirect oldVersion="0.0.0.0-2.4.0.0" newVersion="2.4.0.0"/>
</dependentAssembly>
</assemblyBinding>
</runtime>
well i had heard about the default namespace creating problems(from a very wise man) so i added the "xmlns="urn:schemas-microsoft-com:asm.v1".
Tried running the test case still no go.
Opened up Fusion Log Viewer checked the problem and wonders of wonder it is till looking for the old dll.
The really helpfull message given below was deciphered using this post
http://msdn.microsoft.com/en-us/magazine/dd727509.aspx
*** Assembly Binder Log Entry (28/07/2010 # 18:59:36) ***
The operation failed.
Bind result: hr = 0x80131040. No description available.
Assembly manager loaded from: C:\WINNT\Microsoft.NET\Framework\v2.0.50727\mscorwks.dll
Running under executable C:\Program Files\Microsoft Visual Studio 9.0\Common7\IDE\devenv.exe
--- A detailed error log follows.
=== Pre-bind state information ===
LOG: User = BELGACOM\id820374
LOG: DisplayName = Msdcc.Common, Version=2.2.0.0, Culture=neutral, PublicKeyToken=9d9c15280f7f1425
(Fully-specified)
LOG: Appbase = file:///c:/data/source/explorev1/explore.root/explore/euc.explore.domainobjectstest/bin/debug
LOG: Initial PrivatePath = NULL
LOG: Dynamic Base = NULL
LOG: Cache Base = NULL
LOG: AppName = NULL
Calling assembly : (Unknown).
===
LOG: This is an inspection only bind.
LOG: Using application configuration file: c:\data\source\explorev1\explore.root\explore\euc.explore.domainobjectstest\bin\debug\euc.explore.domainobjectstest.dll.config
LOG: Using machine configuration file from C:\WINNT\Microsoft.NET\Framework\v2.0.50727\config\machine.config.
LOG: GAC Lookup was unsuccessful.
LOG: Attempting download of new URL file:///c:/data/source/explorev1/explore.root/explore/euc.explore.domainobjectstest/bin/debug/Msdcc.Common.DLL.
LOG: Assembly download was successful. Attempting setup of file: c:\data\source\explorev1\explore.root\explore\euc.explore.domainobjectstest\bin\debug\Msdcc.Common.dll
LOG: Entering run-from-source setup phase.
LOG: Assembly Name is: Msdcc.Common, Version=2.4.0.0, Culture=neutral, PublicKeyToken=9d9c15280f7f1425
WRN: Comparing the assembly name resulted in the mismatch: Minor Version
ERR: The assembly reference did not match the assembly definition found.
ERR: Failed to complete setup of assembly (hr = 0x80131040). Probing terminated.
My Though Process
This got me thinking why does it still not do the assembly redirection if the link is present in my config file.
So newbie that i am i just decided i will do exactly what the old man told me to do and removed the namespace declaration from the configuration element and hey presto it worked. xmlns="http://schemas.microsoft.com/.NetConfiguration/v2.0"
My Question after this very long story is from what i understand the namespace declarations is only supposed to mess with the Intellisense why is it screwing around with the assembly binding ???
Loading an assembly into the Reflection load context by design ignores publisher policy and binding redirect policy. Junfeng Zhang examines why this is in his excellent blog.
A similar question is asked here: Is it possible to use Assembly.ReflectionOnlyLoad together with publisher policies / assembly versioning?
Updating MSTest.TestAdapter and MSTest.TestFramework from version 1 to version 2 resolved this issue for me.
(to be precise, from 1.3.2 to 2.2.10)