The "Found conflicts between different versions of the same dependent assembly." compiler warning in Visual Studio 2005 can be resolved by double clicking on the warning in the error list. Visual Studio 2005 proposes to fix the conflict by adding binding redirect records in the app.config file. I've build a simple solution which illustrates this problem. You can download the source at the bottom of this article.

   If you want to know which conflicts have been found,  you will have to browse through the output window of Visual Studio 2005 looking for lines like :

C:\WINDOWS\Microsoft.NET\Framework\v2.0.50727\Microsoft.Common.targets : warning MSB3247: 

Found conflicts between different versions of the same dependent assembly.

C:\WINDOWS\Microsoft.NET\Framework\v2.0.50727\Csc.exe /noconfig /nowarn:1701,1702 /errorreport:prompt /warn:4 

/define:DEBUG;TRACE 

/reference:G:\temp\ConflictsBetweenAssembly\LibraryTwo\bin\Debug\LibraryTwo.dll 

/reference:"D:\dotNet\NUnit V2.1\bin\nunit.framework.dll" 

/reference:C:\WINDOWS\Microsoft.NET\Framework\v2.0.50727\System.Data.dll 

/reference:C:\WINDOWS\Microsoft.NET\Framework\v2.0.50727\System.dll 

/reference:C:\WINDOWS\Microsoft.NET\Framework\v2.0.50727\System.Xml.dll 

/debug+ /debug:full /optimize- /out:obj\Debug\LibraryOne.dll /target:library Program.cs Properties\AssemblyInfo.cs

Compile complete -- 0 errors, 0 warnings

LibraryOne -> G:\temp\ConflictsBetweenAssembly\LibraryOne\bin\Debug\LibraryOne.dll

Done building project "LibraryOne.csproj".

The compiler output only learns that there is a conflict, it doesn't say which one. The Sytem.Data.dll, System.dll and System.Xml.dll assemblies should be ok, those belong to the .Net 2.0 framework. The nunit.framework.dll and LibraryTwo.dll assemblies, however, are suspicious.

   After a closer inspection of the Visual Studio 2005 solution, it becomes clear that LibraryTwo.dll depends on nunit.framework.dll version 2.2.3.0. So far so good, now we know which assembly has a versioning problem. For large solutions, this approach seems a bit difficult and error-prone to me. Adding binding redirects to app.config might be your preferred choice to solve this specific issue, I'd like to have more control about the ins and outs of my solutions.

    For this kind of situations, Lutz Roeder's .NET Reflector comes in : http://www.aisto.com/roeder/dotnet/. From the website of Lutz :

Reflector is a class browser for .NET components. It supports assembly and namespace views, type and member search, 

XML documentation, call and callee graphs, IL, Visual Basic, Delphi and C# decompiler, dependency trees, base type and 

derived type hierarchies and resource viewers.

Dependency trees are exactly what we are looking for. Roeder's .NET Reflector displays the dependencies of an assembly as a tree :

That's ok if you want to click through all the assemblies of a solution/project and inspect the version numbers of all assemblies with the same name. An assembly dependency graph would be a nice addition to the dependency tree. The Assembly Graph addin from http://projectdistributor.net/Projects/Project.aspx?projectId=43 does exactly this.

   First, you will have to install the latest version of Roeder's .NET Reflector, start Reflector.exe, close Reflector. After closing Reflector you will find a Reflector.cfg file. Add the following line in the [AssemblyCache] section of Reflector.cfg :

"%SystemRoot%\Assembly"

My [AssemblyCache] section looks like :

[AssemblyCache]

"%SystemRoot%\Microsoft.net"

"%ProgramFiles%\Microsoft.net"

"%SystemRoot%\Assembly"

This "%SystemRoot%\Assembly" line will instruct Roeder's .NET Reflector to search in the GAC for assemblies. Save Reflector.cfg and restart Reflector.exe. Click on File - Cache. Select the assemblies that you use. For instance, mscorlib (all versions), nunit.core, nunit.framework (all versions), etc. You can try to select all assemblies, on my machine that resulted in an empty Assembly Graph. So, it seems wise to only select assemblies that you actualy use.

   Now, drop the assemblies mentioned in the Visual Studio 2005 output window in Roeder's .NET Reflector, i.e. LibraryOne.dll and LibraryTwo.dll. Notice that we've loaded nunit.framework.dll from the GAC. Click on Tools - Assembly Graph, and there it is, the assembly dependency graph :

   It shouldn't be too difficult to spot the nunit.framework version conflict (in Roeder's .NET Reflector the red boxes are blue). So far so good, we have a visual representation of the conflicting assemblies. For this particular example, you can solve the issue by replacing the reference to nunit.framework version 2.1.4.0 in LibraryOne 1.0.0.0 with nunit.framework version 2.2.3.0.

   Notice that after making LibraryTwo dependent on LibraryOne, the compiler warning disappears. I don't know how you feel about that, I'd like to know which (sleeping) version conflicts exist in my source base. Dependency graphs seem to be an invaluable tool !