I'm aware of how you add references to assemblies that are in the GAC.

The issue seems to be a bug in VSNET2003 -- it's not checking for later versions of assemblies when copy local is set to false.
Except when you open a project -- then it does an automatic update of the reference.

- Mark

Gary,

I was summarizing a somewhat more complicated picture. I don't actually load the strong named assembly in the GAC statically. What I
do is load an assembly which references a strong named assembly which is already statically referenced in the project. This leads to
a problem with Type resolution. The load is done via LoadFrom(), with a file reference. The assembly I'm loading with LoadFrom() is
the assembly of the project being built.

I do this because I need to be able to resolve Types in the current assembly at design-time. For example, I have a user control
which exposes a property that must be set to a Type exposed by the same assembly that contains the user control. This is similar to
the functionality in VSNET of being able to add user controls defined in an assembly to other controls in the assembly (i.e., the My
Controls toolbox tab).

Example:
    Project1 contains a static reference to Assembly A, which is strong-named and in the GAC. This reference, by default, is
Copy Local = false.

    Project1 extends a control class (Control C) defined in Assembly A. Call this extended control class Control E.

    At design-time, Project1 needs to be able to examine Control E, and potentially allow instances of it to be added to other
controls in the Project. To do this, a control designer in Project1 dynamically loads the Project1 assembly (which, of course, has a
static reference to Assembly A).

    If I set Project1's reference to Assembly A to Copy Local = True to get Project1 to automatically update the Assembly A
reference for updates, then the designer insists that typeof(Control E).IsSubclassOf(typeof(Control C)) is False...even though they
are clearly related. For example, typeof(Control E).BaseType.AssemblyQualifiedName is exactly equal to typeof(Control
C).AssemblyQualifiedName.

I've read in the dotnet.framework discussion group that this behavior is by design, because AppDomains maintain two separate lists
of loaded assemblies, one for assemblies that are statically referenced and one for assemblies that are dynamically loaded.

That's why I apparently have to leave Copy Local set to False...even though I'd prefer to have it set to True.

BTW, if you know of another design pattern for examining the assembly of the current project I'd love to hear it. I've always
wondered how VS.NET itself handles the situation.

- Mark