Determine Assembly's .NET Framework Version

[Z D]

Hello,

If I have a .NET assembly, how do I determine what version of the .NET
framework it....
1) was compiled against
2) is supposed to use
3) is compatible with?

Is there a utility that will extract this info somehow?

thanks!
-ZD

[Mattias Sjögren]

1) was compiled against
2) is supposed to use
Once the assembly is loaded, you can use Assembly.ImageR untimeVersion
to check the runtime version ot was complied against (stored in the
metadata header).

Most assemblies will also reference the version of Mscorlib.dll that
was included in that runtime version, so you can also check the
assembly's references with a tool such as ILDASM.

3) is compatible with?

It would be hard to provide a tool that could prove an assembly to be
compatible with a certain version. Better to test it or ask the
vendor.

Mattias

--
Mattias Sjögren [MVP] mattias @ mvps.org
http://www.msjogren.net/dotnet/ | http://www.dotnetinterop.com
Please reply only to the newsgroup.

[Sven Groot]

Z D wrote:

3) is compatible with?

You should check for an App.Config file, see if it says anything. If not,
assume it's only compatible with the version it was compiled against.

--
Sven Groot

http://unforgiven.bloghorn.com

[Z D]

Hi Mattias,

Thanks for your reply.

I tried using ILDASM and looked at the manifest.

For an assembly known to be using .NET v1.1, I get this for mscorlib:
..assembly extern mscorlib
{
.publickeytoken = (B7 7A 5C 56 19 34 E0 89 ) //
..z\V.4..
.ver 1:0:5000:0
}

What is version 1:0:5000:0 ??

If I go to mscorlib.dll and look at its file version, it says: 1.1.4322.573

So why doesn't ILDASM show this too?

thanks
-ZD
"Mattias Sjögren" <ma************ ********@mvps.o rg> wrote in message
news:eX******** ******@tk2msftn gp13.phx.gbl...

1) was compiled against
2) is supposed to use

Once the assembly is loaded, you can use Assembly.ImageR untimeVersion
to check the runtime version ot was complied against (stored in the
metadata header).

Most assemblies will also reference the version of Mscorlib.dll that
was included in that runtime version, so you can also check the
assembly's references with a tool such as ILDASM.

3) is compatible with?

It would be hard to provide a tool that could prove an assembly to be
compatible with a certain version. Better to test it or ask the
vendor.

Mattias

--
Mattias Sjögren [MVP] mattias @ mvps.org
http://www.msjogren.net/dotnet/ | http://www.dotnetinterop.com
Please reply only to the newsgroup.

[Phill. W]

"Mattias Sjögren" <ma************ ********@mvps.o rg> wrote in message
news:eX******** ******@tk2msftn gp13.phx.gbl...
.. . .

3) is compatible with?

It would be hard to provide a tool that could prove an assembly to be
compatible with a certain version. Better to test it or ask the
vendor.

Mattias,
(Probably a silly question, but...)

Does it actually matter?

Are there any incompatibiliti es between Framework versions that we
should be aware of and try to avoid?

TIA,
Phill W.

[Sven Groot]

Z D wrote:

Hi Mattias,

Thanks for your reply.

I tried using ILDASM and looked at the manifest.

For an assembly known to be using .NET v1.1, I get this for mscorlib:
.assembly extern mscorlib
{
.publickeytoken = (B7 7A 5C 56 19 34 E0 89 )
// .z\V.4..
.ver 1:0:5000:0
}

What is version 1:0:5000:0 ??
It's the version of mscorlib.dll.
If I go to mscorlib.dll and look at its file version, it says:
1.1.4322.573
The file version you see in explorer is determined by an old-style Win32
VERSION_INFO resource. It is separate from the version defined in the
assembly manifest. The VB.NET and C# compilers by default emit a
VERSION_INFO resource that mirrors the assembly version info. It is
perfectly possible to add in a Win32 resource file yourself during
compilation time, in which case the compiler will not generate this info. So
the two version numbers need not match. And in the case of most of the
Framework Class Library files, they don't. Why MS chose to do this I don't
know.
So why doesn't ILDASM show this too?

ILDASM knows nothing about Win32 resources, and the .Net assembly loader
doesn't either. If you open mscorlib.dll in ILDASM, you'll see the assembly
version defined in its manifest is in fact 1:0:5000:0:

..assembly mscorlib
{
.ver 1:0:5000:0
}

--
Sven Groot

http://unforgiven.bloghorn.com

[Sven Groot]

Phill. W wrote:

"Mattias Sjögren" <ma************ ********@mvps.o rg> wrote in message
news:eX******** ******@tk2msftn gp13.phx.gbl...
. . .

3) is compatible with?
It would be hard to provide a tool that could prove an assembly to be
compatible with a certain version. Better to test it or ask the
vendor.

