Mayayana said:
Curiosity got the better of me and I ended up writing
a VBScript to test for .Net. For anyone who's curious,
it's here:
http://www.jsware.net/jsware/test/dotnetv.zip
Drop any file onto the script and if it's .Net the version
required will be reported. I've tested a number of files
and this script seems to be dependable. It parses the
PE file header directly, thus not requiring .Net or any
other software. (As is typical, the script wasn't so hard
to write, but finding accurate information was difficult.)
I'll package it up into an HTA, so that people who want
to scan their systems can just enter a path and have all
EXEs, DLLs on that path checked.
I altered my script, to call "ildasm.exe", an official MS tool
from one of their SDKs.
After my test run, the ildasm.exe threw five runtime errors
(versus the twenty using CLRver.exe off the 'net). So
the damn script wouldn't run, without dismissing error
dialogs on the screen. I'm going to work on that in a bit.
Using CLRver, my scan got
"V1.0.3705 occurred 13 times
V2.0.50727 occurred 156 times
-2 occurred 21 times"
Using ildasm, the latest scan got
'v4.0.30319' Version String occurred 2 times
'v2.0.50727' Version String occurred 215 times
'v1.0.3705' Version String occurred 13 times
so it would appear the CLRver approach of loading the assembly,
will also fail when a program has a version of dotnet, which
is not installed on the machine. Apparently I have two programs
which call for .net 4.0 and I don't have that version installed.
ildasm is capable of reading that out, without throwing a wobbly.
It's also a bit puzzling, how the MS tools got 215 of the .net 2.0
executables, while the CLRver got 156. That might correspond to
x64 executables that would not load in CLRver (on my x32 OS).
In all cases, the ildasm program detected
Metadata Header Storage Signature: 0x424a5342
which is hex for "BSJB" (only backwards due to endianness).
So that appears to be a pretty consistent theme. The gnuwin32
"file" program, logged a couple things it identified as dotnet,
and there was no BSJB string present. The ildasm never seemed
to log anything that didn't have that present.
This is the ildasm output blob which I used for logging the strings.
There didn't seem to be variation in this, and only the Version
String line is the one that changes from instance to instance.
// Metadata Header
// Storage Signature:
// 0x424a5342 Signature
// 0x0001 Major Version
// 0x0001 Minor Version
// 0x00000000 Extra Data Offset
// 0x0000000c Version String Length
// 'v2.0.50727' Version String
// Storage Header:
The "Version String Length" was still 0c or decimal 12, even for
the short string v1.0.3705. It almost seems like a "max length" of
some sort.
Anyway, good fun for a "something to do" kinda project.
Paul