This browser is no longer supported.
Upgrade to Microsoft Edge to take advantage of the latest features, security updates, and technical support.
![](data:image/svg+xml, %3Csvg xmlns='http://www.w3.org/2000/svg' height='64' class='font-weight-bold' style='font: 600 30.11764705882353px "SegoeUI", Arial' width='64'%3E%3Ccircle fill='hsl(307.2, 36%, 39%)' cx='32' cy='32' r='32' /%3E%3Ctext x='50%25' y='55%25' dominant-baseline='middle' text-anchor='middle' fill='%23FFF' %3EJA%3C/text%3E%3C/svg%3E)
Hi,
I have a project A (an application) which includes a package B, which in turn contains a third party package C3, which in turn contains another third party package package D3. Both packages A and D3 use the same third party package NLog but with different versions: package A includes NLog with version 5.0.0, and package D3 contains NLog with lower version 4.5.0.
A (application)
|-B
|...|-C3
|.......|-D3
|...........|-NLog 4.5.0
|
|-NLog 5.0.0
Compilation of project A is ok and execution of a certain program P is ok.
Then I have a test (MSTest) project T that includes project A:
T (test project)
|-A (application)
....|-B
....|...|-C3
....|.......|-D3
....|...........|-NLog 4.5.0
....|
....|-NLog 5.0.0
But, although project T compiles correctly, package D3 throws an exception at runtime when running a test which internally loads program P with message:
System.TypeLoadException: 'Could not load type 'NLog.Targets.OutputDebugStringTarget' from assembly 'NLog, Version=5.0.0.0, Culture=neutral, PublicKeyToken=5120e14c03d0593c'.'
Since project A runs ok, and project T is just a test project which includes project A, I would expect both executions to behave the same but it seems that, when executing the test in project T, D3 uses NLog 5.0.0 and fails because it expects 4.5.0.
The Global Assembly Cache does not contain NLog, so I do not expect the GAC to be related to the problem.
Has anyone gone through a similar situation or has any clue?
![](data:image/svg+xml, %3Csvg xmlns='http://www.w3.org/2000/svg' height='64' class='font-weight-bold' style='font: 600 30.11764705882353px "SegoeUI", Arial' width='64'%3E%3Ccircle fill='hsl(256, 32%, 34%)' cx='32' cy='32' r='32' /%3E%3Ctext x='50%25' y='55%25' dominant-baseline='middle' text-anchor='middle' fill='%23FFF' %3EMT%3C/text%3E%3C/svg%3E)
That isn't going to work. NLog had breaking changes between v4 and v5. You cannot use code that was compiled for v4 with the v5 version of NLog and vice versa. You'll need to pick the version you want to use and either upgrade your code (and any dependencies) to use v5 or downgrade the package to v4 until you can. This is a known issue with NLog.
In general you should not try to mix major versions of packages as breaking changes can happen between major versions (hence the version change). But NLog is pretty notorious for breaking things even between minor versions. But in this case v5 broke any v4 reliant code.
Thx, @Michael Taylor , but what is puzzling me is that the project A running through the test T is able to bind the desired versions of nlog. This is my main point and the reason why I have still not surrendered on making it work with both versions.
The exception in the test indicates that NLog is using the debugger target. Does your app do that as well? This is normally done either programmatically or via the nlog.config file.
Another possibility is of the binding order. It is never recommended that you mix package versions because the ordering is undefined and that may be what is happening here. Go to the output directory of your app and see what version of NLog was actually copied there. This is the version that will be used at runtime. You also likely have a binding redirect in your app config to ensure this. However in the test project it might have selected a different version of NLog. Additionally, unless you configured the test project to use redirect bindings, then it will likely bind to whatever version it finds, but I'm just guessing here. The final binary that is placed into the output directory is undefined so binding redirects help catch this at runtime.
Hi, after double checking, the issue came from the third party library having a different behavior for tests and normal run, injecting nlog for the tests pipeline, which led to the crash. Have solved it by not injecting nlog for that third library, which was not needed for the specific test. This ticket can be closed thx.