I have the following problem when creating an and loading an assembly: I followed the steps described as anywhere i looked for documentation regarding this issue and the result is not quite what I expected. I obtain a shadow copy of my dll, but both files, the original and the shadow copied dll are locked by the process. Here is a piece of the code, please tell me what is wrong with it and what should i do for the original dll not to be locked anymore System. appDomainSetup = new (); appDomainSetup. Shadow CopyDirectories = "D:\\pathToMyApp\\bin\\Debug"; appDomainSetup. Shadow CopyFiles = "true"; appDomainSetup.CachePath = "D:\\pathToMyApp\\bin\\Debug"; appDomainSetup.ApplicationName = "appName"; System. appDomain = System. .CreateDomain("Domain" + "someName", new System.Security.Policy. ( .CurrentDomain.Evidence), appDomainSetup); System.Reflection. assemblyName = System.Reflection. .GetAssemblyName("pathToTheDll"); System.Reflection. assembly = appDomain.Load(assemblyName); I also tried using the Load(byte[] buffer) version of .Load, but in this case, the shadow copy is not created anymore but the original dlls is used by the application, which, by the way, seems very strange to me. --------------------------------------------------------------------------------- The problem lies in the way .Load() works. When you make a call to .Load, the assembly is loaded in the target domain (which is appDomain in your case) BUT the call returns a reference to the same assembly back to your parent domain (the one where the code is running). When this happens, the dll gets loaded in the parent domain where there is no setting to shadow copy the files. So you see, shadow copy is working for the target domain, but it doesn't happen in the parent domain. Hence, the file gets locked. If you want to load the assembly in the target domain without getting a reference back in the parent domain, you will have to write a class that will load the assembly for you in the target domain. i.e., something like a proxy object where you would first create an instance of the Loader object in the target domain and then call Loader.LoadMyAssembly(filename) which would load the specified file in the target domain and NOT return any reference to it. The only caveat is that you should never get a direct reference to the loaded assembly, even if it just an interface. The moment you do that, it will get loaded in your parent domain and you're back at square one. There is an excellent article on this topic by Eric Gunnerson on MSDN called ' AppDomains and Dynamic Loading'. You should take a look at that.