Как использовать FileSystemWatcher для изменения данных кэша?

Question

мое приложение считывает данные DLL из кэша.но если какой-либо разработчик изменит DLL, DllCaching должен измениться.Поэтому я использую FileSystemWatcher для обнаружения любых изменений в DLL.

Мой механизм systen Watcher ниже: этот проект находится в asp.net

    public void CreateFileWatcher(string path)
        {
            FileSystemWatcher watcher = new FileSystemWatcher();
            watcher.Path = path;

            watcher.NotifyFilter = NotifyFilters.LastAccess | NotifyFilters.LastWrite | NotifyFilters.FileName | NotifyFilters.DirectoryName;
            watcher.IncludeSubdirectories = true;
            watcher.Filter = "*.dll";

            // Add event handlers.
            watcher.Changed += new FileSystemEventHandler(OnChanged);
            watcher.Created += new FileSystemEventHandler(OnChanged);
            watcher.Deleted += new FileSystemEventHandler(OnChanged);
            watcher.Renamed += new RenamedEventHandler(OnChanged);

            // Begin watching.
            watcher.EnableRaisingEvents = true;
        }

   private static void OnChanged(object source, FileSystemEventArgs e)
        {

             //FillCache
}

Button1_Click
{
CreateFileWatcher(@"C:/data")

// like that:
    myarray = CachData
}

Как это сделать?как загрузить dll (снова загружается), когда Dlls меняется.

Answer 1

Трудно понять, как очистить кеш, если вы используете кеш в своем приложении, и это становится сложным, когда вы реализуете собственную логику для очистки кеша. Если вы используете кеш EnterpriseLibrary, мы можем иметь зависимость при добавлении элементов в кеш. Любое изменение в этом файле очистит кеш.

Ниже приведен пример кода. Та же перегрузка доступна и для кеша asp.net.

FileDependency cacheFileDependency = new FileDependency("\\mynetworkpath\abc.txt");
cacheMgr.Add(cacheName, cacheValueList, 
             Microsoft.Practices.EnterpriseLibrary.Caching.CacheItemPriority.Normal,
             null, cacheFileDependency);

Answer 2

Вы не понимаете, как работает ASP.NET, я полагаю.Вот мое видение, надеюсь, оно поможет вам понять проблему и найти подходящее решение.

Я включаю FileSystemWatcher в элементах управления на стороне сервера, что, в частности, не означает использование одного экземпляра, которое толькоозначает, что конкретный клиент получил доступ к вашей веб-форме или тому, что будет предоставлено (не совсем, на самом деле) хотя бы одному потоку.Это также означает, что поток IIS может иметь меньше количества, чем требуется клиентам.

В дополнение, это также означает, что вы не можете эффективно использовать шаблон Singleton, а также хранилище сеансов или файлы cookie (егонарушит закон в случае асинхронных вызовов веб-фермы).

Единственный действительно работающий вариант - реализовать веб-сервис и накапливать изменения, удаления или добавления к указанному пути к серверу (не физическому пути, а скорее IIS (или любому веб-серверу, например, моно).т. е. \ etc \ bin \ dlls \, которая может быть эффективно переведена на физический путь к серверу с использованием http-классов BCL для веб-сайтов) и периодически получать необходимую информацию.

Если вы желаете получить такойнапрямую информацию, которая будет невозможна, потому что всегда будут пропуски, между экземплярами мониторинга, где эта папка будет в неконтролируемом состоянии, например, между одним клиентским потоком завершается, и незадолго до того, как следующий клиент подключится к серверу, напримеркогда пользователь загружает большой файл на страницу, а затем вызывает F5 или обновляет страницу, но страница перешла в состояние с истекшим сроком (состояние с истекшим сроком означает, что значимое состояние страницы для клиента потеряно, возможно, потребительский поток клиента насервер завершил свою работу или перешел к следующему клиенту вочередь.