NDepend - Several .NET assemblies have the name {MyAssembly} but they are different

Question

I've just started using NDepend and am trying to analyse a solution.

This warning appears when I add the solution's assemblies and it will not load any assemblies with the warning:

Cant' load the assembly {MyAssembly}: Several .NET assemblies have the name {MyAssembly} but they are different: ...list of the .dlls in the project which contain this assembly

What could be causing this? I am using a common AssemblyInfo.cs file as well as the standard one to set some common attributes but there are no conflicts between these attributes.

Whin

Answer 1

I had one project in my solution (the tests project) which was not set to build and referenced many of the other assemblies. Even when deselecting this assembly from NDepend it still threw the error.

Whin

Answer 2

David, the error is that in the set of input folders you provided in your NDepend project, NDepend found several different occurences of {MyAssembly.dll}. Meaning for example you have a {MyAssembly v1.0.1} file and a {MyAssembly v1.0.2} file.

Apparently this is something you were not aware of, so NDepend did a good job at exhibiting a flaw.

In the Project Property > Code to Analyze panel, hover the assembly {MyAssembly} with the mouse. In the tooltip that appears, you'll see several paths to different occurence of the different {MyAssembly.dll} files.

Connally

Thanks Patrick - I have looked through the assemblies it believes are different but they all have the same version number and were created at the same time. I can't see how they could be different. – Whin

Do they have the same exact size? (compare bit length). If yes contact us at support a-t ndepend dotcom – Connally

So if you want your solution to be analyzable by ndepend, you cannot use different versions of the same third-party assembly across your solution? – Acerate

The solution is still analyzable, but indeed, NDepend will refuse to analyze such duplicated third-party lib. Frankly, if several projects of your code base relies on multiple versions of a third-party lib, like NLog for example, you have a problem much bigger than having NDepend refuses to analyze your third-party lib :) – Connally

Answer 3

I have seen this occur when I have two versions of a solution in the same parent directory on my machine.

-root
-- solutiona
-- solutionb

My NDepend project was attached to the solution in the solutiona directory. However, NDepend was scanning starting at root, and finding dlls in both solutiona and solutionb. I moved one copy out of root, and was able to proceed.

I am using NDepend 4.1.0.6871. This behavior may not happen with newer releases.

Villeneuve