Questions about referencing assemblies in GAC

[Richard Zebo]

I have a few questions about properly referencing assemblies and those in
the GAC.

We are making a commercial .NET assembly DLL to be used as a class library
from ASP.NET pages. At install time we will put our DLL in the GAC.

1) What is the right way for our customers to refer to the assembly from
their ASP.NET pages? The @ Assembly Name directive looks like it can be
used, but it presents upgrade issues - I think. For example let's say they
use this code in their ASP.NET page:

<%@ Assembly
Name="Widget,Version=1.0.0.7,culture=neutral,PublicKeyToken=83fa83ad231235"
%>
<%@ Import Namespace="MYAssembly.Widget" %>

Is this the only approach that people can reference the assembly directly
from the GAC?

2) So now what happens when we release version 2 of the product, say
2.0.1.5. Let's assume that the customers do not update their Assembly Name
directive to change the version from 1.0.0.7 to 2.0.1.5. Also let's say
that 1.0.0.7 is still in the GAC. Then they are going to run with 1.0.0.7
still right?

3) Now what about the case when 1.0.0.7 is removed from the GAC and 2.0.1.5
is installed. And let's say that they do not update the version in their
Assembly Name directive. Will the .NET framework automatically load 2.0.1.5
for them since it is a close match or will it fail to find the assembly? I
think it would be the later.

4) Is there any type of language or directive that can be used to tell the
framework that they always want it to run the latest version of the assembly
in the GAC? For example could you specify a wildcard for the version, like
<%@ Assembly
Name="Widget,Version=*,culture=neutral,PublicKeyToken=83fa83ad231235" %>?

5) We had some test customers that put copies of the DLL in their local bin
directory which worked great. But then when we gave them a new build with
an update version number they received an error that it couldn't find the
assembly, because apparently the required assembly name was compiled into
their ASP.NET application. Is there a way we can do something so that they
can update a DLL withou the need to recompile their application under this
scenario?

Thank you in advance.

*RZ*

 

[Candan Akyol]

Hello Richard,

Appearently, Visual Studio.NET places the @Assembly directive as you
specified and I haven't heard of a wildcard usage of the version attribute.
AFAIK, the fully qualified assembly name is compiled into the code, this is
the expected way for an application not to break when a new version of the
assembly without backwards compatibility is installed.

For preventing your customers from recompiling their code when a backwards
compatible new version is installed, you can instruct them to "redirect" the
requests to version 1.0.0.7 to 2.0.1.5. This can be either be done
application-based (in application configuration files) or machine-based (in
machine.config file) with the following snippet:

<configuration>
<runtime>
<assemblyBinding xmlns="urn:schemas-microsoft-com:asm.v1">
<dependentAssembly>
<assemblyIdentity name="Widget" publicKeyToken="83fa83ad231235"
culture="neutral" />
<bindingRedirect oldVersion="1.0.0.7" newVersion="2.0.1.5"/>
</dependentAssembly>
</assemblyBinding>
</runtime>
</configuration>

You can also create a publisher policy file to do the same thing. I am not
sure whether your customers can remove the old version from GAC after this
configuration. For more information, see "Redirecting Assembly Versions"
topic in .NET Framework Developer's Guide from MSDN.

Hope this helps.