blocks|key|50528|text|它将其隐藏在GAC中。它可能会无限期地驻留在那里。使用较新的版本可能确实解决了这个问题，但Visual+Studio中存在一个与选择正确版本的DLL文件有关的突出错误。(如果DLL+Hell还不够糟糕，Visual+Studio团队正在让它变得更糟！)|type|unstyled|depth|inlineStyleRanges|entityRanges|offset|length|data|50529|在GAC中找到它很棘手，我不能建议您如何做到这一点，但一旦从那里删除了旧版本，就不会再找到它。有时，即使您将编译器指向较新的版本(按日期)，它也会使用较旧的版本，因为它具有相同的版本级别(按版本)。这就是它的bug。|50530|entityMap|0|LINK|mutability|MUTABLE|url|http://en.wikipedia.org/wiki/Global_Assembly_Cache|1|http://en.wikipedia.org/wiki/DLL_Hell^0|6|3|0|2F|8|1|0|0^^$0|@$1|2|3|4|5|6|7|P|8|@]|9|@$A|Q|B|R|1|S]|$A|T|B|U|1|V]]|C|$]]|$1|D|3|E|5|6|7|W|8|@]|9|@]|C|$]]|$1|F|3|-4|5|6|7|X|8|@]|9|@]|C|$]]]|G|$H|$5|I|J|K|C|$L|M]]|N|$5|I|J|K|C|$L|O]]]]

It hides it in the <a href="http://en.wikipedia.org/wiki/Global_Assembly_Cache">GAC</a>. 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 <a href="http://en.wikipedia.org/wiki/DLL_Hell">DLL Hell</a> 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.

blocks|key|2743324|text|可能正在从另一个文件夹引用该DLL。如果您的PATH环境变量中有网络驱动器，它甚至可以在网络驱动器上。下面是Windows搜索DLL的方法：http://msdn.microsoft.com/en-us/library/7d83bc18%2528v=vs.80%2529.aspx|type|unstyled|depth|inlineStyleRanges|entityRanges|offset|length|data|2743325|entityMap|0|LINK|mutability|MUTABLE|url|http://msdn.microsoft.com/en-us/library/7d83bc18%2528v=vs.80%2529.aspx^0|1Y|1U|0|0^^$0|@$1|2|3|4|5|6|7|L|8|@]|9|@$A|M|B|N|1|O]]|C|$]]|$1|D|3|-4|5|6|7|P|8|@]|9|@]|C|$]]]|E|$F|$5|G|H|I|C|$J|K]]]]

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:
<a href="http://msdn.microsoft.com/en-us/library/7d83bc18%28v=vs.80%29.aspx" rel="nofollow">http://msdn.microsoft.com/en-us/library/7d83bc18%28v=vs.80%29.aspx</a>

blocks|key|2533535|text|我也猜他们藏在GAC里。你可以在“C：\Windows\assembly”中查看所有的dll，然后从那里注销你的dll。|type|unstyled|depth|inlineStyleRanges|entityRanges|data|2533536|entityMap^0|0^^$0|@$1|2|3|4|5|6|7|D|8|@]|9|@]|A|$]]|$1|B|3|-4|5|6|7|E|8|@]|9|@]|A|$]]]|C|$]]

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.

blocks|key|51026|text|在我的例子中，这是由于切换到释放模式，该模式具有不同的配置(使用DLL的不同位置)。|type|unstyled|depth|inlineStyleRanges|entityRanges|data|51027|entityMap^0|0^^$0|@$1|2|3|4|5|6|7|D|8|@]|9|@]|A|$]]|$1|B|3|-4|5|6|7|E|8|@]|9|@]|A|$]]]|C|$]]

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

blocks|key|2533574|text|我遇到了类似的问题(但没有Visual+Studio)。我正在使用UnsafeLoadFrom加载一个.NET动态链接库。在一台计算机(终端服务器)上，旧文件仍然被使用，而不管更新的版本号等。|type|unstyled|depth|inlineStyleRanges|entityRanges|data|2533575|原因很简单:只要已经加载了旧dll的程序实例正在运行，新的dll就永远不会被使用。所有进一步的UnsafeLoadFrom都将成为旧的dll，尽管旧的版本不再存在于硬盘上，因为它已经加载了一段时间。|2533576|解决方案是关闭应用程序的所有正在运行的实例，甚至重新启动计算机。然后，所有新实例都将获得更新后的dll。|2533577|entityMap^0|0|0|0^^$0|@$1|2|3|4|5|6|7|H|8|@]|9|@]|A|$]]|$1|B|3|C|5|6|7|I|8|@]|9|@]|A|$]]|$1|D|3|E|5|6|7|J|8|@]|9|@]|A|$]]|$1|F|3|-4|5|6|7|K|8|@]|9|@]|A|$]]]|G|$]]

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.

