none
GAC install, not found in .Net tab of add reference...

    Question

  • Well,
    I've created a Class Library that will be used with my Code Generator, so I sort of need to have the Class library installed in the GAC.  I've already managed to get the CodeGenerator to work via RegAsm since it basically has to be com visible, though I do some of my registry installation's manually via the ComRegister and ComUnRegister method attributes.  Since the entire idea is that I've created my own descendant of the ApplicatonSettingsBase class, enhancing the Configuration system's design, I needed to write the generator that would insist that the settings.designer.vb file would no longer use the default ApplicationSettingsBase as the ancestor but my own class. 

    Thus, my DynamicApplicationSettings class must be in the GAC or else I have to include the source/class library with each project.  Naturally this will come in later and more complicated when I have to install this into the GAC on the user-systems, most likely involving writing my own MSI, but currently i'm still in the test/debug phase and I'm noticing a little issue.  I compile the assembly:
    System.Configuration.Dynamic (which is also the namespace) and it is located in C:\Source\Visual Studio 2008\GAC.  I go to that directory and run gacutil /i system.configuration.dynamic.dll and it says it is registered. 

    As a secondary test I've jumped out in a command prompt and looked into the C:\windows\assembly\GAC_MSIL directory and I see it there bright as day.  HOwever, in the .Net Reflector when I look in the Cache for dll's to load, or when I go the Visual Studio's "Add Reference" dialog on the .Net page, my assembly is no where to be found. 

    ??? I'm confused now, any ideas?
    Thanks
    Jaeden "Sifo Dyas" al'Raec Ruiner


    "Never Trust a computer. Your brain is smarter than any micro-chip."
    Monday, March 23, 2009 7:54 PM

Answers

  • This is a common gotcha: neither the compiler nor the Visual Studio Add Reference dialog can really reference against the GAC.  Instead, a search path is used.  And the plot thickens:  the search path is different for the compiler (when you use the /r compiler option) versus when you add reference in the Visual Studio Add Reference UI.

    When using the compiler on the command line:

    The search path includes the C:\windows\Microsoft.NET\Framework\v2.0.50727 folder, which has copies of the DLLs that are used by the compiler.  In other words, there is a copy of the .NET Framework DLLs in addition to the ones that are in the GAC.

    Per http://msdn.microsoft.com/en-us/library/s5bac5fx.aspx:

    [quote]

    The compiler searches for assembly references that are not fully qualified in the following order:

    1. Current working directory. This is the directory from which the compiler is invoked.

    2. The common language runtime system directory.

    3. Directories specified by /lib.

    4. Directories specified by the LIB environment variable.

    [quote]

    When using the Add Reference dialog:

    Per http://msdn.microsoft.com/en-us/library/ftcwa60a.aspx:

    [quote]

    The Add Reference dialog box does not automatically display every assembly, even if an assembly has been installed to the Global Assembly Cache (GAC). The Add Reference dialog box is path-based, and there are several methods to display an assembly:

    • Move or copy the assembly to the current project directory (you can find these assemblies using the Browse tab), other project directories within the same solution (you can find these assemblies using the Projects tab), or the Public Assemblies folder at Program Files\Microsoft Visual Studio .NET\Common7\IDE\Public Assemblies; (you can find these assemblies on the .NET tab).

    • Set a reference path to the directory containing the assembly using the Reference Paths Dialog Box (Visual Basic) or the Reference Paths Page, Project Designer (C#).

    • Set a registry key that specifies the location of assemblies to display.

    [/quote]

    The following KB article explains the registry key mentioned above: http://support.microsoft.com/kb/306149

    You could just browse to the assembly on your disk when you Add Reference.  The above gives you some additional options.

    Why is it like this?  Don't know for sure -- seems like Microsoft wanted to keep the compile-time versus runtime parts of the system separate.

    Monday, March 23, 2009 10:39 PM

All replies

  • This is a common gotcha: neither the compiler nor the Visual Studio Add Reference dialog can really reference against the GAC.  Instead, a search path is used.  And the plot thickens:  the search path is different for the compiler (when you use the /r compiler option) versus when you add reference in the Visual Studio Add Reference UI.

    When using the compiler on the command line:

    The search path includes the C:\windows\Microsoft.NET\Framework\v2.0.50727 folder, which has copies of the DLLs that are used by the compiler.  In other words, there is a copy of the .NET Framework DLLs in addition to the ones that are in the GAC.

    Per http://msdn.microsoft.com/en-us/library/s5bac5fx.aspx:

    [quote]

    The compiler searches for assembly references that are not fully qualified in the following order:

    1. Current working directory. This is the directory from which the compiler is invoked.

    2. The common language runtime system directory.

    3. Directories specified by /lib.

    4. Directories specified by the LIB environment variable.

    [quote]

    When using the Add Reference dialog:

    Per http://msdn.microsoft.com/en-us/library/ftcwa60a.aspx:

    [quote]

    The Add Reference dialog box does not automatically display every assembly, even if an assembly has been installed to the Global Assembly Cache (GAC). The Add Reference dialog box is path-based, and there are several methods to display an assembly:

    • Move or copy the assembly to the current project directory (you can find these assemblies using the Browse tab), other project directories within the same solution (you can find these assemblies using the Projects tab), or the Public Assemblies folder at Program Files\Microsoft Visual Studio .NET\Common7\IDE\Public Assemblies; (you can find these assemblies on the .NET tab).

    • Set a reference path to the directory containing the assembly using the Reference Paths Dialog Box (Visual Basic) or the Reference Paths Page, Project Designer (C#).

    • Set a registry key that specifies the location of assemblies to display.

    [/quote]

    The following KB article explains the registry key mentioned above: http://support.microsoft.com/kb/306149

    You could just browse to the assembly on your disk when you Add Reference.  The above gives you some additional options.

    Why is it like this?  Don't know for sure -- seems like Microsoft wanted to keep the compile-time versus runtime parts of the system separate.

    Monday, March 23, 2009 10:39 PM
  • The GAC is just completely unsuitable to act as a source of reference assemblies.  It was designed to store many different versions of assemblies.  And should only be used when required.  As little as possible.  The only way to find an assembly in the GAC is by knowing its name, version, culture and architecture.  Up front.  The exact opposite of what a reference assembly is all about.
    Hans Passant.
    Tuesday, March 24, 2009 1:03 AM
    Moderator
  • I see.

    So by modifying one thing or another that would allow me to "add reference" to that (instead of browsing for the dll directly) that simply allows for the compile time usage of the assembly.  once compiled into EXE form, the system will follow the pre-determined search path (which will find the assembly in the GAC where it's been installed) and all is hunky dory. 

    Seems a bit round about, but I'm sure they had their reasons. 

    Thanks for the pointers BC.
    Jaeden "Sifo Dyas" al'Raec Ruiner

    "Never Trust a computer. Your brain is smarter than any micro-chip."
    Tuesday, March 24, 2009 2:24 PM