views:

682

answers:

2

I am using some of the testing libraries from Sharp Architecture which make use of NUnit 2.5.0 while the rest of my project uses NUnit 2.5.1 so I placed an assembly redirect in my test project app config file:

<?xml version="1.0" encoding="utf-8" ?>
<configuration>
    <runtime>
        <assemblyBinding>
            <dependentAssembly>
                <assemblyIdentity name="nunit.framework"
                                  publicKeyToken="96d09a1eb7f44a77" />
                <bindingRedirect oldVersion="2.5.0.9122"
                                 newVersion="2.5.1.9189"/>
            </dependentAssembly>        
        </assemblyBinding>
    </runtime>
</configuration>

I am still getting an assembly redirect version:

TestCase ''
failed: Could not load file or assembly 'nunit.framework, Version=2.5.0.9122, Culture=neutral, PublicKeyToken=96d09a1eb7f44a77' or one of its dependencies. The located assembly's manifest definition does not match the assembly reference. (Exception from HRESULT: 0x80131040)
    System.IO.FileLoadException: Could not load file or assembly 'nunit.framework, Version=2.5.0.9122, Culture=neutral, PublicKeyToken=96d09a1eb7f44a77' or one of its dependencies. The located assembly's manifest definition does not match the assembly reference. (Exception from HRESULT: 0x80131040)
    File name: 'nunit.framework, Version=2.5.0.9122, Culture=neutral, PublicKeyToken=96d09a1eb7f44a77'

Enabling my Fusion ErrorLog I see this:

=== Pre-bind state information ===
LOG: DisplayName = nunit.framework, Version=2.5.0.9122, Culture=neutral, PublicKeyToken=96d09a1eb7f44a77
 (Fully-specified)
LOG: Appbase = file:///C:/code/Samples/PersistencePatterns/app/PersistencePatterns.Tests/bin/Debug
LOG: Initial PrivatePath = NULL
Calling assembly : SharpArch.Testing.NUnit, Version=1.0.0.0, Culture=neutral, PublicKeyToken=b5f559ae0ac4e006.
===
LOG: This bind starts in default load context.
LOG: Using application configuration file: C:\code\Samples\PersistencePatterns\app\PersistencePatterns.Tests\bin\Debug\PersistencePatterns.Tests.dll.temp.config
LOG: Using machine configuration file from c:\WINDOWS\Microsoft.NET\Framework\v2.0.50727\config\machine.config.
LOG: Post-policy reference: nunit.framework, Version=2.5.0.9122, Culture=neutral, PublicKeyToken=96d09a1eb7f44a77
LOG: Attempting download of new URL file:///C:/code/Samples/PersistencePatterns/app/PersistencePatterns.Tests/bin/Debug/nunit.framework.DLL.
WRN: Comparing the assembly name resulted in the mismatch: Revision Number
ERR: Failed to complete setup of assembly (hr = 0x80131040). Probing terminated.

What gives? What is this temp.config file that its looking for? Why isn't it looking in my actual config?

Well no matter, I added the following to my post-build events:

copy $(ProjectDir)App.config $(TargetDir)\$(TargetFileName).temp.config

Everything gets copied fine, but as soon as I run tests with Testdriven.NET the file disappears.

Can anyone give me a clue as to whats going on?

A: 

I don't have any idea about testdriven.net, but i would probably try adding the assembly redirect to the assembly referencing the nunit dlls. Probably the first one, so maybe the app.config for testdriven.net, if it uses nunit directly or in the app.config for whichever assembly uses/loads nunit dlls. This is mostly a guess :/

Ankit
Please don't answer a bounty question with a complete guess. This is especially annoying because in the question I actually showed you the FusionLog which demonstrates all the config files checked for binding.
George Mauer
+1  A: 

Have you tried copying the App.config of the class library without the ".temp" part?

copy $(ProjectDir)App.config $(TargetDir)\$(TargetFileName).config

EDIT: The "*.temp.config" seems to be generated by the TestDriven.NET, as [stated in the release notes of version 2.3][1]

João Angelo
That's what Visual studio does already. I have verified that this functionality isn't broken for some reason by checking that the file exists. I've never seen a temp extension like that before though.
George Mauer
You're right, I was convinced that it would only do that for an executable and not a class library. My mistake. The "*.temp.config" seems to be generated by the TestDriven.NET though, as stated in the release notes of version 2.3 (http://www.testdriven.net/downloads/ReleaseNotes.html).
João Angelo