Question

I am not a .NET developer, so there might be some basic things I don’t know.

I have some experience coding in C#, but now I have a question. One of my projects (A) references another ptoject (B), with “local copy” set. When B.dll is in the same location as A.exe everything works. But when B.dll is put in a common directory from PATH it doesn’t work.

One of my coworkers said he thought I should make B strongly signed. Is he correct? Is that why one would strongly sign an assembly?

I read a bit about in in the internet but all I saw was about security… If so, how does one sign an assembly and what consequences does it have? Please note that I am using VS2003 .Net 1.1.

Edit: Thank you all very much for your answers, however all the links you provided refer to later versions of VS and .NET which have some sort of Signing tab in project properties. Does anybody know (or give a link )how to strongly name the assembly in VS2003 .Net1.1?

Answer 1

I think that what your co-worker might be referring to is “Strong Naming” an Assembly.
Strong Naming is what enables you to deploy your assembly to the GAC.

Once it is in the GAC, then any application using that assembly can always locate it. Path’s are irrelevant and that is the preferred way to have shared assemblies deployed.

To strong name an assembly, you can use the sn.exe tool that comes with Visual Studio to generate a strong name and then sign the assembly using the keyfile that is generated via sn.exe.

EDIT : Example of how to use SN.exe to strong name an assembly is here

Also, I think you should understand how the runtime loads assemblies. From MSDN

The runtime uses the following steps to resolve an assembly reference:

Determines the correct assembly version by examining applicable
configuration files, including the application configuration file,
publisher policy file, and machine configuration file.

If the configuration file is located on a remote machine, the
runtime must locate and download the application configuration file
first.

Checks whether the assembly name has been bound to before and, if so,
uses the previously loaded assembly.

Checks the global assembly cache. If the assembly is found there, the
runtime uses this assembly.

Probes for the assembly using the following steps: If configuration
and publisher policy do not affect the original reference and if the
bind request was created using the Assembly.LoadFrom method, the
runtime checks for location hints.

If a codebase is found in the configuration files, the runtime checks
only this location. If this probe fails, the runtime determines that
the binding request failed and no other probing occurs.

Probes for the assembly using the heuristics described in the probing
section. If the assembly is not found after probing, the runtime
requests the Windows Installer to provide the assembly. This acts as
an install-on-demand feature.

Note: There is no version checking for assemblies without strong
names, nor does the runtime check in the global assembly cache for
assemblies without strong names.