ASP.Net: Add extra files to be monitored to trigger AppDomain recycle

Question

All of my Asp.Net websites use a separate configuration system, driven by XML files, which is responsible for building an awful lot of the objects used throughout the sites; effectively a series of uber IOC containers might be used to resolve anything from controllers for MVC sites, to data services and configuration objects for back-end code.

The XML builds a bunch of dynamic methods which are then hidden behind a factory interface. Once loaded and built, those methods will not be rebuilt until the App Domain recycles.

The smallest change in one of the files, then, can have a profound effect on the functionality of the website and thus updates often can be deployed as a simple config change. The files can appear within the website root and any child folder within it - but not, typically in any of the standard Asp.Net folders (App_LocalResources etc).

But because the files don't use an extension that Asp.Net/IIS recognises as being 'important' (let's say the extension is .configfoo), if I change one of them I have to manually ensure an app domain restart on the server by either:

a) Touch the web.config to force an AppDomain restart; or

b) Recompile the binaries

What I would like to do is to somehow tell Asp.Net/IIS to include these files in its monitoring, and treat them as being as important as .config files and the .dlls in the bin folder; triggering an app domain restart if any of them change.

UPDATE in response to Artem's answer

I've tried placing the files in either the bin\ or in App_LocalResources, for example, and indeed the AppDomain is restarted - which is good news, but... I don't like bin\ deployment because the only way to get the file updated easily in development is to do a build (unless you manually copy/paste) and it also doesn't fit with the concept of these files being Content - which is what they actually are, and need to be treated as from a deployment perspective.

Equally, the App_LocalResources (et al) solution is great, but is not natural from a developer point of view - it's a configuration file and therefore should be able to placed in the same place as other configuration files (there's also the small matter that VS seems not to see my Item Template that I've done if I'm adding to this folder due to its context-sensitive Add New Item dialog).

Finally it doesn't solve the problem of the other freeform folders that a project might have which might contain .configfoo files alongside aspx/ascx/master/.config files etc. Unless I force these folders to all be placed inside one of the Asp.Net folders of course, but nobody expects to find a page inside App_LocalResources!

END Update

Failing this - I do remember seeing a bit of code a couple of years ago where a FileSystemWatcher was used, which triggered an AppDomain.Unload within the site itself according to its own file-based rules. I think the preferred method now would be to use System.Web.Hosting.HostingEnvironment.InitiateShutdown.

This would be my last resort as I'm hesitant to roll my own when I already know that what I want is already being done for some other extensions.

So is it possible to add other dependancy files to those being watched? Or am I going to have to roll my own?

Any advice, as always, greatly appreciated

Answer 1

In the end I rolled my own.

On web application startup I set up a FileSystemWatcher monitoring the AppDomain.BaseDirectory and all its sub folders with a filter of *.configfoo.

I then hooked into the four events that are raised (Created, Renamed, Deleted, Changed) which then calls System.Web.Hosting.HostingEnvironment.InitiateShutDown() (and then sets a flag to prevent it calling it again, as the FileSystemWatcher will often raise multiple events for one file system action).

Finally set FileSystemWatcher.EnableRaisingEvents = true; and hey presto.