Mattias,
(Probably a silly question, but...)

Does it actually matter?

Yes.
Are there any incompatibiliti es between Framework versions that we
should be aware of and try to avoid?

The .Net Framework 1.1 should be mostly backward compatible with 1.0.
Forward compatibility only holds as long as you don't use anything that's
exclusive to the 1.1 version.

However, there are some changes I believe that can cause an application to
malfunction. I believe there are some in the Xml and Xslt classes, but I'm
not certain. I'm not certain an (exhaustive) list exists of any
incompatibiliti es, but you could always try googling it.

--
Sven Groot

http://unforgiven.bloghorn.com

[Z D]

Sven,

Thank's very much for your response. I get it now! :)

-ZD

"Sven Groot" <sv*******@gmx. net> wrote in message
news:%2******** **********@TK2M SFTNGP09.phx.gb l...

Z D wrote:

Hi Mattias,

Thanks for your reply.

I tried using ILDASM and looked at the manifest.

For an assembly known to be using .NET v1.1, I get this for mscorlib:
.assembly extern mscorlib
{
.publickeytoken = (B7 7A 5C 56 19 34 E0 89 )
// .z\V.4..
.ver 1:0:5000:0
}

What is version 1:0:5000:0 ??
It's the version of mscorlib.dll.

If I go to mscorlib.dll and look at its file version, it says:
1.1.4322.573

The file version you see in explorer is determined by an old-style Win32
VERSION_INFO resource. It is separate from the version defined in the
assembly manifest. The VB.NET and C# compilers by default emit a
VERSION_INFO resource that mirrors the assembly version info. It is
perfectly possible to add in a Win32 resource file yourself during
compilation time, in which case the compiler will not generate this info.

So the two version numbers need not match. And in the case of most of the
Framework Class Library files, they don't. Why MS chose to do this I don't
know.

So why doesn't ILDASM show this too?
ILDASM knows nothing about Win32 resources, and the .Net assembly loader
doesn't either. If you open mscorlib.dll in ILDASM, you'll see the

assembly version defined in its manifest is in fact 1:0:5000:0:

.assembly mscorlib
{
.ver 1:0:5000:0
}

--
Sven Groot

http://unforgiven.bloghorn.com

[Z D]

Phil,

Yes! It is important! (IMO)

And there are incompatibilite s! Alot of them! I was bitten pretty hard when
I migrated from v1.0 to v1.1. Luckily it wasn't anything major and it was
only in a test environment (I just had to stay up until all hours of the
morning fixing the issues since I hadn't planned for any!)

Here's a good list of all the changes that will break your application when
moving from v1.0 to v1.1:

http://www.gotdotnet.com/team/changeinfo/default.aspx
Hope it helps,
-ZD

"Phill. W" <P.A.Ward@o-p-e-n-.-a-c-.-u-k> wrote in message
news:c7******** **@yarrow.open. ac.uk...

"Mattias Sjögren" <ma************ ********@mvps.o rg> wrote in message
news:eX******** ******@tk2msftn gp13.phx.gbl...
. . .

3) is compatible with?

It would be hard to provide a tool that could prove an assembly to be
compatible with a certain version. Better to test it or ask the
vendor.

Mattias,
(Probably a silly question, but...)

Does it actually matter?

Are there any incompatibiliti es between Framework versions that we
should be aware of and try to avoid?

TIA,
Phill W.

[Z D]

Sven,

not certain. I'm not certain an (exhaustive) list exists of any
incompatibiliti es, but you could always try googling it.
Here's a pretty exhaustive (if not complete) list of changes that will break
an ap in both directions:
http://www.gotdotnet.com/team/changeinfo/default.aspx

-ZD

"Sven Groot" <sv*******@gmx. net> wrote in message
news:%2******** ********@TK2MSF TNGP09.phx.gbl. .. Phill. W wrote:

"Mattias Sjögren" <ma************ ********@mvps.o rg> wrote in message
news:eX******** ******@tk2msftn gp13.phx.gbl...
. . .

3) is compatible with?

It would be hard to provide a tool that could prove an assembly to be
compatible with a certain version. Better to test it or ask the
vendor.

Mattias,
(Probably a silly question, but...)

Does it actually matter?

Yes.

Are there any incompatibiliti es between Framework versions that we
should be aware of and try to avoid?

The .Net Framework 1.1 should be mostly backward compatible with 1.0.
Forward compatibility only holds as long as you don't use anything that's
exclusive to the 1.1 version.

However, there are some changes I believe that can cause an application to
malfunction. I believe there are some in the Xml and Xslt classes, but I'm
not certain. I'm not certain an (exhaustive) list exists of any
incompatibiliti es, but you could always try googling it.

--
Sven Groot

http://unforgiven.bloghorn.com