.NET framework version vs. the CLR version

[Aleksander Oven]

Hi,

I'm building a native application that will host managed 3rd-party
assemblies. Before loading each assembly, I'd like to check if the
required CLR and .NET version are present, and display a warning if
it turns out they're not.

Using the GetFileVersion unmanaged API gets me the CLR version that
assembly was linked against when it was built. For assemblies built with
VS2008, this will almost invariably be v2.0.50727, since this is the
latest CLR available (for now).

As it turns out, this is not sufficient...

Assemblies might be using some of the features that weren't made
available before .NET framework v3.x (for example LINQ), which means
that the "Target framework" property had to be set to, say v3.5, when
building those assemblies. However, GetFileVersion still returns
v2.0.50727 even in such cases.

This means that my check might give a false positive if it finds the
v2.0.50727 .NET framework installed, because it won't know it should
actually check for v3.5.

So the question is: do assemblies carry the information about the
required .NET framework version as well as the required CLR version?

If not (most probable to me), what else can I do to implement a safe
check?

 

[Jon Skeet [C# MVP]]

So the question is: do assemblies carry the information about the
required .NET framework version as well as the required CLR version?

Well, not so much the framework version itself as the names and
versions of all the assemblies they reference. Just check the
referenced assemblies, and make sure they're all present and correct.

 

[Aleksander Oven]

Just check the referenced assemblies, and make sure they're all

present and correct.

Ah, bingo! I assume the assembly manifest is the place to look for
this info?

If yes, is there an established way for an unmanaged code to iterate
the entries (short of loading the resource and parsing the xml
manually)?

 

[Jon Skeet [C# MVP]]

Ah, bingo! I assume the assembly manifest is the place to look for
this info?
Yup.

If yes, is there an established way for an unmanaged code to iterate
the entries (short of loading the resource and parsing the xml
manually)?

I don't know if there's a simple API available for it, I'm afraid.

 

[Aleksander Oven]

I don't know if there's a simple API available for it, I'm afraid.

No worries. I'm quite adept at XML.

Thanks, Jon! You've been very helpful (and really fast, too).

 

[Jon Skeet [C# MVP]]

No worries. I'm quite adept at XML.

That's fine - although I'm not sure which bit of XML you're referring
to, to be honest. There's *some* XML in an assembly, but not the
relevant information as far as I'm aware.

If you look in the assembly manifest with ildasm, you want the
".assembly" entries. I don't know how easy they are to get hold of, but
hopefully not too bad

Thanks, Jon! You've been very helpful (and really fast, too).

No problem

 

[Aleksander Oven]

I'm not sure which bit of XML you're referring to, to be honest.

My bad. I wasn't exactly familiar with assembly manifest and I wrongly
assumed it was all XML. I went and read up on this topic, and I know
better now.

If you look in the assembly manifest with ildasm, you want the
".assembly" entries. I don't know how easy they are to get hold of, but
hopefully not too bad

Actually I'm stuck. I'm going to start a new thread and ask a couple of
questions there.

 

[Jon Skeet [C# MVP]]

My bad. I wasn't exactly familiar with assembly manifest and I wrongly
assumed it was all XML. I went and read up on this topic, and I know
better now.


Actually I'm stuck. I'm going to start a new thread and ask a couple of
questions there.

The CLI spec has details about the assembly file format. I started a
project to load all the details quite a while ago - it's a bit of a
pain, but far from impossible. If you're only after the manifest, it
may not be too bad at all.

The spec is available from
http://www.ecma-international.org/publications/standards/Ecma-335.htm