Speeding-up DNN Module Development
On the DotNetNuke forums today, jstemper posed a question about how to speed up DNN development, specifically, the delay caused by app re-start when a module is recompiled.
I have invested a considerable amount of time researching the intricacies of Fusion probing to faciliate the co-existence of third-party assemblies with different versions in the same bin folder. In an earlier post on Managing assembly versions in ASP.Net I had provided tips on doing this. Reading this post got me thinking about applying the same technique for DNN development. I did a quick test and everything seems to work. Here is how you can speed-up DNN module development by skipping the app restart that occurs when assemblies in the “bin” folder are updated.
1) Create a “bin” folder under ~/DesktopModules (i.e. ~/DesktopModules/bin)
2) Modify your DNN web.config as follows:
<runtime> <assemblyBinding xmlns="urn:schemas-microsoft-com:asm.v1"> <probing privatePath="bin;DesktopModules\bin" /> assemblyBinding> runtime>
If you have a
The “privatePath” attribute tells Fusion where to search for assemblies referenced by an application.
3) Change your module’s script (ascx) file so the “Inherits” attribute includes the assembly name like this:
Inherits=”Speerio.DNN.Modules.SkinStudio.Editor, Speerio.DNN.Modules.SkinStudio”
This corresponds to a typename of “Speerio.DNN.Modules.SkinStudio.Editor” and an assembly file “Speerio.DNN.Modules.SkinStudio.dll” (note: the extension should not be included in the “Inherits” attribute value).
4) Change your module’s VS.Net project build folder to ~/DesktopModules/bin
That’s it. Now, when you recompile your module, there will be no application restart and the only assemblies that are converted from bytecode to native code are your module assemblies.
Please post a comment if you encounter any problems so I can modify the procedure if necessary.
Andrew J. Leer
Dude your link is to "Managing assembly versions in ASP.Net" is broke.