为什么引用的程序集被锁定？
我有 2 个组件。 Assembly2 被 Assembly1 引用。 为什么 Assembly2 被锁定？
我认为整个程序集是由 JIT 编译器加载到 RAM 中的，不是吗？
当调用引用的程序集时，该机制如何工作？
I have 2 assemblies. Assembly2 is referenced by Assembly1.
Why is Assembly2 locked?
I thought the whole assembly is loaded into the RAM by the JIT-Compiler, isn't it?
How does the machinism work when a referenced assembly is called?
如果你对这篇内容有疑问，欢迎到本站社区发帖提问 参与讨论，获取更多帮助，或者扫码二维码加入 Web 技术交流群。
绑定邮箱获取回复消息
由于您还没有绑定你的真实邮箱，如果其他用户或者作者回复了您的评论，将不能在第一时间通知您！
发布评论
评论（2）
（是的，这个问题本来可以更好，但是......）
引用的程序集被加载到进程中并因此被锁定。您可以通过卷影复制来解决这个问题，或者只是确保在尝试修改程序集之前关闭使用程序集的每个进程。
(yes, the question could have been better, still...)
Referenced assemblies are loaded into the process and are thus locked. You can get around this with shadow copying, or just make sure you close every process that uses your assemblies before you attempt to modify them.
我在编写要在 VB6 应用程序中使用的 .NET 组件时遇到了一种情况，当 VB6 编辑器打开时，我无法部署重新编译的 .NET 程序集。这真的让我很沮丧，因为我希望能够快速进行更改，然后将更改显示在我的 VB6 编辑器中。我收到一条错误消息，表明程序集已被另一个进程或线程锁定。
后来我意识到这很有意义。如果引用应用程序（在我的例子中是 VB6 IDE）每次使用该库时都相信该库是相同的，那么当应用程序位于内存中时 dll 发生更改，就会遇到严重的问题。
就我而言，关闭 VB6 IDE，更新 dll，然后重新打开 VB6 IDE 效果很好。这对我的工作流程来说是一个小小的障碍，但一旦我意识到为什么会发生这种情况，我就克服了它。
I ran into a situation when writing a .NET componenet to be consumed in a VB6 app where I couldn't deploy my recompiled .NET assembly while the VB6 editor was open. This really frustrated me because I wanted to be able to just make a quick change and then have the change show up in my VB6 editor. I was getting an error message that the assembly was locked by another process or thread.
I later realized that this made a lot of sense. If the referencing application (in my case, the VB6 IDE) is trusting that library to be the same each time it goes to consume it, it's going to run into serious problems if the dll changes while the application is in memory.
In my case, closing the VB6 IDE, updating the dll, and reopening the VB6 IDE worked just fine. It was a little bit of a hindrance in my workflow, but once I realized why it was happening, I got over it.