Файловая система-наблюдатель и GAC - PullRequest
Новая
       28

Файловая система-наблюдатель и GAC

2 голосов
/ 02 апреля 2011

В течение последних нескольких месяцев я использовал Filesystemwatcher, чтобы найти изменения файловой системы в системе.Однако, когда я устанавливаю сборку в GAC, Filesystemwatcher не захватывает dll, зарегистрированную в GAC.Вот кодХотя файл создается в каталоге C: \ Windows \ assembly \ GAC_MSIL \ ConsoleApplication2 \ 1.0.0.0__aea873120d858924 \ consoleapplication2.dll, я не смог найти его в переменной "str".Вместо этого у меня есть путь к каталогу.У кого-нибудь есть идеи, где это идет не так. 

static void Main(string[] args)
    {

        str = new List<string>();
        FileSystemWatcher fs = new FileSystemWatcher(@"c:\");
        fs.IncludeSubdirectories = true;
        fs.Created += new FileSystemEventHandler(OnFileCreate);
        fs.Changed += new FileSystemEventHandler(OnFileCreate);
        fs.EnableRaisingEvents = true;
        new System.EnterpriseServices.Internal.Publish().GacInstall(@"C:\Users\jijiadmin\Documents\Visual Studio 2008\Projects\ConsoleApplication2\ConsoleApplication2\bin\Debug\consoleapplication2.dll");
        Console.ReadKey();
     }
     static void OnFileCreate(object e, FileSystemEventArgs ev)
    {
            str.Add(ev.FullPath);
    }

Ответы [ 4 ]

1 голос
/ 03 апреля 2011

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

Возможно, вы могли бы сохранить свой собственный кэш того, что хранится в фактической структуре каталогов, и просмотреть этот кэш, чтобы увидеть, что действительно изменилось, когда виртуальная сборка в C:\Windows\Assembly корне изменяется?

0 голосов
/ 28 сентября 2011

Является ли ваша машина 32-битной, а сервер - 64-битным?

У меня была похожая проблема, я компилировал приложение для запуска на любой платформе.Проблема в том, что компоненты OracleDataAccess, которые были установлены на сервере, предназначены для 32-разрядных систем, поэтому сборки были установлены только в папке GAC_32.Таким образом, когда приложение пытается работать в 64-битном режиме, оно не находит сборки.

Поэтому я просто перекомпилировал приложение как x86 (32 бита), и оно заработало.Приложение работает в 32-битном режиме и ищет сборки в нужной папке.

Вы пробовали это?

0 голосов
/ 11 апреля 2011

Это, похоже, проблема с файловой системой и подняла ее в Microsoft.Спасибо за все ваши ответы.

0 голосов
/ 04 апреля 2011

Я не мог записать это в комментарии, поэтому писал на странице ответов. @Крис Если вы видите это через проводник Windows. Вы можете найти только путь C: \ Windows \ Assembly, я мог бы найти все сборки в GAC. Это похоже на папку, но она виртуальная, как вы сказали. Я не мог скопировать и вставить.

Однако, только когда вы проходите через командную строку, вы можете визуализировать существование dll. Я надеюсь, что вы согласны, в любом случае, окна должны хранить эту сборку где-то в физической памяти и могут называть ее другими именами, такими как GAC. Он хранится в C: \ Windows \ assembly \ GAC_MSIL \ ConsoleApplication2 \ 1.0.0.0__aea873120d858924.

Имя папки 1.0.0.0__aea873120d858924 - это всего лишь версия и открытый ключ сборки. Для поддержки нескольких сборок они создают папки с этими двумя данными.

Здесь вы можете выполнять все операции с папками, кроме командной строки.

Я понял, что filesystemwatcher не может смотреть эту папку. Но если я копирую образец файла «a.txt» в папку 1.0.0.0__aea873120d858924, он отслеживает и сообщает мне правильно.

...