Last post Apr 06, 2006 01:47 PM by ikamiksok
Mar 31, 2005 09:14 AM|neilyoung|LINK
I don't need nearly all of the predefined DNN 3 modules (except account management and login). I just need DNN as a carrier and manager of selfmade modules.
Is there a chance to get rid of predefined modules anyhow?
Mar 31, 2005 09:31 AM|mathisjay|LINK
Mar 31, 2005 10:05 AM|neilyoung|LINK
Hmm. I did it already. This removed the modules as expected, but did not significantly boost the development/trial process. The problem behind is that the process of changing, recompiling and testing needs incredibly long over here (on a 3 GHz P4...). My
suspecion is, that this is due to the recompilation process whenever a module assembly (mine) has changed. Unfortunately it seems, that _all_ assemblies are recompiled again, whenever just one changes... That takes too long.
Probably I have to remove the DLLs as well...
Mar 31, 2005 10:46 AM|Imsoccrman|LINK
Just 'cuz you don't need them doesn't mean you might not use them :-)
You could also go in and define them as premium modules so that you can hide them on the portals unless you decide that you want them... would be a little lower impact than actually delting them.
Mar 31, 2005 11:00 AM|neilyoung|LINK
Is this forum moderated? I already answered, but my posting did not appear...
Just for testings. Please ignore.
Mar 31, 2005 11:43 AM|Richard Cox|LINK
If you are developing a standalone custom module in another project other than DNN's project (but under the solution) then change the DotNetNuke project in vs.net's configuration manager to not compile - also change any other projects that you don't need
to recompile to not compile. That still won't help you on the assembly load times when you start the app, but should help on the compiles. In your development environment, remove any modules that you don't require, and remove them from the solution as well
so they don't build. That's about as quick as you are going to get.
I do have to agree with you regardless, the development->load->test cycle times are very slow - I'm running a 3.2 / 2GB mem workstation and it's very slow in development mode. Luckily we were able to move back down to DNN 2 for our development environments.
Mar 31, 2005 11:47 AM|Imsoccrman|LINK
Are you talking about the compilation in Visual Studio or the JIT that occurs after the DLLs change ?
From my experience, on a machine that is much lower powered than yours, when i place a new DLL in the bin folder, the app takes around 10 seconds to JIT... I don't think you would notice enough a difference by deleting the module DLLs... If your machine
is taking longer than that to JIT the assemblies, I would think there's something else going on there.
BTW - are you re-compiling ALL of the projects (all 54 of them) and placing the updated DLL's en masse on the server ? I generally only compile the project that I am directly working with rather than compiling all of htem... I generally remove all of theprojects
that I do not feel that I need to work with in my module and only leave my module project and the DNN core Project in the solution. I then set the DNN project to NOT compile through the build configuration manager. This lets you compile only your module DLL's
when the solution is compiled. This also speeds the IDE up as the classes for all of these other projects don't have to be loaded...
Hope that helps,
Mar 31, 2005 01:16 PM|neilyoung|LINK
Hello Richard, Hello ImSoccrMan,
thanks for your answers. I already suppressed the build of all modules exept buildsupport and my module. I'll try to uncheck buildsupport as well and report the results.
That all - of course - minimizes the build time. The point is the JIT time. If I look into my bin folder after compilation, both the buildsupport and my module dll have changed. No other. But nontheless the test run with F5 (debug) needs about 45 sec to
present the very first page. And this, if I only change "Hello world" to "Hello word" and recompile :)
That's why I thought it might be a good idea to get rid of all unnecessary modules (at least for dev purposes uneccessary) on JIT time...
I can't believe the 10 sec :) BTW: My machine does not have any problems on JIT and compilation of other apps with less modules.
Mar 31, 2005 01:44 PM|Richard Cox|LINK
that was the primary reason why we had to forgo development under DNN 3. We figure we lost slews of man hours using DNN 3 as the primary development platform prior to us getting BDPDT cross version between DNN 2 and DNN 3 working fine.
Another thing to try is to run ngen on your assemblies to speed up the load time. Read all about it here:
I'm running a 3.2 hyperthreaded, and I'm lucky if I get the debugger binding to the assemblies happening in 10 seconds let alone DNN to the home page. You're not the only one that finds that hard to fathom [:)]
Mar 31, 2005 02:24 PM|Imsoccrman|LINK
Mar 31, 2005 03:19 PM|neilyoung|LINK
Thanks for the hints.
I just took a fresh installed DNN 3, compiled the solution "DotnetNuke.Core". Note: There is no own module in the game.
Compilation ~5 secs. F5 (debug mode) ~50 secs until DNN comes up. I tried that promissing ngen and put all DNN DLLs into the native cache (ngen /show does list the files correctly after having setup them for caching). But - there is NO difference. Exactly
the same 50 secs...
Very strange...This solution does not compile in RELEASE mode, so I can't comment on the speed here...
The processor load is below 10 % for the first 30 sec. After that until the end of the load it is ~100%
Update: I could manage to compile a release version (for some reasons the solution has lost the references to CountryListBox.dll, DotNetNuke.WebControls.dll and DotNetNuke.WebUtility.dll, means: All these files have been deleted (!!) after the switch from
Debug to Release and vice versa). I have noticed that loss of reference several times, but didn't think too much about, just referenced the files manually again, but it seems to happen in conjunction with the Debug/Release switch.
Nevermind: There is no difference in load time behavior compared to Debug :(
Steve: You mentioned you copy the fresh compiled versions to a server for testing. Does that mean, you do not compile into bin directory directly? I think to remember, that a simple "touch" to on of the assemblies does really not affect the load time...
hmm. needs to be verified again...
Update2: If I just rename DotNetNuke.Core.BuildSupport.dll to something other and back the load time is about 15 secs, so near to your value (what would be OK). A new browser session w/o the rename action is up < 1 sec.
Mar 31, 2005 04:33 PM|neilyoung|LINK
So, here is somewhat to think about (what I kindly ask you to verify):
Core solution rebuild and start with F5: ~50 secs
Core solution stop/restart with F5: ~2 secs
Rename one of the assemblies back and forth, restart with F5: ~15 secs
So far nothing new.
As I told above I usually compile my modules into the global bin directory. I created an empty new module and rebuild the solution. Result on F5 ~50 secs.
After that I recreated the project and let it drop the assembly into a directory different from bin.
Recompile/Restart F5: ~2 secs (this is because the global bin hasn't been changed). After that I copied my modules's assembly into the global bin and restarted the app. The result: 15 secs! I would treat this as piece of evidence, that Steve is right and
Richard and me is right too.
If you keep your own modules assembly off of the global bin and just copy it (manually) into the bin after compilation, the load time decreases dramatically.
I do not have a clue, what the reason for that odd behavior is... The difference in the projects layout is: Whereas in situation a) my project has a reference to the DotNetNuke project as well as BuildSupport has a reference to me, in b) my project has only
the DotNetNuke reference and BuildSupport is untouched. Hence my module compiles to somewhere outside global bin...
Not really a solution, but a starting point for further investigations.
Update: Strange, strange... I gave the VS DNN templates a second chance and ... voila: It works!! I have my assembly in the global bin, I have the .ascx in DestopModules and I have ~15-20 secs load time _AFTER CHANGE AND RECOMPILE_ in DEBUG Mode... Perfect.
I can just recapitulate, how I made my projects up to now. I just followed the instruction given in a traincert demo video.
a) Start with one of the provided solutions (I took Core) and build it
b) Create a new class library project, name it following the naming convetions, remove default namespace, remove class1.vb, save it unter DesktopModules
c) Add a reference to Dotnetnuke project and add a reference to your project in BuildSupport
d) Add some *.ascx...
The resulting DLL in global bin and the .ascx in a folder under DesktopModules.
The whole trial and error process took about 50 secs.
Now I have exactly the same folder layout, but based upon the VS templates from dnnjungle... and it works fine... Crazy.
Apr 01, 2005 03:09 PM|neilyoung|LINK
Forget about all I told you :(
New project, same problems. I CAN'T FIGURE OUT, WHAT MADE THE BUILD AND LOAD SO "FAST" YESTERDAY.
Today I can try what I want: I cannot get faster than 50 secs.
Apr 01, 2005 03:45 PM|neilyoung|LINK
Currently I have the 20 sec load back again.
What I did? I ignored all predefined solutions and created a new project from scratch in VS. I used both, the templates from dnnjungle and the PACT stuff. I created two new projects, both located under DesktopModules with output to global bin. I did not
change any of the deployed binaries of DNN3. In order to make debugging possible I configured both projects to URL debugging.
Changing the projects and hitting F5: 20 secs later the app is running.
Great. Hopefully that situation is reproducible...
May 12, 2005 08:29 PM|walterman|LINK
This thread is full of usefull information. However try as I might I cannot get the 50-60 second JIT time down to a reasonable timeframe. My assumed sure-fire method (based on stuff from this thread) was to compile everything in release mode, make my changes
in a solution with only my module, then copy the dll into the DNN\bin directory. This hasn't helped - still seeing 45-60 second JIT times. Has there been any further revelations on this topic?
May 13, 2005 05:25 AM|neilyoung|LINK
I agree. I also cannot manage less than 50 s currently... This is one of the major blocking points for DNN to me...
I'm doing the things with ASP.NET 2.0 currently.
May 13, 2005 09:13 AM|exptrade2000|LINK
May 13, 2005 12:42 PM|alexdresko|LINK
First, I'd like to say that I'm not the worlds best coder. But I do know that having to step into the debugger frequently is a sure sign that your coding process needs improvement. I rarely ever fire up the debugger any more. My unit tests run lightening
fast and point out most problems before needing to debug. Proper use of OO techniques, unit testing, commenting, naming conventions, logging, design patterns, etc will greatly reduce the need to debug.
By the way, I can have my nUnitASP confirm that every page in the website is working flawlessly in about 20 seconds. This basically involves forcing nUnitASP to log into DNN and loop through all of the records in the Tabs table while testing them for errors.
So sure, it takes me 45-50 seconds to get DNN to start with F5, but as little as I have to do it, I don't complain.
There are some (not I) who think debugging is for pansies.
May 13, 2005 12:56 PM|brian_c|LINK
also in localhost .. clearing cache or updating certain parts of the settings just keeps running forever (or until timeout) .. still have no idea why ...
I dont understand why it takes longer on my 3.2 HT with 1GB mem .. much much longer than on the actual server .. is .net really that cpu/mem intensive or is it DNN.. ??
May 13, 2005 04:59 PM|walterman|LINK
I'm undoubtedly not the coder you are. In fact this is the first coding I've done in years. I'm writing a pretty complex module from the ground up and honestly I cannot imagine a scenario where this amount of code could be written without a lot of step-through
debugging - both to fix my own logic and to figure out the nuances of DNN.
I wrote most of the ASCX files in an independent project, but now that it's been incorporated into a DNN module I cannot tweak and fix bugs or add simple new functionality without the entire DNN core JIT'ing every time. So other than being a better coder,
is there a trick I'm missing?
May 13, 2005 05:31 PM|jjmartin|LINK
Here's how I do it - I have very little issues with load time.
I have my browser up and navigated to my localhost DNN site.
I make my changes in code, and ctrl-shift-b (recompile).
Alt tab to the web browser refresh or click button or whatever (JIT runs about 10-20secs).
Evaluate any issues.
If I need to debug, I set a breakpoint, go to the Debug menu, Processes, choose aspnet_wp.exe.
alt-tab (i actually have two monitors so i just usually click on the web browser on the other screen, to be honest). Resfresh, reclick - whatever... VS enters break mode...voila.
Doing this, i can usually recompile and retest without ever leaving debug mode, although I don't stay in debug mode often.
Should I need to debug client script, I attach to the IE process that has my page up.
May 13, 2005 06:07 PM|michael1047|LINK
I have a 3.2 1GB machine (dell) and have no load time issues.
Sometimes the cache will get hosed if you copy your project .dll into the global bin directory (which is just as bad as "touching" the web.config file); thus, causing (I believe) a binary compatibility check with the related/referenced dll files.
I found it quite a pain in the *** to copy the .dll files into the global bin. I found that if I change the project's build properties from bin/ to ../../bin/ (which is the global bin directory) I didn't have to copy the file anymore and speeds increased
by almost a factor of 3. (not to mention the time it took to actually navigate and copy the .dll) Unfortunately, I like to keep my .aspx pages away in a separate folder, so I have to nav/copy those every time I make changes.
Just a note too, you can make form changes in the html view without getting out of debug mode. heck, there's been times I just did a lot of table layout for controls while in run mode. Keep in mind, the design view will not let you do the same thing.
oh, fyi, check out WebHarpoon on snowcovered.com; also, be sure to check out the comments about that product. It sounds like that product may allow you to create forms without having the overhead of DNN (but still use DNN as a wrapper).
One more note, (I think you're doing this), is make sure that you only build the project folder you need -- and put them in release mode.
Cheers! (and good luck!)
May 13, 2005 06:07 PM|jbrazell|LINK
My how things have changed. Early in my career, I worked with a few large programs that took 45-60 minutes to compile. Many of them could compile in 3-5 minutes. Now we expect sub-second compiles. [;)]
Actually, I find them to be frustrating when I am trying to make a minor correction as well but this thread reminded me of our changing expectations.
May 14, 2005 03:37 PM|walterman|LINK
I'm going to beat this horse one more time...
I'm running on a 3.2 1gig Dell laptop. Of course HD performance isn't that of a desktop machine, and may explain why many of you see 15-20 second waits to my 60 second waits. My HD grinds a lot during this period. I downloaded and ran filemon to see what
was going on - there were almost 6000 files opened and closed during this time, including 400 created files. Most of this activity is from aspnet_wp.exe and vbc.exe, and most of the file access is in temporary directories. This seems
extraordinary. But the really frustrating thing is I've got .5 gig RAM free the whole time. Why doesn't all this activity go on in memory???? I've played with all the cache settings, even
going into the registry and making changes per some tips I found on the web.
So, does this info spur any more ideas from you geniuses? Is there a way to move this activity into a RAM drive or something?
May 14, 2005 06:54 PM|bhopkins|LINK
First I have to admit I have not read this entire thread so this may have been mentioned already You say you are seeing a lot of hard drive thrashing. During a compile. Do you see this a loty even when you are not compliing.. If so you may want to check
the fragmentation of your file system as this sounds like a possiblity to one issue you may be having here. You may nto be seeing 60000 files opened but rather 60000 fragments opened. I've never used this filemon and I'm not sure what my own machine does in
this instance, but this does resemble a machine which needs a good defrag and maybe some other general housekeeping issues worked on.
May 14, 2005 09:58 PM|walterman|LINK
Good thoughts, I'll do a defrag tonight but it's not likely to help. There are actually 6,000 files being opened - there are over 30,000 file system events during this period - fragments being read, files being locked, directory trees being
queried, etc. I have a log of every filename and the application that opened it.
I assume my wait times are around 60 seconds simply because a typical laptop harddrive has half the performance of a typical desktop machine (I gather from this thread that most other debuggers are seeing 20-30 second JIT times). I also assume that this
much activity is typical of how .NET does it thing.
Improving this it will have dramatic benefit to all DNN developers. A huge bulk of the activity is in "C:\WINDOWS\Microsoft.NET\Framework\v1.1.4322\Temporary ASP.NET Files" - if this directory location is configurable this activity could be moved to a RAM
drive. I'm considering doing the same thing for the DNN global bin.
BTW, filemon is a simple utility to log database activity for this type of debugging. You can find it at
May 17, 2005 05:07 PM|walterman|LINK
My problem at heast has been solved. I created a 64 meg RAM drive and pointed the temp directory to that drive (via the machine.config). My JIT times went from 50-60 seconds to 15-20 seconds.
May 17, 2005 05:22 PM|midspot|LINK
May 17, 2005 08:19 PM|aaava|LINK
My problem at heast has been solved. I created a 64 meg RAM drive and pointed the temp directory to that drive (via the machine.config). My JIT times went from 50-60 seconds to 15-20 seconds.
May 17, 2005 11:31 PM|walterman|LINK
Here are the details:
1) I downloaded the ramdrive software from SuperSpeed software (http://www.superspeed.com/download/trialversions.php).
2) Setup a 64 meg drive, configured as FAT32
3) Add a "tempDirectory" attribute to the machine.config file (located at C:\WINDOWS\Microsoft.NET\Framework\v1.1.4322\CONFIG. The tag looks like this when done...<compilation
My results were dramatic probably due to my slow laptop HD. If your CPU is pegged the entire JIT process you may not see much of an improvement. Please post your results, I'm very curious.
May 19, 2005 02:01 AM|neilyoung|LINK
excellent job. It works for ASP.NET 2.0 too. Just one thing: The closing sequence of the a.m. tag has to be"/>" instead of ">".
Due to the long development cycles I dropped DNN meanwhile. I'm currently using VWD Beta 2 together with the GoLive license in order to build and roll out my new app. Nevertheless the RAMDRIVE trick does the job here too, so a remarkable boost can be seen.
I'm using the default MS RAMDRIVE.
EDIT: Final statement: RAMDRIVE setup on two machines (ASP.NET 2.0 OK, ASP.NET 1.1 OK). The boost for DNN is nearly NULL :( It still takes ~30 secs after F5 until the browser notes "website found" and ~50 secs until DNN is up and running.
I'm through with it ...
May 19, 2005 08:47 AM|oziweb|LINK
<My how things have changed. Early in my career, I worked with a few large <programs that took 45-60 minutes to compile. Many of them could compile <in 3-5 minutes. Now we expect sub-second compiles
Not too sure how far back your early days went but in my early days we only got one compile a day . Compiles in those days was to actually run the program today compiles are used to debug the code. If you went over 3 compiles for the same program then you
were expected to explain why to the system programmer
But then in those days we wrote programs bigger then dnn that ran in 64Mbyte of memory or less on a mainframe - How indeed have things changed.
But back to the active disk during compile - defrag the disk and move the swap file off the source/compile disk. I would also turn off any antivirus or disk checkers during the compile - if you are compiling on a W2003 system switch it from web to application
It is just as well that PC's unlike mainframes of old don't dump out 450 pages of a memory dump during a bad compile.
Jun 03, 2005 04:20 PM|DevDave|LINK
When I open the Configuration Manager in VS 2003, I cannot uncheck any of the build checkboxes. Does anyone know what my problem might be?
Aug 10, 2005 11:08 AM|jjmartin|LINK
Aug 10, 2005 03:01 PM|DevDave|LINK
Aug 16, 2005 07:08 PM|jjmartin|LINK
Aug 17, 2005 09:29 AM|walterman|LINK
Aug 17, 2005 01:01 PM|jjmartin|LINK
what sort of horrendous grinding to a halt happens when this drive is filled? (If its not obvious as to what the problems is, i'd like to know what symptoms to look for.)
Aug 17, 2005 03:57 PM|walterman|LINK
Jan 27, 2006 05:00 PM|roachslayer|LINK
Jan 27, 2006 06:03 PM|walterman|LINK
No idea, but JIT performance for me in 2005 has been fantastic, I wasn't going to bother trying to improve it with a ram drive. But then again, I've only been playing with it for a few hours so far.
Jan 27, 2006 06:12 PM|roachslayer|LINK
Cool trick. Any ideas how to set the Temp directory for compilation in VS 2005? Machine.config is different.
Somewhat solved for myself: Web.config has a place for
tempDirectory in the <compilation> tag. It works. Of course, this means it is per project, so I'd have to do this to each project I want to use the RamDisk temp drive.
Jan 31, 2006 12:06 PM|paul.meyer|LINK
Feb 02, 2006 01:19 PM|exptrade2000|LINK
Ok, here are my findings so far. First my setup. Build support (release, build). My module(debug, build). Everything else has been compiled in release mode and will not be recomplied. Build Support builds into global bin. Kill asp.net process, hit F5 45-50
sec. till first page shows up.
I downlaoded ram disk from
http://www.superspeed.com/download/trialversions.php and installed E: drive. Size: 60 MB. Changed compilation in web.config, hit F5 and I get 20-25 sec till first page is served. Very nice.
Now I go and look into the E:\temp folder. There are hundreds and hundreds of folders and files. Each dll that is in the global bin directory gets copied in its own folder with with __AssemblyInfo__.ini file and actual dll. I am going to remove all DLL's
that I do not use and see if I get even better performance.
Oh, I forgot I this is on the Dell laptop D810
Feb 02, 2006 01:53 PM|exptrade2000|LINK
Now I removed all dll that I do not use, like desktop modules, support dlls etc. and I get 20 sec exact every time.
Feb 03, 2006 07:07 PM|roachslayer|LINK
Apr 06, 2006 01:47 PM|ikamiksok|LINK
I've had my eye on this thread for sometime as I had some serious problems and page load times would take 2 minutes sometimes after doing a compile. I tried everything. But then my computer crashed and I had to start from scratch. Turns out to be a good
thing as though it took me 2 weeks to recover all my files and get back where I was, I now run at 10 secs. It seemed like it kept getting worse and worse.
So, not sure what might have slowed it down. But perhaps starting from scratch may help someone with a serious problem. So reinstalling IIS, VS, maybe try a newly formatted drive, full defrag, etc.....
ps: thanks for the ramdrive suggestion as it helped me. cause i think that may have been what crashed my computer and made me start over! ;)
so read up on it just in case (i tried a 30 day trial version suggested on this thread). it was only 2 weeks after getting it that my windows bootup failed after I had to powerdown my pc after it locked up while i was using visual studio.