I am not sure how many of the DotNetNuke users out there read the monthly newsletter that is sent out, but this morning when the newsletter was sent they mentioned that DNN 4.5.4 RC1 has been released to the Platinum Benefactors, Project Leads, and Core Team members for testing.  From my knowledge this release will include many needed bug fixes to fix items introducted in 4.5.3 and 4.5.2.  However, I also know that some new items will be introduced, one of the most interesteing items would be "SSL Support".  I had discussions with some core team members regarding this feature a few weeks ago so I have a general idea of how this will be implemented, but I am very anxious to see how it all works.

As always you can expect an update from me shortly after the new version has been released with more information.

Recently I have noticed an increased number of questions regarding the upgrade process from DNN 3.x to DNN 4.x and overall I do not think there is very much good documentation available on how to actually complete the upgrade. Therefore with this article I will walk you through the process of upgrading a 3.x site to 4.x, I will try to cover as many of the "gotchas" as possible, but please remember as with all of my other tutorials PLEASE use these at your own risk!

I just released a new version of my Text/HTML Deniable module.  The previous version of the module was having difficulties with data segmentation per module instance.  I have since corrected this issue and now it correctly handles additions and deletions when multiple instances are placed in the same Portal.

Due to the nature of the backend changes this upgrade is a "Breaking Upgrade" and all existing content will be removed as part of the upgrade, so please make backups if you have existing data that you are using inside this module prior to upgrading.  I greatly apologize for the troubles this has caused.  As always please feel free to contact me with any questions or suggestions.

I just noticed the other day that they have finally released the session information for the full OpenForce conference this fall.  It looks like there will be a lot of great sessions and a few open forums that I will not want to miss!  Here is a link to the full details! http://www.devconnections.com/openforce/default.asp?c=1&s=109.

Hope to see all of you there in November!

Reducing the delay time upon first requests to a DotNetNuke or other ASP.NET website is something that I see asked quite often.  This delay is due to the ASP.NET Worker Process compling a website, this articles will discuss the solutions available to prevent this delay from occuring.   I personally find that the simplest solution is the best; the even better part is that it is free! First of all before I talk about the different solutions available let me first explain the issue and why it happens.

Depending on your specific setup and hosting environment this initial load time can be quite lengthy. I have noticed initial load times of anywhere from 4-5 seconds to over 25 depending on the server configuration and load. What is actually happening is that your DNN site is being compiled after the ASP.NET worker process has restarted. The worker process can restart for many reasons, however the most troubling one is due to site traffic. By default IIS will shut down the ASP.NET worker process after 20 minutes of inactivity meaning that the next request will restart the worker process and cause the compilation to occur.

Solutions

Now there are many different solutions to this issue I have recently noticed 4 distinct common recommendations. The first recommendation is a very simple fix, however, for those of us in shared hosting environments we cannot perform the needed changes. If you have access to administer IIS you can change the recycling properties of the ASP.NET worker process for your specific application pool. I have heard of many users changing the value from 20 minutes to be 6-8 hours to ensure that the process does not end until extreme cases of inactivity.

The second method to resolve this issue is the one that I personally use for all of my websites DotnetNuke or ASP.NET. This method relies on using an external service to “request” a page of your site every __ minute. DotNetNuke even provides a .aspx page that you can use for this purpose to limit the bandwidth used by these “keep alive” processes; keepalive.aspx. http://www.host-tracker.com provides a free service to monitor your website the added benefit is that they will track your overall site uptime as well. I use them for this website and they are directed to http://www.mitchelsellers.com/keepalive.aspx for monitoring. This should do a good job to keep your site active as long as the monitoring location sends requests every 10-15 minutes.

The other two options are site isolated elements that I have not yet tested and these involve placing various pieces of code into your application to have it call itself just before the worker process is shutdown. This can be done via an HTTP Module or via the ASP.NET Website Heartbeat event monitoring. I personally have not used these methods as I do not want to modify the DNN core, or the core of any of my ASP.NET applications. However, if you search for these topics online you will find many examples.

