HomeHomeArchived Discus...Archived Discus...Developing Under Previous Versions of .NETDeveloping Under Previous Versions of .NETASP.Net 1.1ASP.Net 1.1Debug optimization helpDebug optimization help
Previous
 
Next
New Post
8/15/2006 8:10 PM
 

Anyone have any suggestions on ways to speed up the debug startup when developing modules?

I thought I read someplace about a way to not have DNN restart each time you recompiled a module in development.

 

TIA

John

 
New Post
8/16/2006 3:44 AM
 

Hmmm...that would be useful.

However, to the best of my knowledge, making any changes to the "bin" folder (i.e. adding or modifying an assembly) triggers an app restart in ASP.Net so I don't think one can get around that. You can speed things up by either not including the core code in your solution, or excluding it from being re-compiled each time. This will minimize the number of assemblies that have to be re-processed (i.e. byte code to native assembly) on each debug attempt.

Nik

 


Nik Kalyani
Co-founder
DotNetNuke Corporation
Blog | Twitter | FaceBook
 
New Post
8/16/2006 6:07 AM
 

I'm wondering if putting the DNN core stuff in the GAC (Dev only, not Prod) might help? I will have to try and play with that sometime.

 

John

 
New Post
8/16/2006 7:08 AM
 

Yes, putting the assemblies in the GAC will work.

Your post got me thinking and I found another way that's more flexible -- put the module assemblies outside the DNN "bin" folder. Since ASP.Net only monitors the "bin" folder for changes to trigger app restarts, putting your module assemblies in ~/DesktopModules/bin, for example, bypasses the app re-start.

The process is quite simple and I did a quick blog post with the exact steps to facilitate this -- Speeding-up DNN Module Development

Nik

 


Nik Kalyani
Co-founder
DotNetNuke Corporation
Blog | Twitter | FaceBook
 
New Post
8/16/2006 9:57 AM
 

I have a solution for this case, at least it worked for me.

When you use source package of DNN you are able to debug, because the assembly of the project is compiled to debug, not to release.

The problem is that by default, all projects in the solutions are marked to build. This way, everytime you run the application using Visual Studio, all project are re-builded, and the access to the pages are slow, because every access is considered the "first-time" to the .NET framework.

To solve this problem, I simply unchecked all projects in the option Configuration Manager, including tha main project. In VWD it´s in the Build menu.
In my case, I don´t need to change none of the core modules and projects, just my modules. I didn´t have any trouble doing this configuration.

Maybe in the first time after you uncheck the options the page processing would still be slow. It´s because the last time you made the access by Visual Studio, the code was pre-compiled.

When I discovered that I :
1- Copied all projects again
2- Opend in VWD and uncheck to not build.
3- After that I run the app before the build occur, without the delay .

I hope this solve your problem.

Guilherme Hahn
Brazil.

 
Previous
 
Next
HomeHomeArchived Discus...Archived Discus...Developing Under Previous Versions of .NETDeveloping Under Previous Versions of .NETASP.Net 1.1ASP.Net 1.1Debug optimization helpDebug optimization help