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.ImageRuntimeVersion
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.org> wrote in message
news:eX**************@tk2msftngp13.phx.gbl...

1) was compiled against
2) is supposed to use

Once the assembly is loaded, you can use Assembly.ImageRuntimeVersion
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.org> wrote in message
news:eX**************@tk2msftngp13.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 incompatibilities 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.org> wrote in message
news:eX**************@tk2msftngp13.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 incompatibilities 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
incompatibilities, 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******************@TK2MSFTNGP09.phx.gbl...

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 incompatibilites! 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.org> wrote in message
news:eX**************@tk2msftngp13.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 incompatibilities 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
incompatibilities, 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****************@TK2MSFTNGP09.phx.gbl... Phill. W wrote:

"Mattias Sjögren" <ma********************@mvps.org> wrote in message
news:eX**************@tk2msftngp13.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 incompatibilities 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
incompatibilities, but you could always try googling it.

--
Sven Groot

http://unforgiven.bloghorn.com

[Phill. W]

ZD,

Please, /please/, *please*

- Is there a comparable list (even a preliminary one) for the change
over from Framework 1.1 to 2.0?

TIA,
Phill W.

"Z D" <NO****@NOSPAM.com> wrote in message
news:O9**************@TK2MSFTNGP12.phx.gbl...

Phil,

Yes! It is important! (IMO)

And there are incompatibilites! 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.org> wrote in message
news:eX**************@tk2msftngp13.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 incompatibilities between Framework versions that we
should be aware of and try to avoid?

TIA,
Phill W.

[Z D]

Phill,

I saw one floating around not too long ago, cant seem to find it. If I come
across it I will post it.

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

ZD,

Please, /please/, *please*

- Is there a comparable list (even a preliminary one) for the change
over from Framework 1.1 to 2.0?

TIA,
Phill W.

"Z D" <NO****@NOSPAM.com> wrote in message
news:O9**************@TK2MSFTNGP12.phx.gbl...

Phil,

Yes! It is important! (IMO)

And there are incompatibilites! 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.org> wrote in message
news:eX**************@tk2msftngp13.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 incompatibilities between Framework versions that we
should be aware of and try to avoid?

TIA,
Phill W.