1

The following saying is quoted from this article in MSDN.

... strong-name signing makes servicing more complicated. Under current versioning policy, an assembly will always attempt to load the exact version of the assembly it was built against. If, for example, your application was built against version 1.0.0.0 of a strong-named assembly and you fix a bug in the assembly, bumping the version number to 1.0.0.1, the existing application will not find the updated assembly.

Now, suppose that two strong-named assemblies (written in C# or VB.net), namely X and Y, exist and X depends on Y.

  1. Does the version of Y is stored somewhere in X in compile time?
  2. Does the public key used in Y is stored somewhere in X to avoid code change attacks?
  3. If the version of Y is checked when CLR loads it, what happens if Y is loaded dynamically and there is no compile time referencing?

Please post references in your answers, if possible.

TonySalimi
  • 8,257
  • 4
  • 33
  • 62
  • The assembly tag is not for .NET assemblies but for assembly programming. – harold Sep 14 '11 at 16:59
  • Your question number 3 made me think of a realisation I made a long time ago... If you register the AssemblyResolve event (which fires when the CLR cannot find a required dependency and gives you a chance to load it), then you call Assembly.LoadFrom, and load the required assembly from some alien path - this will work. Now, imagine you point to the path of a different version, or heck, a different DLL COMPLETELY - this will also succeed! The DLL that you loaded will be put in the 'bucket' LABELLED with the requested assembly name and version, and be used for the rest of the application life! – Adam Oct 26 '11 at 04:08
  • ..continued... Of course, the DLL you return will be expected to have the requisite types/members that the calling code is compiled against. If those members dont exist, then something will fail..., but only when a method or type is 'invoked' that doesnt exist in the surrogate DLL (called a bind-time failure instead of a load-time failure). If you have versioning practices that say "never delete or change members, only add new ones" then your 'dynamic surrogacy' will never fail. Interesting eh? – Adam Oct 26 '11 at 04:10

2 Answers2

2

You can reference Strong Named Assembly either at compile or run time.

Compile time:

When you use compile-time referencing, the compiler automatically gets the public key of the targeted strong-named assembly and places it in the assembly reference of the assembly being compiled.

So it would be stored in the assembly manifest:

Information on referenced assemblies: A list of other assemblies that are statically referenced by the assembly. Each reference includes the dependent assembly's name, assembly metadata (version, culture, operating system, and so on), and public key, if the assembly is strong named.

Run time:

When you make a run-time reference to a strong-named assembly (for example, by using the Assembly.Load or Assembly.GetType method), you must use the display name of the referenced strong-named assembly. The syntax of a display name is as follows:

<assembly name>, <version number>, <culture>, <public key token>

Obviously here is you should specify verison manually in run time.

See How to: Reference a Strong-Named Assembly

sll
  • 61,540
  • 22
  • 104
  • 156
  • 1
    Thanks for your nice, clear, referenced, self-contained, organized and structured answer. I really enjoyed it. – TonySalimi Sep 14 '11 at 16:47
2

1 Does the version of Y is stored somewhere in X in compile time?

Yes, every assembly contains a 'manifest' that records its own identity and that of the references.

2 Does the public key used in Y is stored somewhere in X to avoid code change attacks?

Yes it does

3 If the version of Y is checked when CLR loads it, what happens if Y is loaded dynamically and there is no compile time referencing?

It's usually not checked but see AssemblyName

H H
  • 263,252
  • 30
  • 330
  • 514