Recently I have been asked by multiple people what rapid design tools I use, or what types of code generation tools do I use.  Many people are surprised when I tell them that for the most part I don't use any rapid generation tools.  I do use a few home grown tools, such as my Info Class Generator, which is available on this site.  However, that is as far as I go with automated code generators.  However, one thing that I have started using more and more frequently are Code Snippets within Visual Studio.

I have found that creating a few helpful Code Snippets has allowed me to quickly and easily format my code, and build my needed structures in almost no time.  In this blog article I will share two of my most commonly used Code Snippets, if there is a demand I will post future code snippets here as well.

 The question on which is better WSP (Website Project) or WAP (Web Application Project) has been one asked many times on this site and DotNetNuke.  Over the past months I have provided explainations that fit for each of the specific applications, however, I never really took the time to provide a full compare/contrast article that shows you the overall ease of using one over the other or the hidden downfalls of one over the other.  This article will take you through a number of steps to compare the two development models, so you can make your own decision on which is better.

A question I have been asked many times recently is how do you debug a DotNetNuke module that has been developed using the WAP (Web Application Project) development model.  This is a question that I have known the general answer to for quite some time, but I have never actually had a need to truly debug one of my custom modules.  During the course of helping a client with an issue today I actually took the time to document all steps necessary to debug a WAP DotNetNuke Module within Visual Studio 2005.  This article will walk you through all steps necessary to debug your project.

I just released my ASP.NET Global Error Handler HttpModule that can be used to capture application level errors and send e-mail notifications to a specified individual.  For more information and to download this item please click on the following link. Click here to visit the ASP.NET Global Error Handler Download Page

I have had many requests in the past few weeks to look at building a module that would wrap around the Telerik radSchedule component that is due out in the near future to allow instant drop-in to DNN as a module.  I contacted Telerik to try and obtain permissions to re-distribute this if I built it and this is the response I got.

We had a detailed discussion with my colleagues and decided that at this moment we cannot offer you Redistribution rights as your product will not offer significant functionality to our RadScheduler component and this scenario will contradict with our License agreement terms. In fact this is one of the most important requirements that every customer needs to abide to in the cases when there is redistribution of our components as part of commercial products. It is always hard to turn down someone's business, and I am hopeful that we will have other opportunities to cooperate in the future.

So basically I get two things out of this.

• Making their module a drop-in usable item in DotNetNuke is not an enhancement
• They expect all customers to wait until they build it themselves "in a future release"

I am deeply saddened by these series of events as I thought this would be a great contribution to the community and something that I might have even been able to cooperate with them on, however, that does now appear out of the picture.

I just wanted to keep all of those that have asked up to date. Now I am off to talk to Infragistics to see what they say!

Recently there have been numerous discussions on the DotNetNuke.com Forums regarding hosting providers and who one should go with and who they should switch to because they are unhappy with their current provider. During all of these discussions I have always recommended the company that I use for hosting 3Essentials. Since making this recommendation I have been receiving numerous e-mails regarding the process to actually migrate a live site over to 3Essentials so I thought I would write a short blog article that explains the basics of moving a website over to 3Essentials, in actuality these instructions SHOULD work for most providers, however ther might be some differences.

Search Engine Optimization (SEO) has become a very popular topic among the DotNetNuke community as well as in all other types of web development. I do not claim to be a master in SEO, however, I do have a number of tools that I use to help judge the SEO capacities of my websites and also a number of directories that I utilize to enhance the visibiliy of my website. In this article I will share some of these sites, links, and directories that might help improve your websites search engine placemen and/or popularity/visibility.

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 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!

Tom over at Seablick.com has posted a great article regarding a method to provide a proper SEO friendly 301 redirect to keep your site under 1 actual address (www.mysite.com instead of that and mysite.com).  This is a very important SEO item.  You can view his article at the following link.

seablick.com/blog/tabid/53/articletype/articleview/articleid/44/default.aspx

I found the following article to be very helpful when I was looking for a method to call a specific javascript function right after an AJAX request.  blog.jeromeparadis.com/archive/2007/03/01/1501.aspx

For my readers that are using DotNetNuke to build AJAX enabled applications you must perform one additional task in your code-behind file to ensure that you have a script manager referenced for use on the front end of your application. To accomplish this you must simply place the below call in the page load event and ensure that it is called at least on the first load of any page that needs access to the script manager.

DotNetNuke.Framework.AJAX.RegisterScriptManager();

At one point or another everyone has a need to include an HTML form within a DNN website. This might be to link to a PayPal Buy it now button or one of many other options. Well as most of us know it is not possible to simply put a HTML form into a Text/HTML module and have the form submit. This is due to the ASP.NET form that is existing in the website that is used to handle all server side controls. However, there is a fairly simple method to allow the form to post using some simple javascript. A special thanks goes to John Mitchell who covered this specifically relating to the PayPal Buy it now buttons in this blog post.

To include an HTML form within DNN you will first need to note the "Action" property that is set in the <form> tag. Once you know this action you will want to remove the opening and closing form tags. Now, in the HTML source location the submit button (<Input type="submit"> or similar) . Then add the following inside the tag declaration.

Be sure to put your Action URL inplace of the "YourUrlHere" text. This tells the HTML form that if the submit button is clicked that it should change the form action, which will prevent ASP.NET postback and then it actually submits the form to the new URL.

This provides you a quick and reliable method to submit HTML forms to external sites. This isn't the best solution as other input items on the current page will be submitted to the action page, however, typically that is not too large of an issue.

NOTE: this also works in any other ASP.NET application.

Like many ASP.NET programmers I utilize a third party hosting company to host all of my sites. We have all ran into situations where we have been loosing sessions and other oddities and it would be very helpful to find out exactly what caused the application to restart. Well thanks to this post on DotNetNuke.com by Frankt I have found a way to track this information. In this entry I will provide you with code that can obtain this information