Rick Strahl's Weblog  

Wind, waves, code and everything in between...
.NET • C# • Markdown • WPF • All Things Web
Contact   •   Articles   •   Products   •   Support   •   Advertise
Sponsored by:
West Wind WebSurge - Rest Client and Http Load Testing for Windows

Recycling an ASP.NET Application from within


:P
On this page:

I’m still working on my Localization provider in my ample spare time and one of the things that is a pain is that ASP.NET caches the Resource provider and resource retrieval in internal ResourceSets. The sets load once and then are usually never loaded again for a given resource set and served out of memory instead.

 

This is great for overall performance so even if you build a database provider the performance of it is not going to be that much different from a Resource driven provider because in the end the actual access mechanism using a dictionary is roughly the same.

 

However, during development this is a pain. You make a change to the resources in the database and you want to see those changes, but ASP.NET has them cached. There are a couple of things you can do. What I’ve been doing is manually make a quick change to web.config which restarts the app.

 

After a while that got a bit old, so I wrote a quick method that handles this in my wwWebUtils library:

 

/// <summary>

/// Restarts the Web Application

/// Requires either Full Trust (HttpRuntime.UnloadAppDomain)

/// or Write access to web.config.

/// </summary>

public static bool RestartWebApplication()

{

    bool Error = false;

    try

    {

        // *** This requires full trust so this will fail

        // *** in many scenarios

        HttpRuntime.UnloadAppDomain();

    }

    catch

    {

        Error = true;

    }

 

    if (!Error)

        return true;

 

    // *** Couldn't unload with Runtime - let's try modifying web.config

    string ConfigPath = HttpContext.Current.Request.PhysicalApplicationPath + "\\web.config";

 

    try

    {

        File.SetLastWriteTimeUtc(ConfigPath, DateTime.UtcNow);

    }

    catch

    {

        return false;

    }

 

    return true;

}

 

HttpRuntime.UnloadAppDomain() is the official way to unload an application, but it requires full trust so this is not always an option. The alternative is to ‘touch’ the web.config file by modifying the timestamp which in turn forces ASP.NET to shut down the AppDomain as well. This is more likely to succeed IF your Web account has rights to write the web.config file (ie. NETWORK SERVICE/ASPNET or ISP assigned account).

 

This has been handy. Now what I do on my Test pages that I use to test the provider I have a link unload resources and it goes off and runs this code. I also use this for the localization front end routines that allow special users to change the localized text. Anytime they make a change the app is unloaded so the changes actually show up.

Posted in ASP.NET  

The Voices of Reason


 

Glyn Simpson
October 09, 2006

# re: Recycling an ASP.NET Application from within

Yes! thanks for this. Had to use the touching the web.config for a long while, but this sorts me out.

Thanks

Glyn

# DotNetSlackers: Recycling an ASP.NET Application from within

# A Continuous Learner's Weblog: Links (10/10/2006)


Sevein
October 24, 2006

# re: Recycling an ASP.NET Application from within

Hi Rick! Don't you think it should be a more elegant way to solve this? Your solution helped me a lot but it seems to be a way to do something that ASP.NET does not support officialy or something, don't you think so?

However, in this ASP.NET site example (Basic Instincts: Resources and Localization, http://msdn.microsoft.com/msdnmag/issues/06/08/BasicInstincts/) the author didn't need to unload the application. Why? I feel lost with this.

Anyway, I want to say you have a nice blog and you make a great work! :-)

Rick Strahl
October 24, 2006

# re: Recycling an ASP.NET Application from within

Steve, well HttpRuntime.UnloadAppDomain is 'the official' way to do this except it doesn't work in anything but full trust <s>... The idea is that in theory the application should never have a need to unload the application and in most cases that's probably true.

Resource Providers are cached by ASP.NET so if you change resources the resources are not reloaded. You can write a Resource Manager that unloads its resources (you can close the Resource Set) but there's no real easy way to get at the ResourceManager reliably in ASP.NET. There's no way to unload the ResourceProvider for that matter. So while I've been able to get resources to unload in some situations by calling on the ResourceManager it's not been reliable.

Actually, while running Debug mode even touching web.config doesn't seem to be reliable at times with resources apparently caching even past the lifetime of the application itself. Works reliable at runtime though.

FWIW, assuming you have the rights to do either of these tasks they work well and reasonably quickly.

Amos
November 07, 2006

# re: Recycling an ASP.NET Application from within

Hi. I have come across your post trying to find a solution to a similar problem. I have tried touching the web.config timestamp (I make a 1 second or 1 minute change to it, and prefer to set the original modification time back afterwards; I think that the time the file was last edited is a piece of information that is worth keep meaningful). Anyway, I have noticed it only worked with ASP.Net 1.1 sites, and not with ASP.Net 2. Was there a change in the way the .Net framework treats the timestamp of the web.config file from 1.1 to 2? do you have it working with ASP.Net 2 sites? I only checked it with 1 site of each type so far, and one of them was compiled in debug mode, so mine is not really a "scientific" survey.

Alex
July 17, 2019

# re: Recycling an ASP.NET Application from within

System.Web.Hosting.HostingEnvironment.InitiateShutdown()

Seems like a more modern & better alternative to UnloadAppDomain() (which force-terminates everything immediately)


West Wind  © Rick Strahl, West Wind Technologies, 2005 - 2024