views:

380

answers:

4

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

The issue is that when i upgrade foo, somehow in Visual studio when i go to object browser it shows me 2 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.

A: 

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's lots of ways to go with assemblies and its easy to get confused over which one is being used by various applications. Its worth spending some time solving this problem once in a templateable manner that can apply to all future projects.

DarkwingDuck
+3  A: 

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 :(

Spence
A: 

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 dlls.

cdonner
A: 

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.

reinierpost