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?
+2
A:
(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.
Assaf Lavie
2010-08-11 16:36:00
I thought the whole assembly is in the RAM, isn't it?
Rookian
2010-08-11 17:04:27
@Rookian That's a great question. I wonder if the whole assembly gets loaded into memory or just the parts needed to be referenced by other applications, i.e. the parts marked `public`.
Ben McCormack
2010-08-11 17:10:34
referenced are loaded into the process ... in which one?!
Rookian
2010-08-20 20:48:24
+1
A:
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.
Ben McCormack
2010-08-11 16:39:14