Learn More





DNN Community Blog

The Community Blog is a personal opinion of community members and by no means the official standpoint of DNN Corp or DNN Platform. This is a place to express personal thoughts about DNNPlatform, the community and its ecosystem. Do you have useful information that you would like to share with the DNN Community in a featured article or blog? If so, please contact .

The use of the Community Blog is covered by our Community Blog Guidelines - please read before commenting or posting.

Locked assemblies when using <probing privatePath... />

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 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 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 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 path were not shadow copied (i.e. AppDomainSetup.PrivateBinPath is not initialized from 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.

[Reproduced from devTao :: Nik Kalyani on the Developer Way]


Comment Form

Only registered users may post comments.


2sic Daniel Mettler (124)
Aderson Oliveira (15)
Alec Whittington (11)
Alex Shirley (10)
Andrew Nurse (30)
Anthony Glenwright (5)
Antonio Chagoury (28)
Ash Prasad (21)
Ben Schmidt (1)
Benjamin Hermann (25)
Benoit Sarton (9)
Beth Firebaugh (12)
Bill Walker (36)
Bob Kruger (5)
Brian Dukes (2)
Brice Snow (1)
Bruce Chapman (20)
Bryan Andrews (1)
cathal connolly (55)
Charles Nurse (163)
Chris Hammond (203)
Chris Paterra (55)
Clinton Patterson (28)
Cuong Dang (21)
Daniel Bartholomew (2)
Dave Buckner (2)
David Poindexter (3)
David Rodriguez (2)
Doug Howell (11)
Erik van Ballegoij (30)
Ernst Peter Tamminga (74)
Geoff Barlow (6)
Gifford Watkins (3)
Gilles Le Pigocher (3)
Ian Robinson (7)
Israel Martinez (17)
Jan Blomquist (2)
Jan Jonas (3)
Jaspreet Bhatia (1)
Jenni Merrifield (6)
Joe Brinkman (269)
John Mitchell (1)
Jon Henning (14)
Jonathan Sheely (4)
Jordan Coopersmith (1)
Joseph Craig (2)
Kan Ma (1)
Keivan Beigi (3)
Ken Grierson (10)
Kevin Schreiner (6)
Leigh Pointer (31)
Lorraine Young (60)
Malik Khan (1)
Matthias Schlomann (15)
Mauricio Márquez (5)
Michael Doxsey (7)
Michael Tobisch (3)
Michael Washington (202)
Mike Horton (19)
Mitchel Sellers (28)
Nathan Rover (3)
Navin V Nagiah (14)
Néstor Sánchez (31)
Nik Kalyani (14)
Peter Donker (52)
Philip Beadle (135)
Philipp Becker (4)
Richard Dumas (22)
Robert J Collins (5)
Roger Selwyn (8)
Ruben Lopez (1)
Ryan Martinez (1)
Salar Golestanian (4)
Sanjay Mehrotra (9)
Scott McCulloch (1)
Scott S (11)
Scott Wilkinson (3)
Scott Willhite (97)
Sebastian Leupold (80)
Shaun Walker (237)
Shawn Mehaffie (17)
Stefan Cullmann (12)
Stefan Kamphuis (12)
Steve Fabian (31)
Timo Breumelhof (24)
Tony Henrich (3)
Torsten Weggen (2)
Vicenç Masanas (27)
Vincent Nguyen (3)
Vitaly Kozadayev (6)
Will Morgenweck (37)
Will Strohl (163)
William Severance (5)
Try Evoq
For Free
Start Free Trial
a Demo
See Evoq Live
Need More Information?