blocks|key|51043|text|在我的例子中，我使用Visual+Studio发布网站，虽然我检查了dll文件的引用已经更改，但发布的dll仍然是旧的。最后，我新建了一个Publish+Web+Profile并选择了正确的配置(如Debug+-+x86+/+Release+-+Any+CPU)，然后再次发布，然后更正该dll。|type|unstyled|depth|inlineStyleRanges|offset|length|style|CODE|entityRanges|data|51044|entityMap^0|1X|J|2R|V|0^^$0|@$1|2|3|4|5|6|7|H|8|@$9|I|A|J|B|C]|$9|K|A|L|B|C]]|D|@]|E|$]]|$1|F|3|-4|5|6|7|M|8|@]|D|@]|E|$]]]|G|$]]

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 <code>Publish Web Profile</code> and choose the right configuration (such as <code>Debug - x86 / Release - Any CPU</code>), publish again then the dll is corrected.

blocks|key|2533624|text|在我的Visual+Studio+2015中，我确保有问题的Visual+Studio项目的引用路径列表为空：|type|unstyled|depth|inlineStyleRanges|entityRanges|data|2533625|​|2533626|📷|atomic|offset|length|2533627|2533628|entityMap|0|IMAGE|mutability|IMMUTABLE|imageUrl|https://ask.qcloudimg.com/http-save/yehe-900000/90ee041b9055463c9264f8021d8f2e1c.png|imageAlt^0|0|0|0|1|0|0|0^^$0|@$1|2|3|4|5|6|7|S|8|@]|9|@]|A|$]]|$1|B|3|C|5|6|7|T|8|@]|9|@]|A|$]]|$1|D|3|E|5|F|7|U|8|@]|9|@$G|V|H|W|1|X]]|A|$]]|$1|I|3|C|5|6|7|Y|8|@]|9|@]|A|$]]|$1|J|3|-4|5|6|7|Z|8|@]|9|@]|A|$]]]|K|$L|$5|M|N|O|A|$P|Q|R|-4]]]]

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

<a href="https://i.stack.imgur.com/r26sD.png" rel="nofollow noreferrer"><img src="https://i.stack.imgur.com/r26sD.png" alt="enter image description here"></a>

blocks|key|50613|text|虽然这个问题很古老，但也许有人会在寻找解决方案的过程中再次遇到这个问题。在我的例子中，我得到了一个ASP.Net页面的CS0433错误。在删除项目的obj\和bin\文件夹中的内容后，它再次工作。可能必须使用封闭的Visual+Studio来完成。也许还可以在同一解决方案中清除引用项目中的这些文件夹(如果在项目中使用，而不是通过Nuget拉取)。|type|unstyled|depth|inlineStyleRanges|entityRanges|data|50614|entityMap^0|0^^$0|@$1|2|3|4|5|6|7|D|8|@]|9|@]|A|$]]|$1|B|3|-4|5|6|7|E|8|@]|9|@]|A|$]]]|C|$]]

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

blocks|key|50618|text|如果你发现这样问题，删除你的引用dll和pdb扩展文件添加新的引用并重建你的项目.This经常发生，因为没有重建项目，提交和更新。|type|unstyled|depth|inlineStyleRanges|entityRanges|data|50619|entityMap^0|0^^$0|@$1|2|3|4|5|6|7|D|8|@]|9|@]|A|$]]|$1|B|3|-4|5|6|7|E|8|@]|9|@]|A|$]]]|C|$]]

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.

blocks|key|51341|text|在我的例子中，旧的DLL在|type|unstyled|depth|inlineStyleRanges|entityRanges|data|51342|C:\Windows\Microsoft.NET\assembly\GAC_MSIL\MyDLL\MyDLL.dll|code-block|syntax|javascript|51343|它没有显示在c:\Windows\assembly中。|offset|length|style|CODE|51344|我在我的驱动器中搜索了MyDLL，结果如上所述。当时我正在调试我的测试应用程序，并试图删除被Visual+Studio锁定的有问题的folder...no+go...it。我不得不停止调试我的应用程序，关闭Visual+Studio，然后删除文件夹。问题解决了！我不知道我的DLL怎么会在那里，但自从我把它删除后，它就再也没有出现过。|51345|entityMap^0|0|0|6|J|0|0^^$0|@$1|2|3|4|5|6|7|Q|8|@]|9|@]|A|$]]|$1|B|3|C|5|D|7|R|8|@]|9|@]|A|$E|F]]|$1|G|3|H|5|6|7|S|8|@$I|T|J|U|K|L]]|9|@]|A|$]]|$1|M|3|N|5|6|7|V|8|@]|9|@]|A|$]]|$1|O|3|-4|5|6|7|W|8|@]|9|@]|A|$]]]|P|$]]

In my case, the old DLL was in 

<pre><code>C:\Windows\Microsoft.NET\assembly\GAC_MSIL\MyDLL\MyDLL.dll
</code></pre>

It DID NOT show up in <code>c:\Windows\assembly</code>.

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.

