

- #Filewatcher created passing parameters how to#
- #Filewatcher created passing parameters update#
- #Filewatcher created passing parameters full#
First we must retrieve a reference to the object from the application collection, then remove it from the collection, and finally dispose the object:

#Filewatcher created passing parameters how to#
The following function shows how to do this. To be a good citizen we should ensure that we dispose of this object properly at application end.
#Filewatcher created passing parameters full#
Note the use of the Server.MapPath function to obtain the full path of the application directory from the relative path provided by IIS. The basic code for adding a FileSystemWatcher to an ASP.NET application looks like this: Care should be taken when applying synchronisation in a server environment to ensure that performance and scalability are not compromised. To manage the lifecycle of the FileSystemWatcher it must be stored in this collection.Įvent handlers for the FileSystemWatcher events may be added to the Global class, but you must ensure that they only access data in the Application collection, and that they do so in a thread-safe manner (see my previous article). This seems like the obvious place to put our FileSystemWatcher object, but although Global.asax defines a class named Global (derived from HttpApplication), the ASP.NET system will not necessarily use the same instance of this object for all of the events handled there!Īpplications in ASP.NET store application-wide information in name/value pairs in the AllKeys collection of the Application object (a member of HttpApplication and thus Global), and ASP.NET does ensure that the Application object is the same for each event handled. When you create a project with Visual Studio it automatically creates for you a Global.asax file that contains handlers for the principle events in the lifecycle of an application including Start and End. In this article I will show how FileSystemWatcher can be used within web applications, and then go on to describe the Cache mechanism that provides an ASP.NET specific alternative.
#Filewatcher created passing parameters update#
Some of the responses I received were asking about the use of FileSystemWatcher within ASP.NET applications, for example to update a product list.

This would allow files to be copied up to a file-based web server (e.g. The original article mentioned using FileSystemWatcher to update files on a web server, and the model I envisaged was similar to the Photo Library application described in the article. I received a number of responses to my article in the July/August edition of VSJ, Your fingers on the filesystem, regarding the use of the FileSystemWatcher class in ASP.NET applications.
