Assembly Binding and Visual Studio Projects

  • Thread starter Thread starter Chris Marsh
  • Start date Start date
C

Chris Marsh

All

I'm still grappling with assembly binding - hopefully I'll grok it soon :)

I create a strong named assembly. I add a reference to this assembly to a
project in Visual Studio. When I view properties for the assembly reference
in Visual Studio, I am informed (correctly) that the assembly is strong
named. However, when I look at the .csproj file in a text editor, there is
no version, indication of strong name, or public key. Where is this metadata
stored?

In an MSDN article on assembly binding
(http://msdn2.microsoft.com/en-us/library/yx7xezcf(VS.71).aspx) the
following is stated: "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.". Therefore, the runtime must have access
to metadata regarding the strong name (or not) of an assembly referenced at
design time, otherwise it would not know whether to check for it in the GAC
or not at runtime?

Can someone explain this to me possibly? I'm struggling to grasp this, but I
think that once I understand where this metadata is stored and how the
runtime accesses it, everything else will fall into place.

Many thanks in advance for any asssistance!
 
All

A quick thought - the metadata to which I refer below would be managed by
Visual Studio rather than the runtime, right? The information about
references would be in the assembly manifest buy the time that the runtime
is involved in the binding process, so presumably what I'm *actually* trying
to understand is the mechnism by which Visual Studio manages assembly
references?

Cheers!
 
All

On the offchance that anyone's following this thread apart from me:

The path displayed in the reference properties is found in the .csproj.user
file, so that's one question answered.

So: when an assembly reference is added, VS reads the assembly manifest and
can tell what version and culture are applied to the assembly. It can also
tell if the assembly is strong named. Further questions, then:

Does the .NET runtime get the referenced assembly version information from
the manifest of the referencing assembly? If not, how does the runtime know
whether the assembly is strongly named or not and therefore whether to look
in the GAC? If so, where do the publisher policy file and/or config files
come into things - do these settings override those in the referencing
assemblies manifest?

TIA for any thoughts at all on the subject!
 
Hi Chris,

From your description, you have some questions about the .NET assembly's
metadata and strong-name binding ,correct?

As for metadata, it is always stored in assembly file itself(store as a
header section in assembly and have fixed structure and format). Thus,
runtime can read information about assembly from its metadata. Metadata can
not only contain strong-name info, but also many other useful info such as
Type information, assembly properties info....

For strong-name, it is one feature which utilize metadata as the storage.
Strongname need a key pair and after assembly is built, strong-name key
token has been embeded into the assembly's metadata as an identity.

Here are some articles which introduce some on them:

#Metadata and Reflection in .NET
http://www.odetocode.com/Articles/288.aspx

#Security Briefs: Strong Names and Security in the .NET Framework
http://msdn2.microsoft.com/en-us/library/aa302416.aspx

If you have interests, you can use the "ildasm.exe" or "reflector" tools to
open the assembly and view strong-name info.

For Visual Studio, it is an development tool/IDE, the project file does
store some assembly name and path info. However, those information doesn't
related to the runtime assembly binding and locating behavior. Those path
and file info(in project file) just help indicate a certain location where
Visual Studio can find a copy of the assembly so that when performing the
compile/build, visual Studio can locate an assembly(for reference).

At runtime, the CLR runtime will use another strategy to locate any
assembly that is referenced by the application. Here is the MSDN reference
describe .NET runtime's assembly loading behavior:

#How the Runtime Locates Assemblies
http://msdn2.microsoft.com/en-us/library/yx7xezcf(VS.80).aspx

Hope this helps.


Sincerely,

Steven Cheng

Microsoft MSDN Online Support Lead



==================================================

Get notification to my posts through email? Please refer to
http://msdn.microsoft.com/subscriptions/managednewsgroups/default.aspx#notif
ications.



Note: The MSDN Managed Newsgroup support offering is for non-urgent issues
where an initial response from the community or a Microsoft Support
Engineer within 1 business day is acceptable. Please note that each follow
up response may take approximately 2 business days as the support
professional working with you may need further investigation to reach the
most efficient resolution. The offering is not appropriate for situations
that require urgent, real-time or phone-based interactions or complex
project analysis and dump analysis issues. Issues of this nature are best
handled working with a dedicated Microsoft Support Engineer by contacting
Microsoft Customer Support Services (CSS) at
http://msdn.microsoft.com/subscriptions/support/default.aspx.

==================================================


This posting is provided "AS IS" with no warranties, and confers no rights.

--------------------
 
Steven

Steven Cheng said:
From your description, you have some questions about the .NET assembly's
metadata and strong-name binding ,correct?
[..]

#Metadata and Reflection in .NET
http://www.odetocode.com/Articles/288.aspx

#Security Briefs: Strong Names and Security in the .NET Framework
http://msdn2.microsoft.com/en-us/library/aa302416.aspx
Click to expand...

Good articles, thanks.
If you have interests, you can use the "ildasm.exe" or "reflector" tools
to
open the assembly and view strong-name info.
Click to expand...

Ah, illuminating.

[..]
Hope this helps.
Click to expand...

Very much. I think I understand the whole process now, and am creating a
flowchart for quick reference.

Cheers!
 
Thanks for your followup Chris.

Glad to be of assistance.
BTW, welcome to share your flowchart with us:)

Sincerely,

Steven Cheng

Microsoft MSDN Online Support Lead


This posting is provided "AS IS" with no warranties, and confers no rights.
--------------------
From: "Chris Marsh" <[email protected]>
Subject: Re: Assembly Binding and Visual Studio Projects
Date: Tue, 18 Dec 2007 10:24:47 -0000
Click to expand...
Steven

Steven Cheng said:
From your description, you have some questions about the .NET assembly's
metadata and strong-name binding ,correct?
[..]

#Metadata and Reflection in .NET
http://www.odetocode.com/Articles/288.aspx

#Security Briefs: Strong Names and Security in the .NET Framework
http://msdn2.microsoft.com/en-us/library/aa302416.aspx
Click to expand...

Good articles, thanks.
If you have interests, you can use the "ildasm.exe" or "reflector" tools
to
open the assembly and view strong-name info.
Click to expand...

Ah, illuminating.

[..]
Hope this helps.
Click to expand...

Very much. I think I understand the whole process now, and am creating a
flowchart for quick reference.

Cheers!
Click to expand...
 
Steven

Steven Cheng said:
Thanks for your followup Chris.

Glad to be of assistance.
BTW, welcome to share your flowchart with us:)
Click to expand...

The flowchart can be found at the following location:
http://www.cjmarsh.com/assembly_binding.jpg. Any comments on format, or
errors and omissions will be gratefully received. The only thing I haven't
mentioned is the <probing> element of the application configuration file -
I'm not sure how to represent this without the [already large] diagram
becoming out of control.

Cheers!
 
Steven

Steven Cheng said:
Thanks for your followup Chris.

Glad to be of assistance.
BTW, welcome to share your flowchart with us:)
Click to expand...

The flowchart can be found at the following location:
http://www.cjmarsh.com/assembly_binding.jpg. Any comments on format, or
errors and omissions will be gratefully received. The only thing I haven't
mentioned is the <probing> element of the application configuration file -
I'm not sure how to represent this without the [already large] diagram
becoming out of control.

Cheers!
 
Back
Top