Old DLL file keeps being used

Question

I have a seemingly random problem where my project will run using an old version of a DLL file that no longer exists. Sometimes the real version of the DLL file will be used, other times an ancient version of the DLL file will be used. Who knows where Visual Studio is getting this DLL file from - it's months out of date!

I know that it is using the old DLL file, because when the application runs I start getting weird 'TypeLoadExceptions', complaining that methods don't exist or don't have implementations.

The following actions will sometimes help, sometimes not:

Restarting Visual Studio
Restarting the computer
Cleaning and rebuilding the solution
Deleting everything in \WINDOWS\Microsoft.NET\Framework\v4.0.30319\Temporary ASP.NET Files
Searching for and deleting instances of the DLL file in \Documents and Settings\username\Local Settings\Temp

Sometimes I perform all of the above steps, and it still uses an old copy of the DLL file. Where is it hiding it?!

The same issue exists on our TeamCity server which is using MSBuild. When TeamCity tries to run unit tests it uses an old DLL file.

Now, I know that I can use assembly redirection in the web.config file, but the version number of the DLL file hasn't changed (I don't bother to update it, so it just stays at version 1). I don't want to have to start versioning the DLL files just to solve this problem. I would just like to know which particular caches I need to clear so that I can get on with developing.

Its all in the version.. You would need to change the version and it will take the latest. — sajoshi, Apr 07 '11 at 02:29
This is a .NET dll. I have never updated the version number on my dlls before, and have never had the need to. I'm not sure why suddenly in this one particular instance I need to. — cbp, Apr 07 '11 at 04:36
Have you tried renaming the dll [Summer](http://stackoverflow.com/q/2193953/85950)? — blahdiblah, Sep 14 '11 at 03:15
Revisiting this question, nowadays I've learned that versioning the dll is essential and can be done automatically: https://stackoverflow.com/questions/826777/how-to-have-an-auto-incrementing-version-number-visual-studio — cbp, Feb 27 '18 at 22:50

score 54 · Accepted Answer · edited Feb 22 '12 at 13:10

54

It hides it in the GAC. There it may reside indefinitely. Using a more recent version may indeed solve the problem, but there is an outstanding bug in Visual Studio that has to do with choosing the correct version of DLL files. (If DLL Hell wasn't bad enough, the Visual Studio team is making it worse!)

Finding it in the GAC is tricky, and I cannot advise you on how to do that, but once the old version is deleted from there, it will not be found again. Sometimes, even though you are pointing the compiler at a newer version (by date), it will use the older version, because it has the same version level (by version). That is its bug.

edited Feb 22 '12 at 13:10

Peter Mortensen

30,738
21
105
131

answered Sep 08 '11 at 23:22

shipr

2,809
1
24
32

1

And of course it is a good idea to keep the version number unique among releases. ^"If it ain't got a new version number, don't deploy it" :-) – TheBlastOne Sep 14 '11 at 11:49
2

Have you seen this document, titled "How to: Remove an Assembly from the Global Assembly Cache"? http://msdn.microsoft.com/en-us/library/zykhfde0.aspx – djdanlib Sep 14 '11 at 15:26
2

you can check if it is there using gacutil -l {name of the assembly} – Nicolas De Irisarri Sep 14 '11 at 22:15
2

for gacutil, point your cmd to C:\Program Files (x86)\Microsoft SDKs\Windows\v7.0A\Bin – GorvGoyl Jun 27 '17 at 06:07

score 33 · Answer 2 · answered Sep 14 '11 at 20:26

33

Who knows where Visual Studio is getting this dll from - it's months out of date!

The Modules Window is your friend...

It'll tell you exactly where that file is coming from. You can even use it with arbitrary processes if you attach the debugger.

answered Sep 14 '11 at 20:26

Eric Nicholson

4,053
1
28
29

5

I'd just like to add for future skimmers, your project needs to be running in debug mode just for the option to appear (debug -> windows -> modules). – John Pavek Sep 06 '19 at 21:14

Dan Lord · Answer 3 · 2016-03-24T02:54:04.143

5

I too would guess that they're hiding in the GAC. You can look in 'C:\Windows\assembly' to see all the dlls and unregister yours from there.

edited Mar 24 '16 at 02:54

answered Sep 15 '11 at 01:48

Dan Lord

6,166
3
19
15

score 3 · Answer 4 · answered Nov 21 '12 at 10:11

3

The problem may exists with the build order or your projects. If your Test project is built before the application project, this cause the behaviour you describe.
To fix this:
right click on your main project in VS and select the Project Dependencies... option and check the build order. Changes to the build subsequence can be made here by correctly setting these dependencies.

answered Nov 21 '12 at 10:11

rafiy

39
1

This solved the problem for me. I cleaned each project and then built each one individually in the correct order, and voila. Problem went away. Thank you. – joelc Mar 16 '18 at 23:46

score 2 · Answer 5 · edited Jun 27 '17 at 09:32

I had a similiar problem (but without Visual Studio). I am loading a .NET dll using UnsafeLoadFrom. On one computer (a terminal server) the old file still remains being used, regardless of updated version numbers, etc.

The reason is simple: As long as a program instance is running, which has already loaded the old dll, the new dll will never be used. All further UnsafeLoadFrom will become the old dll although the old version doesn't exist on the harddisk anymore, because it has already loaded some time ago.

The solution is to shut down all running instances of the application or even restart the computer. Then all new instances will get the updated dll.

score 1 · Answer 6 · answered Jul 20 '16 at 12:31

1

In my case, this was caused switching to Release mode, which had a different configuration (that used different location of the DLL).

answered Jul 20 '16 at 12:31

Libor

3,285
1
33
41

score 1 · Answer 7 · edited Jan 24 '18 at 11:31

1

In my case, I use Visual Studio to Publish Website, and though I check the reference of the dll file has changed, but the published dll still is old. Finally I new a Publish Web Profile and choose the right configuration (such as Debug - x86 / Release - Any CPU), publish again then the dll is corrected.

edited Jan 24 '18 at 11:31

Irvin Dominin

30,819
9
77
111

answered Jan 07 '18 at 17:28

yu yang Jian

6,680
7
55
80

score 1 · Answer 8 · answered Apr 25 '18 at 12:37

While this question is old, maybe someone will stumble upon it again in his/her quest for finding a solution. In my case i got a CS0433 error for an ASP.Net page. After deleting the content in the obj\ and bin\ folders of the project, it worked again. Probably has to be done with a closed Visual Studio. Maybe also clean out those folders in referenced projects in the same solution (if used in the project and not pulled via Nuget).

score 1 · Answer 9 · edited Nov 02 '18 at 01:46

In my case, the old DLL was in

C:\Windows\Microsoft.NET\assembly\GAC_MSIL\MyDLL\MyDLL.dll

It DID NOT show up in c:\Windows\assembly.

I did a search of my drive for MyDLL, and it showed up as indicated above. I was debugging my test app at the time, and tried to delete the offending folder...no go...it was locked by Visual Studio. I had to stop debugging my app, close Visual Studio, and then delete the folder. Problem solved!! I don't know how my DLL got there, but it hasn't showed up there since I deleted it.

score 0 · Answer 10 · edited Feb 28 '18 at 00:53

0

In My Visual Studio 2015, I ensured that the offending Visual Studio project's Reference Path Listing is empty:

edited Feb 28 '18 at 00:53

Alan Kavanagh

9,425
7
41
65

answered Feb 27 '18 at 18:51

crazyTech

1,379
3
32
67

You posted the exact same answer to 2 different questions? – Alan Kavanagh Feb 28 '18 at 00:55

score 0 · Answer 11 · answered Oct 29 '18 at 05:25

0

If you find such problem ,delete your Reference dll and pdb extensionfile add new references and rebuild your project .This often happens due to no rebuild of project,commit and updates.

answered Oct 29 '18 at 05:25

Shahbaz Raees2

201
2
5

score 0 · Answer 12 · edited Oct 01 '19 at 07:32

I tried a ton of things including re-installing VS 2107. You can see where the DLL files are being loaded from in your Output window. After going through all mine looking for project DLL, I found it.

Clearing this worked for me.

C:\Users\YourUser\AppData\Local\assembly\dl3\222Q4G1T.8AT\JBEAR7PB.E3J\8bfcf9ab\6e61cbd5_30acd401\YourDLL.dll'

I actually deleted all the files in:

C:\Users\YourUser\AppData\Local\assembly\

score 0 · Answer 13 · answered Jun 26 '19 at 23:24

The fix for me was making sure that the virtual directory in IIS was pointing to the correct directory. I have two projects on my system, a v4 and a v5. The virtual directory on my dev system was pointing to the v4 bin directory instead of my v5 bin directory - oops!

score 0 · Answer 14 · answered Jul 13 '19 at 21:47

0

The file that was being cached in the dll, I couldn't trace the file, so I ended up renaming the file. This might not resolve the problem mentioned here but this was the fix that worked for me related to this question.

answered Jul 13 '19 at 21:47

Jayowl

280
3
11

score 0 · Answer 15 · answered Apr 20 '20 at 15:51

Holy Crow! I had an old, old suite of applications including 2 web services and a bunch of class libraries and a click once application. Well, click once stopped publishing for VS 2005 with a bunch of 'not found' errors. So, rather than hack away at my registry as suggested on this site, I figured it was time to upgrade the projects to 2017. Well, when I did this, the projects references in my web service projects got lost. Then, rather than helpfully just telling me that with errors, VS 2017 must have went to some cached file in C:\Users\XXX\AppData\Local\Temp\WebSitePublish or C:\Users\XXX\AppData\Local\Microsoft\VisualStudio\8.0\ProjectAssemblies or C:\Windows\Microsoft.NET\Framework\v4.0.30319\Temporary ASP.NET Files\root and 'helpfully' just used those files instead! I had to do a hardcore search with a custom program to find all the files on my C:\ drive and delete them before I finally got the errors!

score 0 · Answer 16 · answered Sep 14 '11 at 17:09

It's possible that the DLL is being referenced from another folder. It could even be on a network drive if you have one in your PATH environment variable. Here's how Windows searches for DLLs: http://msdn.microsoft.com/en-us/library/7d83bc18%28v=vs.80%29.aspx

Old DLL file keeps being used

16 Answers16

Linked