21

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!

Mr Shoubs
  • 14,629
  • 17
  • 68
  • 107

10 Answers10

38

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.

Darin Dimitrov
  • 1,023,142
  • 271
  • 3,287
  • 2,928
  • +1, ...and make sure to tick the local option for each shared reference inside Visual Studio. – Johannes Rudolph Mar 01 '10 at 17:02
  • Just tried that, but it doesn't work - a previous version is still being pulled in. – Mr Shoubs Mar 01 '10 at 17:04
  • It was a good idea, but didn't work :( what possible places could it be getting this previous verion from? I triple checked I copied the correct file. – Mr Shoubs Mar 01 '10 at 17:08
  • Is the assembly listed in the .NET tab of Visual Studio’s Add Reference dialog? This is not the same as the GAC. If so, even if you reference an assembly through the Browse tab VS may use the Registry to find the file. This has cost me hours. I really wish Microsoft would give developers full control over the build, and fail the build if an assembly is not found (rather than trying to find it). – TrueWill Mar 01 '10 at 18:48
  • It isn't in the GAC but it is in the .net tab... and personally I think they should fail the build if the assembly is the wrong Major version. – Mr Shoubs Mar 02 '10 at 09:36
  • 3
    If no version of the assembly is in the GAC and you have removed the reference to the library in your project's Reference's list and re-added it to point only to the dll in the /lib folder, there is no way the version could be anything other than what is in that folder unless you did not do that same procedure for all projects in the solution that have a reference to the DLL. Each project that needs to reference that DLL needs to use a local /lib folder. – Thomas Mar 02 '10 at 17:23
  • @Mr Shoubs - I'm with you on this one. Try removing the Registry key (after making a backup) to remove the assembly from the .NET tab. See http://support.microsoft.com/kb/306149 – TrueWill Mar 04 '10 at 03:37
  • Interesting - though I don't see how it helps my problem? I thought I would give it the benefit of the doubt, but that path doesn't exist in my registry - I get to HKCU\Software\Microsoft, then there is no .Net datafolder... – Mr Shoubs Mar 04 '10 at 09:26
  • I pretty sure that this is not the case, but since you're coming too close to the end of the tunnel, have you confirmed that you're looking at the assembly version instead of the file version? Can you confirm that file version and assembly versions are the same? Also, can you include a new method in the assembly and find if the new method comes through, just for test? – Wagner Silveira Nov 08 '10 at 20:07
  • If there is a Policy redirect for the .dll defined in the GAC (even though the assembly is not in the GAC), it will probe for this first, then probe in the local bin and then probe in the GAC. – Dave Black Aug 07 '12 at 14:53
9

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.
sankar
  • 1,724
  • 1
  • 22
  • 37
  • I'd vote for this on style, but I've not got 15 rep points yet. 1 - shows correct path 2 - doesn't seem to make any difference at all 3 - already done, sometimes this does solve some problems with compilation, but not this problem 4 - I can't find out where in process explorer it tells me this – Mr Shoubs Mar 01 '10 at 18:15
  • 1. I guess I forgot to mention this, compile and run the application and you can see where it is loaded from in output windows. 2. It is best to keep in the shared folder as Darin mentioned. So that, you can remove the bin and obj folder to always regenerate the executable file to make sure that we run with fresh copy of application. 4. You mentioned that it picks the wrong assembly from somewhere right? Using this tool, you can just view the referenced assemblies of an application and see where it is loaded from and its version number and etc in runtime. – sankar Mar 02 '10 at 01:20
  • 5. Additionally, open your project file in Notepad and see if there is any hardcoded version number or hintpath is there. If yes, remove them and add correct version number. – sankar Mar 02 '10 at 01:21
  • There is: False ..\..\..\vhc.server.solution\vhc.connections\Tags\v_3_0_0_5\bin\Debug\VHC.Connections.dll but changing it makes no difference – Mr Shoubs Mar 02 '10 at 09:39
  • Ok, did you use Process Explorer utility? – sankar Mar 02 '10 at 10:47
  • In process explorer I can't see where you can find referenced assemblies - I right click on the app, click properties, nothing to do with refereced assemblys in there... – Mr Shoubs Mar 02 '10 at 17:10
8

To overcome this, I removed EVERY reference, then added them all back in again. I don't know why this is the solution.

It is possible that in one project a DLL was incorrect, and it is this incorrect DLL that was pulled through by visual studio and used.

Edit: Other times this error has occurred is due to a DDL (A) being referenced in the current project also being referenced by another DLL (B). Not rebuilding this other DLL (B) seems to prevent VS from referencing the correct version of DLL (A) in the current project and thus it brings through an older version of DLL (A).