blocks|key|2533790|text|我尝试了很多东西，包括重新安装VS2107。您可以在“输出”窗口中查看DLL文件的加载位置。在翻遍我所有的DLL项目后，我找到了它。|type|unstyled|depth|inlineStyleRanges|entityRanges|data|2533791|清除这个对我来说很有效。|2533792|C:\Users\YourUser\AppData\Local\assembly\dl3\222Q4G1T.8AT\JBEAR7PB.E3J\8bfcf9ab\6e61cbd5_30acd401\YourDLL.dll'|code-block|syntax|javascript|2533793|实际上，我删除了以下位置的所有文件：|2533794|C:\Users\YourUser\AppData\Local\assembly\|2533795|entityMap^0|0|0|0|0|0^^$0|@$1|2|3|4|5|6|7|O|8|@]|9|@]|A|$]]|$1|B|3|C|5|6|7|P|8|@]|9|@]|A|$]]|$1|D|3|E|5|F|7|Q|8|@]|9|@]|A|$G|H]]|$1|I|3|J|5|6|7|R|8|@]|9|@]|A|$]]|$1|K|3|L|5|F|7|S|8|@]|9|@]|A|$G|H]]|$1|M|3|-4|5|6|7|T|8|@]|9|@]|A|$]]]|N|$]]

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.

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

I actually deleted all the files in:

<pre><code>C:\Users\YourUser\AppData\Local\assembly\
</code></pre>

blocks|key|52002|text|我的修复方法是确保IIS中的虚拟目录指向正确的目录。我的系统上有两个项目，一个是v4，一个是v5。我的开发系统上的虚拟目录指向的是v4+bin目录，而不是我的v5+bin目录-哦！|type|unstyled|depth|inlineStyleRanges|entityRanges|data|52003|entityMap^0|0^^$0|@$1|2|3|4|5|6|7|D|8|@]|9|@]|A|$]]|$1|B|3|-4|5|6|7|E|8|@]|9|@]|A|$]]]|C|$]]

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!

blocks|key|2533844|text|缓存在dll中的文件，我无法跟踪该文件，因此我最终重命名了该文件。这可能不能解决这里提到的问题，但这是与这个问题相关的对我有效的修复方法。|type|unstyled|depth|inlineStyleRanges|entityRanges|data|2533845|entityMap^0|0^^$0|@$1|2|3|4|5|6|7|D|8|@]|9|@]|A|$]]|$1|B|3|-4|5|6|7|E|8|@]|9|@]|A|$]]]|C|$]]

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.

blocks|key|2533875|text|我的天啊！我有一个很老很旧的应用程序套件，包括两个web服务、一堆类库和一个单击一次的应用程序。好吧，click曾经停止发布VS2005，并出现一堆“找不到”的错误。因此，我认为现在是时候将项目升级到2017年了，而不是像这个网站上建议的那样修改我的注册表。嗯，当我这样做的时候，我的web服务项目中的项目引用丢失了。然后，VS+2017肯定是在C:\Users\XXX\AppData\Local\Temp\WebSitePublish或C:\Users\XXX\AppData\Local\Microsoft\VisualStudio\8.0\ProjectAssemblies或C:\Windows\Microsoft.NET\Framework\v4.0.30319\Temporary+ASP.NET文件\根目录中找到了一些缓存文件，而不是帮助地告诉我有错误，而是使用了这些文件！我不得不用一个自定义程序做一个硬核搜索，以找到我的C:\驱动器上的所有文件，并在我最终得到错误之前删除它们！|type|unstyled|depth|inlineStyleRanges|entityRanges|data|2533876|entityMap^0|0^^$0|@$1|2|3|4|5|6|7|D|8|@]|9|@]|A|$]]|$1|B|3|-4|5|6|7|E|8|@]|9|@]|A|$]]]|C|$]]

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!

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:

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

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 <a href="http://en.wikipedia.org/wiki/TeamCity">TeamCity</a> server which is using <a href="http://en.wikipedia.org/wiki/MSBuild">MSBuild</a>. When TeamCity tries to run unit tests it uses an old DLL file.

Now, I know that I can use assembly redirection in the <code>web.config</code> 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.

Old DLL file keeps being used

Visual Studio

单元测试

服务器

编译器

Windows

我有一个看似随机的问题，我的项目将使用不再存在的旧版本的DLL文件运行。有时将使用真实版本的DLL文件，有时将使用旧版本的DLL文件。谁知道Visual Studio从哪里得到这个DLL文件-它已经过期了几个月了！我知道它使用的是旧的DLL文件，因为当应用程序运行时，我开始得到奇怪的“TypeLoadException...

问继续使用旧的DLL文件
EN

社区

活动

资源

关于

腾讯云开发者

热门产品

热门推荐

更多推荐

问继续使用旧的DLL文件EN

社区

活动

资源

关于

腾讯云开发者

热门产品

热门推荐

更多推荐

问继续使用旧的DLL文件
EN