Solution with mulitple projects dependent on the same binary reference

Question

I have a solution with 10 projects. Many of the projects depend on a third party DLL called foo.dll.

The issue is that when I upgrade foo, somehow in Visual Studio when I go to the Object Browser it shows me two versions of foo.dll.

How can I find out which project is referencing the old version of foo.dll so I can upgrade it so there is only one dependency across all projects?

Answer 1

This is the kind of thing you only want to do once.

My recommendation to you is to get Notepad. Yes, Notepad.

Open the .csproj file for each of your projects.

There will be a section in the XML outlining the DLL that is being referenced including the path, etc. Even if they are coming out of the GAC, the version, etc. which is used by the .NET linker will be included in the file. The whole line to the reference must match exactly.

Compare these against one project which you know to be correct.

Dealing with references in .NET is one of the worst parts of it. Welcome to DLL hell v2.0 :(

Answer 2

I think the best answer is to have only one project have this dependency when this is feasible. It lets you deal with it in a single place.

If this means that the project will need to consist of a ridiculously fat wrapper library around the DLL, this may not be the best approach. But at least consider it.

Answer 3

It sounds like you have both versions of Foo.dll installed in the GAC. Check out gacutil to remove the old one.

If it is just a file reference, then in each project, open 'References' and right click on 'Foo' and choose properties. It will tell you in the resulting properties window information such as version.

Usually the best approach to dependencies like this is to have a separate folder at project level (but not part of the actual solution) called 'Dependencies' with these kinds of DLLs in them.

I'd also consider some build automation on your server (TFS = Team Build, SVN = Cruise Control, etc.) that will copy the right version of an assembly into the bin folder prior to build.

There are lots of ways to go with assemblies and it's easy to get confused over which one is being used by various applications. It's worth spending some time solving this problem once in a templateable manner that can apply to all future projects.

Answer 4

I understand the problem, but I am not sure you are asking the right question. Let me explain how .NET selects a referenced assembly.

• Assembly references can be floating or pinned (right-click on the assembly in the project's references folder, select Properties, look for "Specific Version"). If the version is floating, .NET will find and use the latest one. It makes sense to "pin" the version of a reference, so that the problems that you describe can be avoided (i.e. installing a new version of a product does not break your application).

• Assemblies can be in the Global Assembly Cache or just sit in the file system. You should pick one approach and use it consistently across your project, so that you at least know where to look.

If you understand these two aspects, you shouldn't have a problem (well, at least you should know what to do if there is a problem). If you pin the version and upgrade, you have to open your 10 something projects and upgrade the reference - but you are isolated from accidential upgrades.

If you let your version float, all references will automatically pick up the latest version that is installed. If you put your assemblies in the GAC, you don't have to search your search path and file system for left-over pieces and accidential copies of DLL files.

Answer 5

I had this same problem.

Project A referenced Project B. Project C referenced Project D, which referenced Project B. This caused Project C to have a reference to Project B. I got rid of Project D and cleaned up Project C (in the code), but the reference to Project B remained, I guess as a binary reference pointing to the bin folder of Project D.

I updated Project B inside visual studio. When I ran as startup Project C, it threw this error.

To fix, I went into referenced for Project C and removed unused references.

By the way, your actual question - how to find out where the offending dll lives - can more easily be answered like this: 1. Go into Explorer (Window 7 instructions here), and do a search on your whole code folder for .dll. 2. Add the column in Explorer for FileVersion and sort on this column. Voila!