If dll file exists in the application directory, it works fine, but if the dll file is accidentally deleted, the program run collapses without handling the exception. The assembly is used:
private void dosomething()
The program can not handle the exception and collapses immediately. Is there away to
Of course the application dies. If you have a using clause in your class that requires a given dll, then any call made to a namespace the application can't resolve will cause a fatal error.
The solution: Make sure the assembly is properly referenced and that it appears in your output directories.
There is no way to catch the error if the DLL doesn't exist because your app doesn't exist when the error is thrown. When a .net application is run, the framework extracts the required DLLs from the manifest and attempts to resolve them. (Note that it doesn't actually load them... that doesn't happen until the JIT compiler needs them.) When it can't find a library in the GAC or the app directory, it will throw the exception. One of the fundamental conventions of modern operating systems is that the required libraries won't get "accidentally deleted"... as software developers this is an implicit requirement we make of our users. If they go and start deleting files from the app directory... well, then they deserve what they get.
If you have a legitimate reason to replace a DLL after the application has been deployed (for example, to encapsulate some functionality that is likely to change) you can create a library that provides interfaces and types that you need from the DLL and link your application against those. Then use reflection at runtime to locate the DLL that has the actual functionality in it. You can then instantiate concrete instances of the classes you need. Note that the DLL must ALSO be linked to the interface library. In this manner you can do 'in-place' replacement of one or more DLLs after the application has been deployed without forcing an uninstall/reinstall.
What sometimes happens is that you have some dll's left in the bin directory, and the application continues to run fine. The delete the bin directory, and it no longer runs. You are probably missing a reference to a required dll that is not required to compile the application, but required by another reference that is required for compilation.
You're going about this the wrong way.
First, if a .DLL is deleted, the users have too many permissions to the Program Files folder. By default, users cannot modify the contents of anything under Program Files, and hence can't delete a .DLL either, under Vista and above. If they can, someone has given the users the permissions required to do so. This is a support nightmare and should be avoided at all costs.
Second, the solution is not with your code, but with your installer. .MSI-based installers can check for the existence of required files when you application is launched and replace them if they are missing. This is the point behind self-healing application support in Windows Installer. If you're installer is written correctly, you don't have to do anything in your code to detect or replace the missing files. Windows Installer will fix them if they are missing.
This content, along with any associated source code and files, is licensed under The Code Project Open License (CPOL)