Filesystemwatcher and GAC

Question

For the Past few months I was using Filesystemwatcher to find the file system changes in the system. However When I install an Assembly in GAC, Filesystemwatcher doesnot capture the dll registered in GAC. Here is the code. Though the file is created at the location C:\Windows\assembly\GAC_MSIL\ConsoleApplication2\1.0.0.0__aea873120d858924\consoleapplication2.dll, I could not find that in the "str" variable. Instead I have the directory path of it. Does anyone have any idea where it goes wrong.

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);
    }

Answer 1

I suspect you won't find a way to get this working nicely. As you know, the GAC provides a virtualised filesystem allowing assemblies with the same name but different versions to sit as if they were side by side in the same directory. I suspect FileSystemWatcher isn't able to see through this facade.

Perhaps you could maintain your own cache of what is stored in the actual directory structure, and traverse this cache to see what has actually changed when the virtual assembly in C:\Windows\Assembly root changes?

Answer 2

I could not wirte it in comment, hence writing in answer page. @Chris If you see it via Windows explorer. You can only find the path C:\Windows\Assembly, I could find all the Assemblies in the GAC. This looks like a folder but it is virtual, as you said. I could not copy and paste.

However, only when you go through command prompt, you could visualise the existence of the dll. I hope you agree, by anyway windows have to store that assembly somewhere in physical memory and can term it as by different names like GAC. It stores in C:\Windows\assembly\GAC_MSIL\ConsoleApplication2\1.0.0.0__aea873120d858924.

Folder name 1.0.0.0__aea873120d858924 is just nothing but the version and public key of the assembly. To maintain multiple assemblies, they create the folders with this two data.

Here you can do all the operations that you do with folders, but in command prompt.

I understood that filesystemwatcher fails to watch this folder. But If i am copying a sample file "a.txt" to the folder 1.0.0.0__aea873120d858924, It monitors and reports me correctly.

Answer 3

This seems to be Issue with filesystemwatcher and raised it to Microsoft. Thanks for all your replies.

Answer 4

Is your machine 32 bit and the server is 64 bit?

I had a similiar problem, I was compiling the application to run on any platform. The problem is that the OracleDataAccess components that it was installed on the server is for 32 bit, so the assemblies were installed only on GAC_32 folder. Thus when the application try to run on 64 bit mode it doesn't find the assemblies.

So I just recompiled the application as x86 (32 bits) and it worked. The application runs on 32 bit mode and it look for the assemblies in the correct folder.

Did you try that?