Logo Questions Linux Laravel Mysql Ubuntu Git Menu
 

Project References DLL version hell

Tags:

We're having problems getting visual studio to pick up the latest version of a DLL from one of our projects.

We have multiple class library projects (e.g. BusinessLogic, ReportData) and a number of web services, each has a reference to a Connectivity DLL we've written (this ref to the connectivity DLL is the problem).

We always point references to the DLL in the bin/debug folder, (which is where we always build to for any given project) and all custom DLL references have CopyLocal = True and SpecificVersion = False

ReportData has a reference to business logic (which also has a reference to connectivity - I don't see why this should cause a problem, but thought it is worth mentioning)

The weird thing is, when you click "Add Reference" and browse to Connectivity/bin/debug - you hover the mouse over the DLL file, the correct (latest) version is shown (version and file version are always incremented together), but when you click ok, a previous version number is pulled though. Even when I look in the current projects debug folder (where copy local would put the DLL after compiling) that shows the latest version number. - NO WHERE does can I find the previous version of the DLL outside of visual studio, but in that project references it has the old version - even though the path is correct.

I'm at a loss as to where it might be getting the old versions from. Or even why it wants that one.

This is possibly the most frustraighting problem I have ever come across.

Does anyone know how to ensure the latest version is pulled through (preferably automatically or on compile).

EDIT:

Although not exactly the scenario I'm dealing with I was reading this article and somewhere it mentions about CLR ignoring revision numbers. Understandable (even though this hasn't been a problem before - we're on revision 39), so I thought I would update the build number, still didn't work. In a vain attempt I though I would update the minor version number and see if that made any difference.

I'm not saying this is the answer as I have to check quite a few things first, but on the face of it, this seems to have solved my problem...

Further edit: In other class libraries this seems to have solved the problem, however in a test windows application it still pulls a previous version through :(

If I increment the minor version number again, the same problem come back and I am left with the wrong version being pulled though.

Further Edit - I created an entirly new project, added a reference and still had the exact same problem. This suggests the problem is restriced to the project I am referencing. Wish I knew why!

Anyone had this problem before and know how to get around it?

HELP!

like image 920
Mr Shoubs Avatar asked Mar 01 '10 16:03

Mr Shoubs


People also ask

How do you resolve DLL Hell?

A simple solution to DLL Hell in an application is to statically link all the libraries, i.e. to include the library version required in the program, instead of picking up a system library with a specified name. This is common in C/C++ applications, where, instead of having to worry about which version of MFC42.

What is the difference between project reference and DLL reference?

If you directly add a DLL then you are locked into whatever that particular DLL was built as. The project reference allows this to be a build time decision. This is correct what you are saying. At the same time it is not causing issues when working with .

What is DLL Hell problem in C#?

Dll Hell refers to a set of problems caused when multiple applications attempt to share a common component like a dynamic link library (DLL). The reason for this issue was that the version information about the different components of an application was not recorded by the system.

How do I find the DLL version?

If you reference the dll in Visual Studio right click it (in ProjectName/References folder) and select "Properties" you have "Version" and "Runtime Version" there. In File Explorer when you right click the dll file and select properties there is a "File Version" and "Product Version" there.


2 Answers

To avoid the dll hell I would recommend you to create a lib folder inside your project and put all shared assemblies in this folder. Next you Add References only from this folder. This way your project is self contained and you know exactly where it is picking the references from. If you want to update some assembly with a newer version you copy it to the lib folder and rebuild your project.

Also make sure you don't the referenced assemblies into the GAC as they might be picked up first.

like image 200
Darin Dimitrov Avatar answered Sep 30 '22 06:09

Darin Dimitrov


There are few options that you can try.

  1. Compile the project and see in output window to verify the assembly path where it is referred from exactly.
  2. Delete Obj folder before you recompile it.
  3. Close and reopen the Visual Studio since VS has some weird behavior to keep the cache to hold Dll references.
  4. If you still see the problem, use this tool to check the reference assembly where it comes from really. Process Explorer.
like image 44
sankar Avatar answered Sep 30 '22 05:09

sankar