4

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?

Armen Tsirunyan
  • 130,161
  • 59
  • 324
  • 434

5 Answers5

5

Your problem is not related to assembly signing in the first place. .NET does not use the PATH environment variable to load assemblies. The process is actually a bit more complex and you best read all details in MSDN (also see steps 1 to 4):

How the Runtime Locates Assemblies

In your case it might be the best to install the shared assembly to the GAC. Installing to the GAC requires that your assembly has a strong name, so this is probably what your co-worker referred to.

Update:

As you asked specifically about strong-naming a .NET 1.1 assembly I'd suggest checking out the following question:

How to give a .NET 1.1 dll a strong name in VS2003

Community
  • 1
  • 1
Dirk Vollmar
  • 172,527
  • 53
  • 255
  • 316
2

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.

Allen Zeng
  • 2,635
  • 2
  • 20
  • 31
Jagmag
  • 10,283
  • 1
  • 34
  • 58
  • @Armen - Both links updated for .NET 1.1. Note: Most of this usage is unchanged from 1.1 so any of the other links should have been pretty much the same in any case. – Jagmag Nov 16 '10 at 11:01
  • @Armen - Also added an MSDN link with steps as to how to use SN.exe – Jagmag Nov 16 '10 at 11:03
  • @InSame: Just one more question, true or false: Gac is local to the computer/OS, so if I want to place the assembly into GAC, I need to do it on every computer. That information is not in the assembly itself. Correct? – Armen Tsirunyan Nov 16 '10 at 11:38
  • 1
    @Armen - true. In case of a thick client application, that would ideally be something that your deployment package should be doing at the time of install. You can use gacutil utility to do the same. – Jagmag Nov 16 '10 at 14:45
1

The right way to do this is by deploying your .dll in the GAC. http://support.microsoft.com/kb/815808

Oded
  • 489,969
  • 99
  • 883
  • 1,009
Stefan P.
  • 9,489
  • 6
  • 29
  • 43
1

what is the reason you want to put the B.dll in a common directory? is it because it can be used by a another program? if so adding it to the GAC is the best option. See this one

Illuminati
  • 4,539
  • 2
  • 35
  • 55
1

As 0xA3 already mentioned you should read the article at MSDN. But what is not so good explained in the article is the usage of the AssemblyResolve event. It will be thrown if the Framework didn't find the assembly at any place, givin you a chance to start a search on yourself (maybe in your common folder) and return the needed assembly.

An example on how to use this, can be found in my question here.

Community
  • 1
  • 1
Oliver
  • 43,366
  • 8
  • 94
  • 151