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.