Find location of standard .NET assemblies?

For a little C# compiler, I need to find the paths of the standard .NET assemblies like System.dll, System.Xml.dll and pretty much all the assmeblies listed under the ".NET" tab in 开发者_如何学运维the "Add Reference" window in Visual Studio (2010).

I would use the absolute paths but I have a feeling that this can break in exceptional cases.

---

These are all stored in the GAC at %WINDIR%\assembly, which you can view in Windows Explorer.

The actual dlls can be found in subfolders of the GAC, GAC_32, and GAC_MSIL folders, seemingly dependent on their version. On my machine I have three additional NativeImages folders that also appear to contain GAC'd dlls.

Windows Explorer won't allow you to browse these folders directly (as far as I can tell), but you can get there via the command prompt.

The full path for a dll in the GAC is

%WINDIR%\assembly\GACFOLDER\FILENAME\VERSION__PUBLICKEYTOKEN\FILENAME.dll

e.g. On my machine different versions of System.Xml.dll can be found in C:\WINDOWS\assembly\GAC_MSIL\System.Xml\2.0.0.0__b77a5c561934e089 C:\WINDOWS\assembly\GAC\System.Xml\1.0.5000.0__b77a5c561934e089 C:\WINDOWS\assembly\NativeImages1_v1.1.4322\System.Xml\1.0.5000.0__b77a5c561934e089_2775eea1 C:\WINDOWS\assembly\NativeImages1_v1.1.4322\System.Xml\1.0.5000.0__b77a5c561934e089_4c5fbb92

---

When compiling, you can use the reference assemblies under %ProgramFiles(x86)%\Reference Assemblies\Microsoft\Framework\.NETFramework

Also see the registry keys under (HKEY_LOCAL_MACHINE|HKEY_CURRENT_USER)\SOFTWARE\Microsoft\.NETFramework and (HKEY_LOCAL_MACHINE|HKEY_CURRENT_USER)\SOFTWARE\Microsoft\.NETFramework\AssemblyFolders, as documented by KB306149.

The GAC is intended more for run-time use.

---

Most are in the GAC, which is where I believe you are instructed to look with your own compiler. The document that helped with compilers, etc., was found under the .NET Framework in older versions, under the tools developer folder.

I would not be totally adverse to "hardcoding" the folder, per se, but you will be locked to a specific version. I am not suggesting this is the right way, but the location of .NET is not likely to change and most likely your compiler is stuck in a specific version. If you go this route ... To be safe on various machines, you should use %WINDIR% to determine where windows is installed (try cd %WINDIR% in a command prompt if you have never used this and want to see what the variable does). Academic exercise over.

One thing to note is some of what you are attempting may be served better by examining the "compiler as a service" direction MS is heading in vNext (?). This idea/feature is already present in Mono (open source .NET).