CODEWITHSUNDEEP
c#nunitinversion-of-controlcastle-windsornlog
John S.
John S.

Reputation: 2007

NUnit keeps running the wrong version of a .dll

I am using the NUnit 2.6.4 test runner. I am running from an .nunit project file that loads my .csproj test. It keeps running the wrong version of a dependency.
Background:

I have castle windsor 3.3 using the NLog facility. I am using NLog 3.2. By default Windsor tries to load NLog 2.0 and would throw an error "Can't load NLog 2.0". So I added the following to the app.config files of my exe files to tell Windsor to load NLog 3.2:

<runtime>
    <assemblyBinding xmlns="urn:schemas-microsoft-com:asm.v1">
        <dependentAssembly>
            <assemblyIdentity name="NLog" publicKeyToken="5120e14c03d0593c" culture="neutral" />
            <bindingRedirect oldVersion="0.0.0.0-3.2.0.0" newVersion="3.2.0.0" />
        </dependentAssembly>
    </assemblyBinding>
</runtime>

Now, I come to my NUnit. I'm trying to run my integration tests (my unit and functional tests are fine, because we don't use IoC in those tests), in the integration tests we use Windsor IoC to ensure everything is wired ok. When I run this integration test I keep getting the same error about "Can't find NLog 2.0". I've ensured the above is in my test.dll app.config and also tried adding it to the nunit test runner config file. Still no go. How can I get NUnit to ensure this setting is found and applied at test run time?

Upvotes: 0

Views: 824

Answers (2)

Ognyan Dimitrov
Ognyan Dimitrov

Reputation: 6251

In every VS project there is an 'obj' folder in which VS is keeping assembly reference caches. Sometimes this caches are the problem. For this problem I have script that you can safely run from PowerShell before build.

Get-ChildItem .\ -include bin,obj -Recurse | foreach ($_) { remove-item $_.fullname -Force -Recurse }

Run this script when you are in your solution folder. This script will recursively get all the bin and obj folders of your solution and will erase them. When you rebuild your solution it will generate brand new assembly reference caches and probably your problem will be resolved.

Also be sure that you have deleted the folders of the previous versions of the package. When you update a package in your project its folder will not be automatically deleted and this may cause a problem too.

I had this problem with newtonsoftJson package dlls and solved it that way.

Upvotes: 0

John S.
John S.

Reputation: 2007

Adding the following to the .nunit project file fixes this issue:

configfile="Hl7ic.Engine.Test.dll.config"

Even though the above runtime config setting was properly set in the test.dll.config, the nunit project didn't know to use the test.dll.config file. I always thought it was implicitly known to nunit, but apparently it needs to be explicitly set.

Upvotes: 0

Related Questions