views:

47

answers:

2

I have a vb.net 3.5 application which references a dll (abc.dll, also in .net 3.5) This dll is accessed by the application from time to time. If at anytime during execution, if I delete the dll, I expect the application to throw an error the next time it tries to use a class from the dll. But, this is not the behaviour I see. If I delete the dll before startup, the application throws an error at startup. But not when the dll is deleted after startup.

Is this the standard behaviour, or am I doing something wrong? Can I get the app to throw an error if the dll is not found when it tries to use its classes?

Thanks in advance.

+3  A: 

The short answer no. Once a DLL is loaded it is loaded until app AppDomain instances using that DLL are unloaded from the process. Only then can you delete the original DLL.

Longer answer:

This is a complicated question because it depends on how the DLL is being loaded into the process. There are a couple of different ways this can occur

  • Direct loading off of disk. This one I know the least about but in this case the CLR could be taking a file lock on the assembly and hence it should be able to be deleted at all
  • Loading from a shadow directory. In this case the DLL is actually loaded from a different directory on disk to allow for operations such as deleting the original DLL. This is popular in web app scenarios. In this case deleting the original DLL is meaningless as the important DLL is loaded from a temp directory of sort.s
JaredPar
Thanks JaredPar.Does that mean that my options are:1) Load the dll directly off the disk instead of referencing it in my project2) check for file existence before I use a class from the dll.I am not sure which one will be better.
Apeksha
@Apeksha, if the DLL being deleted is a normal scenario I think the best approach is to simply wrap the loading of that class in a method which catches the exception that occurs if the DLL is not present. That is the most reliable way to handle the situation
JaredPar
A: 

Error always occurs at the time when .NET framework tries to load assembly you are referencing. So it looks like for some reason CLR decided to load the assembly on the startup of the your App.

Andrew Bezzub