Conclusion

I hope this has provided some helpful information regarding the delays experienced when requesting the first page for an ASP.NET website.

I have just completed a round of CSS changes to help with the loading performance of this site.  If you encounter any strange layout issues please let me know.

I am not sure how many DotNetNuke module developers out there are running on Windows Vista but I thought I would share my most recent experience.  I managed to get my DotNetNuke installations up and running a while back with minimal issues with Windows Vista.  However, last night Windows Update prompted me for updates and installed "Visual Studio 2005 Service Pack 1 Updates for Windows Vista".  At first I didn't notice any issues, that was until I tried to open any of my DotNetNuke WAP Modules.

I was given a message about incorrect IIS setup or administrator permissions.  Since I run Visual Studio 2005 as an Admin at all times I knew it was not the issue.  Well in the message they also make a note regarding IIS6 compatiability options being needed.  Well lucklly this is an easy fix.  Simply follow the below.

1. Open the Control Panel
2. Open "Programs and Features"
3. Select "Turn Windows features on or off" (You must grant permission for this)
4. Expand the "Internet Information Services" node
5. Expand "Web Management Tools"
6. Ensure that ALL items for "IIS 6 Management Compatibility" are checked, then click "Ok"
7. Now, try opening/creating your solution in Visual Studio and you should be able to do so.

Overall a very quick fix to get you up and running.  I have tested everything on my machine since performing the update and all is well.  This still doesn't fix the fact that you can't directly open .cs, .vb, .aspx or other Visual Studio files directly from your PC but it at least ensures that you can still use all of your existing code files!

After having my DNN sites up and running for almost a year I was very curious to see exactly how many clicks I had on the various tracked links.  I started to look around and was getting tired of clicking "Edit:" on each link to view the information.  So I created this simple query to quickly pull the links in the "Most clicked" order. 

This is a very primitive query that gets the module name, link, click count and last click time.  For documents loaded in the documents module you will only get the file id of the file, but it at least helps to illustrate the activity.

You will need to edit the PortalId portion of the where clause to ensure that you reference the correct portal.

As I mentioned on Friday I have just released my SQL Formatter/Colorizer application.  This is a helpful utility application for formatting and HTML'izing SQL Scripts.  The application is free to download and use.  You can find more information on the application under the "Software" section of this site!

Many of my regular readers have been using my guides for doing DNN site moves and performing backups and restores from a production environment to another. Overall I have not heard of any issues with the processes I have listed in the past. That was until I actually performed the migration of this site to it's new server the week before Memorial Day. This blog post will cover the issues I encountered while migrating the site to my new hosting provider, these issues were all caused by the Repository module.

Another big change from DotNetNuke that has silently became available is the release of Project Release Information to the public!  You can use this to see where in the internal release process a DNN project is.  The nice thing about this is that no longer will we need to constantly ask the project leads where we are in the process.  This ia something that should help to open the release process information up to the community to keep us more informed.  Below is a link to the new tool!

http://www.dotnetnuke.com/Development/ProjectReleaseTracking/tabid/997/Default.aspx

DotNetNuke released version 4.5.3 on May 31st, which was just a few days after the release of 4.5.2.  The interesting thing with this release is that appeared and not all that much information is available on it from the DNN website.  It does appear to have a fair number of improvements/fixes over 4.5.2, the good news is that you can complete a streamlined upgrade process since no web.config changes were made!

For more information on the actual items included in the upgrade I would recommend looking at the following links...

http://www.dotnetnuke.com/Community/Blogs/tabid/825/EntryID/1446/Default.aspx

http://www.dotnetnuke.com/Community/Blogs/tabid/825/EntryID/1447/Default.aspx

The biggest item I see on this is the issue with user specific permissions, if you are using that feature I HIGHLY recommend upgrading very soon!