Mr Shoubs
  • 14,629
  • 17
  • 68
  • 107
  • 1
    I think this works because when the reference is added to the project (through Visual Studio) the version metadata is recorded in the `` line. I'm working with the same problem and found that unloading the project, finding the reference and manually changing the version info allowed the project to "find" the newer-versioned DLL. – Zach Young Nov 07 '11 at 17:49
  • Worked for me, i deleted all obj and bin folders, removed reference between projects, cleaned, rebuilt, re-added references. Booyaa. – Sam Jones Feb 25 '16 at 01:19
  • Worked for me! Also if you are working with a publish folder it will be god to delete all contents before the publish to ensure the files are being adde new instead of replaced!. – revobtz Aug 03 '17 at 20:17
  • @revobtz - if you are using file publish, I think there is an option in setting (file publish options) to automatically "delete all existing files prior to publish" – Mr Shoubs Aug 04 '17 at 09:26
  • @MrShoubs Yes I knew about that already, but sometime people doesn't know about this. So I just want them to ensure to get the new files instead of replace but thanks for the comment it may help others! – revobtz Aug 04 '17 at 14:18
2

Have you tried adding the reference as a Project Reference? i.e. Add Reference... -> Projects tab -> Select your project

Rowland Shaw
  • 37,700
  • 14
  • 97
  • 166
  • Unfortuanly that isn't possible in our scenario, we have to reference the DLL files. (I wish this wasn't the case) – Mr Shoubs Mar 01 '10 at 17:17
2

We (and, as the only .NET developer on our team, by that I mean I) had the exact same problem. I traced it down to a referenced dll, which in turn AGAIN references the dll suffering from versionitis. It seems that because I wasn't updating all the references which in turn reference the dll, it was replaced by an older version at some point during the build process.

One of the symptoms I experienced was that when I am in the code editor, the new class I added to the referenced project would be coloured appropriately, but when I hit Build, it changes back to black and I get a message saying the class does not exist (along with a very sarcastic "Ar you missing an assembly reference?"). This led me to believe that the problem has to happen during the Build phase.

I would therefore suggest building any and every other project that points to this DLL and re-add their references too.

Captain Kenpachi
  • 6,960
  • 7
  • 47
  • 68
0

Enable FusionLog and after the DLL fails to load, open the file with the DLL's name in the folder C:\FusionLog\Default\devenv.exe. This will show the path from where the DLL was really loaded.

In my case, an old version had mysteriously appeared in

C:\Program Files\Microsoft Visual Studio 10\Common7\IDE !

To stop this ever happening again, I added a security rule "Deny Write" to Everyone on Common7\IDE.

smirkingman
  • 6,167
  • 4
  • 34
  • 47
  • 1
    If you enable the Fusion assembly bind logging, make sure to disable it after you are done debuggin the assembly loading problem! – Dave Black Aug 07 '12 at 14:55
  • @smirkingman In my case it is under `C:\Windows\Microsoft.NET\Framework64\v4.0.30319\Temporary ASP.NET Files\root.` I deleted everything from `Temporary ASP.NET Files` and do a clean projec but it still trying to load from the same location. Any thoughts – Ammar Khan Oct 21 '16 at 12:53
0

I had a problem similar to what is described here except that my solution to the problem had to do with how I was compiling the code. There is a difference between build, clean and Rebuild. In my case, I was just using a Build between my changes and the dll from the dependent solution were not being carried over with all the changes to the other solution where the reference was set. I solved it by using Rebuild which cleans, compiles and links all source files regardless of whether they changed or not. Then the dll from the the first solution was updated and copied over automatically to the 2nd solution where the reference was set and the problem was solved. Cheers, I hope this helps.

Mario Levesque
  • 1,017
  • 13
  • 13
0

Similar symptoms - problem was in "Referene paths" in Project Properties, Reference.

Full descrtiption and solution here: Referenced assemblies automatically replaced by visual studio visual-studio/22810867#22810867

Community
  • 1
  • 1
Toke Breer-Mortensen
  • 1
0

Check Out this things:

  1. if problematic dll were referenced by both host web application and its referenced one. e.g. say, your web application uses abc.dll (problematic) and 1 other dll xyz.dll(i.e. class project which also reference abc.dll).

In this case, suppose, you've updated abc.dll from version 1 to version 2 and re-referenced in your web application. but during building process, the version 2 of abc.dll will change back to version 1, because, xyz.dll uses version 1 and web application overwrite abc.dll version 2 back to abc.dll version 1 during auto update on xyz.dll.

Solution: place updated version of abc.dll version 2 in class project bin of xyz.dll , too

Hope, above details will help, good luck

Ranjan Shrestha
  • 1
0

One possible reason is the Reference PATHs. If there's any reference to the old dll folder, VS will use it as the main reference, even though you added the new dll reference.

davidtj
  • 41
  • 4