Several of you tried the tip in Speeding-up DNN Module Development and emailed to report that this does work, but on occasion, the assemblies in the private assembly folder are locked during development. I did some testing to find the cause and a solution.

Background: Assemblies in the "bin" folder are automatically shadow copied to a different folder before the ASP.net process loads them. This allows the files in the "bin" folder to be replaced without causing any locking issues. According to this article even assemblies specified in AppDomainSetup.PrivateBinPath are shadow copied. Of course, this raised the question -- does PrivateBinPath get initialized from the web.config <probing> element.

My curiosity piqued, I did some testing to find the answer. The test is simple enough -- delete the existing shadow copy folder for an app (typically in C:\WINDOWS\Microsoft.NET\Framework\v1.1.4322\Temporary ASP.NET Files\{appname}); setup <probing> with a private path and move some assemblies there; run the app. Assemblies that are shadow copied will then show up in a sub-directory of this folder. In my test, the files from the <probing> path were not shadow copied (i.e. AppDomainSetup.PrivateBinPath is not initialized from <probing> element). But does this explain why the assemblies are locked sometimes? Not completely.

Typically, garbage collection is able to determine if an assembly should be unloaded if there are no more references to its contents. You can ensure that the unload attempt happens right away with GC.Collect(). However, if references to the assembly exist, then GC will not unload the assembly, and since there is no shadow copy, the result is a locked file. If you are recompiling in VS.Net and the file is still locked, it may indicate that there is a problem with your code ... i.e. something has a reference to "something" in your assembly after the ASP.Net page execution is complete. Or, it may not be your code, but VS.Net that has locked the assembly.

I tested with several assemblies that were being used on the page, but were not in the bin folder. Even though these assemblies were not shadow copied, I did not have a problem with them being locked (i.e. an attempt to delete or rename the file works). I could compile/debug etc. with no problem. I suppose it's only a matter of time before I encounter this issue. Is this one of those VS.Net quirks?

Bottom line, there is no quick fix. The "iisreset" command will take care of the locked DLL problem, but then it re-creates the problem that keeping the assemblies in the folder was trying to solve in the first place (i.e. app restart delay). If it does not happen too often, then keeping a command window open and typing iisreset may be the simplest fix (for now).

Working through this problem, I had a thought. What if DNN were to manage the assembly loading and unloading for modules? This would not only allow assemblies to be placed in their respective module folders, but would also solve the problem of DNN DLL-Hell. During development, it would also solve the problem of assemblies being locked as the assembly shadow copying could be enabled when the assembly is loaded on-the-fly.

I don't know the answer, but it's an experiment I'll add to my To-Do list.