Please correct me if I'm wrong, but it appears that the way you describe how to use this makes it unhelpful for people running DNN or other ASP.net apps on shared website hosting.

People using shared website hosting don't have the ability to start/sop services or to execute any console applications. Generally there's no control whatsoever over the remote IIS server, usually all one can do is install files.

For this to useful in a shared website hosting situation, this app should probably be self-starting somehow.

Thank you, Tom

Tom,

In fact how this application operates allows all users as long as they are administrators on some sort of Windows machine whether that be a Windows XP/ Vista desktop or a Windows 2003/2008 server to utilize that application in the exact same manner.  To further clarify this application does NOT need to reside on the same piece of hardware as your DNN or ASP.NET application, thus it works great for those who do NOT have access to administrative services on their hosting server or are in a shared hosting environment.  If you do not have access to a server of any sort simply install this application locally on a desktop computer you have access to, the service / application is as reliable as the machine you place it on.  I will attempt to work up an application diagram on the interworkings of the application and post it on my site, should be up by end of day, check http://www.derektrauger.com/Products/ApplicationPoolDefibrillator/tabid/98/Default.aspx towards the end of the day.  You might ask why does it not need to reside on the same server as my DNN installation or ASP.NET application, the answer is simple the application does not care or need to know that the URL provided is a DNN site or an ASP.NET site, rather it simply takes the URL provided and "pings"  (not a real ping) it so to speak.  This "ping" action simply keeps the application pool alive and prevents it from becoming idle and unloading from memory.  This is a tool that affects Microsoft IIS and how it handles application pools / worker process.  Because DNN is a ASP.NET application that happens to run under Microsoft IIS this tool helps alleviate this problem as it would with any other ASP.NET application.  To even further simplify you can liken the application to the process of someone manually opening a web browser every x amount of minutes and attempting to browse to the site in question, this action keeps the application pool / worker process in memory and allows your site to load faster.

If you need further clarification, please let me know.  Check out my site later today for an application diagram.

Thanks.

Derek