none
GAC versus local assembly loading RRS feed

  • Question

  • 1.   Can you verify or state how much faster the GAC loads versus installing in the assembly at Executables location and loading from there is? (I tried to test by hand and saw no difference in timing as far as after the first launch; I'm assuming the assemblies are getting cached)
     
    2.   What happens if you have an application reference an assembly that is not in the gac but next to the EXE. Say we install this new EXE and assembly to a machine with a same strong named assembly that is in the GAC with the same version. Will that app then attempt to load the version from the GAC?

    3.   The reason I'm asking is we have assemblies in the GAC but the versions are not seperated by major or minor at the moment in the policy file we are only redirecting to the latest build number. I'm worried that if in future releases I remove the GAC dependency and put these assemblies next to their relative exes, that co-existence issues will arise where the new software will try to load the assembly from the GAC even though I don't want it to. Is changing the Major or Minor version of these assemblies all it will take to block that?

    4.   I'm wondering also whats the correct order of locations that the OS will search for an assembly at run time? (say the assembly was built referencing an assembly in the GAC)

    Looking for something like: First it will search the location of the EXE, then the GAC, then PATH.

    Thanks,
    Dan
    • Edited by CynisterSeven Wednesday, March 18, 2009 12:28 AM first sentence unclear
    Wednesday, March 18, 2009 12:27 AM

Answers

  • > Can you verify or state how much faster the GAC loads versus installing in the assembly at Executables location and loading from there is?

    Have you run ngen on the assembly?  That part might have a bigger impact than just the assembly being in the GAC.  All in all, I would not expect to get much of a performance gain from using GAC, especially if you are not using ngen.

    > Will that app then attempt to load the version from the GAC?

    If that version number (more accurately, that strong name, which includes the version number) is in the GAC, the bits from the GAC will be loaded.  Otherwise, the bits in your EXE's directory will be loaded.

    > Is changing the Major or Minor version of these assemblies all it will take to block that?

    Make sure that the assemblies you are planned to install alongside EXEs do not have the same version numbers (more accurately, strong names) as what you put in the GAC previously.  The entire version number is matched as a whole (more accurately, the strong name); the system has no special logic that applies just to major, minor, etc (unless you used wildcard * in your policy/configs, then be careful of what impact that might have as well).

    > I'm wondering also whats the correct order of locations that the OS will search for an assembly at run time? (say the assembly was built referencing an assembly in the GAC)

    The official documentation is "How the Runtime Locates Assemblies"  (http://msdn.microsoft.com/en-us/library/yx7xezcf.aspx).  As you probably have become aware, assembly loading is arguably the most convoluted part of the entire .NET Framework.

    Whether or not the assembly was in the GAC when you compiled has no impact on what will happen at runtime.  All it has to work off of is the strong name of the assembly.
    • Marked as answer by Zhi-Xin Ye Monday, March 23, 2009 9:08 AM
    Wednesday, March 18, 2009 1:39 AM