How to determine programs that require .net on XP?

[aeroloose]

I have all versions of .net on my machine. Reading other
posts, it occurred to me to consider trimming or removing
..net. But, I may have existing programs that require it,
and I may not know they do Any suggestions on ways to
audit my PC for programs that use .net (and which version of
..net)?

Aero

 

[Jo-Anne]

I have all versions of .net on my machine. Reading other posts, it
occurred to me to consider trimming or removing .net. But, I may have
existing programs that require it, and I may not know they do Any
suggestions on ways to audit my PC for programs that use .net (and which
version of .net)?

Aero

I don't know the answer, Aero, but I can tell you that after having lots of
trouble with .NET Framework updates, I uninstalled it--and found out that my
Dell computer wouldn't start properly without it. Every time I booted the
computer, I got an error message about SecureUpgrade that I had to click out
of. I also could not use Filehippo, a program that checks for updates to
programs installed on the computer. I finally broke down, cleaned out all
the old .NET Framework files (with lots of help from Microsoft Support), and
reinstalled the latest version and all its updates.

Jo-Anne

 

[Mayayana]

| Any suggestions on ways to
| audit my PC for programs that use .net (and which version of
| .net)?
|
There may not be any simple way to check,
other than trying them or posting a list here to
get feedback from others.

Since the runtime is so big, most software authors
won't be anxious to tell you that their software requires
..Net. A couple of times I've downloaded something that
tried to go online and install the .Net Framework without
even asking permission. Microsoft encourages that
behavior. (There was a time when all software downloads
would list the download size and the requirements. In many
cases now they no longer list either.)

There could be issues with some printers or other
hardware. If you have something like that requiring .Net
you might have difficulty removing it, though you may
still only need v. 2. Other than that I don't know of
many Windows programs that use .Net. The two that
Jo-anne mentioned seem to be some kind of DRM
http://www.wave.com/products/esc.asp
and a shareware program that looks for software updates.
Generally, small shareware is the most likely to require
..Net. The code is relatively slow; the dependencies are
gigantic; and since it's not actually compiled software, .Net
programs can be decompiled. Those are all qualities that
commercial software authors try to avoid.

The basic library that all .Net programs need, as far as
I know, is mscoree.dll. If you try to run .Net software with
no .Net you probably won't see an informative error message.
You'll just get a message that "mscoree.dll is missing". That's
the giveaway. You might be able to test by temporarily
renaming mscoree.dll and then running your software, but if
you have System File Protection enabled it might not let you
do that.

There's a very useful program named depends.exe that you
can use to find out what libraries a program needs:

http://en.wikipedia.org/wiki/Dependency_Walker

The website for download seems to be currently down. I
have several SDKs and found that depends.exe is included
*at least* in the Win2003 Server DDK. So you should be able
to get depends.exe or its equivalent one way or another.

Depends lists libraries and which functions are being used
from those libraries. It doesn't always manage to find all
dependencies for all EXEs, but it should something like
mscoree.dll.

Java is a similar problem to .Net. Most software doesn't
need it, but occasionally some website functionality might
need it. OpenOffice needs Java for something or other...
I don't know what.... but I was able to find a Java-free
OO installer that's worked fine for me.

 

[Bert]

Since the runtime is so big, most software authors
won't be anxious to tell you that their software requires
.Net.

They'd be foolish not to tell you, since their product is worthless
without it.

 

[Mayayana]

| > Since the runtime is so big, most software authors
| > won't be anxious to tell you that their software requires
| > .Net.
|
| They'd be foolish not to tell you, since their product is worthless
| without it.
|

Did you read down in my post? It's not unusual
for the installer to sneak online and download the
Framework with nothing more than a brief message
flying by during the install process. So you end up
saddled with 1/2 GB for what you thought was a
small trinket program, but most people "won't know
what hit them", so that approach is actually a
clever strategy. If they were honest they'd show a
message saying, "This software will take up as much
room as 1/2 of your total operating system. Do you
still want to proceed?" But that wouldn't win many
converts.

 

[Paul]

I have all versions of .net on my machine. Reading other posts, it
occurred to me to consider trimming or removing .net. But, I may have
existing programs that require it, and I may not know they do Any
suggestions on ways to audit my PC for programs that use .net (and which
version of .net)?

Aero

Best answer so far, was this.

http://www.devfish.net/articles/clrver/article_CLRVer.htm

http://www.devfish.net/downloads.aspx

http://www.devfish.net/.\downloads\files\clrver.zip

Scans clean (not a guarantee it isn't malware)...

http://www.virustotal.com/file-scan...0241fab6fea39353c77f097c7acf258dce-1326052342

*******

Now, if I unzip the file, and pull out CLRver\bin\Release\CLRver.exe
that seems to be all that is needed. I can then, test the program on itself
(as the program also requires dotnet to work).

In a command prompt window, while cd'ed to the directory holding that
single extracted file, I tried

clrver clrver.exe

and the answer was

clrver.exe=v2.0.50727

I would then consult a table of CLR version versus dotnet
release, to figure out what version of dotnet would have
to stay in place. In my case, it's probably .net 2.0 , as
that's all I'm likely to have installed.

*******

On the dotnet side of things, Stebners blog has a few tools.

https://skydrive.live.com/?cid=27e6a35d1a492af7&id=27E6A35D1A492AF7!376

It's possibly "netfx_setupverifier_new" that includes a tool
with dialog, which will list the dotnet layers installed,
and allow them to be tested. That's to allow a user to verify
their version of dotnet installation, is working. It might
also be used to point out, what library versions remain installed.

Once you've removed all your dotnet, I presume a tool like
that would throw a wobbly I would expect most tools
used for dotnet, would have their own dotnet dependency
(which is why I did my "clrver clrver.exe" test case, to
demonstrate that).

Have fun (playing whack-a-mole)

Paul

 

[000-111-000]

I have all versions of .net on my machine. Reading other
posts, it occurred to me to consider trimming or removing
.net. But, I may have existing programs that require it,
and I may not know they do Any suggestions on ways to
audit my PC for programs that use .net (and which version of
.net)?

Aero

If not broking,
do not Fix it...

For old software needs Old .NET,
like the old Games software you have,
New Software like XP Sp3 and up,
need new .NET to run!

 

[Mayayana]

|
| For old software needs Old .NET,
| like the old Games software you have,
| New Software like XP Sp3 and up,
| need new .NET to run!
|

It doesn't work that way. There is no .Net needed
by XP SP3. .Net has no direct connection to Windows.
(Though some framework comes pre-installed on Vista/7,
so it's possible that Microsoft has installed a .Net applet
or two on Vista/7.)

When .Net came out there was v. 1 and 1.1.
..Net v. 2, which is already 10 years old now, eventually
became the standard version because later versions
are very big and therefore difficult to distribute. So a lot
of .Net software written now is .Net v. 2. Some is v. 3 or
later.

 

[Ken Blake, MVP]

If not broking,
do not Fix it...

For old software needs Old .NET,
like the old Games software you have,
New Software like XP Sp3 and up,
need new .NET to run!

Sorry, but that is not at all correct. Neither Windows XP (SP3 or not)
nor any other version of Windows needs .net.

The .net framework (note its full correct name) is needed by some
*application* programs (again, not operating systems). And what
version of the .net framework the application program needs depends on
what version of .net it was written with.

 

[Paul]

Best answer so far, was this.

http://www.devfish.net/articles/clrver/article_CLRVer.htm

http://www.devfish.net/downloads.aspx

http://www.devfish.net/.\downloads\files\clrver.zip

Scans clean (not a guarantee it isn't malware)...

http://www.virustotal.com/file-scan...0241fab6fea39353c77f097c7acf258dce-1326052342

I tried writing some scripts, to scan my hard drive to see what versions
of dotnet were used by the programs on there.

Occasionally, I was seeing an error like this from CLRver.exe .

R6034 "attempt to load the C runtime library incorrectly"
http://img853.imageshack.us/img853/1742/dotnetruntimeerror.gif

So in fact I couldn't make the script run to completion, without
having to dismiss about 21 of those dialog boxes.

It seems to involve 64 bit executables which happen to be sitting
in install folders here and there. Almost like, attempting to
analyze a 64 bit executable on a 32 bit OS, is some how compromised.

The CLR (common language runtime) version printed out by CLRver,
can be decoded with this table.

http://en.wikipedia.org/wiki/List_of_.NET_Framework_versions

This is what my script recorded.

"V1.0.3705 occurred 13 times
V2.0.50727 occurred 156 times
-2 occurred 21 times"

and the -2 corresponds to each instance of error R6034.

So it looks like my old Windows Media Encoder package depends on
dotnet version 1.0. While most of the other junk on my hard drive,
is looking for dotnet version 2.0 . Some of the files captured,
are part of the dotnet installation itself, which means you have to
go through the list of detected files, to find files actually
in the Program Files folder structure.

Paul

 

[Char Jackson]

I tried writing some scripts, to scan my hard drive to see what versions
of dotnet were used by the programs on there.

Occasionally, I was seeing an error like this from CLRver.exe .

R6034 "attempt to load the C runtime library incorrectly"
http://img853.imageshack.us/img853/1742/dotnetruntimeerror.gif

So in fact I couldn't make the script run to completion, without
having to dismiss about 21 of those dialog boxes.

It seems to involve 64 bit executables which happen to be sitting
in install folders here and there. Almost like, attempting to
analyze a 64 bit executable on a 32 bit OS, is some how compromised.

The CLR (common language runtime) version printed out by CLRver,
can be decoded with this table.

http://en.wikipedia.org/wiki/List_of_.NET_Framework_versions

This is what my script recorded.

"V1.0.3705 occurred 13 times
V2.0.50727 occurred 156 times
-2 occurred 21 times"

and the -2 corresponds to each instance of error R6034.

So it looks like my old Windows Media Encoder package depends on
dotnet version 1.0. While most of the other junk on my hard drive,
is looking for dotnet version 2.0 . Some of the files captured,
are part of the dotnet installation itself, which means you have to
go through the list of detected files, to find files actually
in the Program Files folder structure.

Regarding your last point, couldn't you just point the script at the
Program Files tree and have it walk through that tree to completion?

 

[Paul]

Regarding your last point, couldn't you just point the script at the
Program Files tree and have it walk through that tree to completion?

I could, but as a first effort, I wanted to scan everything to
check for "surprises" or things I hadn't thought about. Executable
code is thrown all over the place. For example, my 10GB C:\Xilinx
folder, is not in Program Files as it should be. When a project
gets too big for its own good, it tends to end up in its own
little world.

Paul

 

[aeroloose]

I tried writing some scripts, to scan my hard drive to see
what versions
of dotnet were used by the programs on there.

Occasionally, I was seeing an error like this from CLRver.exe .

R6034 "attempt to load the C runtime library incorrectly"
http://img853.imageshack.us/img853/1742/dotnetruntimeerror.gif

So in fact I couldn't make the script run to completion,
without
having to dismiss about 21 of those dialog boxes.

It seems to involve 64 bit executables which happen to be
sitting
in install folders here and there. Almost like, attempting to
analyze a 64 bit executable on a 32 bit OS, is some how
compromised.

The CLR (common language runtime) version printed out by
CLRver,
can be decoded with this table.

http://en.wikipedia.org/wiki/List_of_.NET_Framework_versions

This is what my script recorded.

"V1.0.3705 occurred 13 times
V2.0.50727 occurred 156 times
-2 occurred 21 times"

and the -2 corresponds to each instance of error R6034.

So it looks like my old Windows Media Encoder package
depends on
dotnet version 1.0. While most of the other junk on my hard
drive,
is looking for dotnet version 2.0 . Some of the files captured,
are part of the dotnet installation itself, which means you
have to
go through the list of detected files, to find files actually
in the Program Files folder structure.

Paul

I appreciate the info, but yikes! Quite a bit more
complicated than I was hoping for I did hear somewhere
that Process Explorer might also be a way to get the
answers, but I think it still boils down to checking each
program individually. Not sure the effort is worth the
cost, at this point. Perhaps another poster has a simpler
way ...

 

[Char Jackson]

I could, but as a first effort, I wanted to scan everything to
check for "surprises" or things I hadn't thought about. Executable
code is thrown all over the place. For example, my 10GB C:\Xilinx
folder, is not in Program Files as it should be. When a project
gets too big for its own good, it tends to end up in its own
little world.

Understood, thanks. I've been known to do the same thing.

 

[Tester]

There is no other way to determine this except to rename the folder that
contains .Net files and then trying to run each and every program one by
one. If the program does not find the .Net files, it will complain and
you will know that program requires .Net files.

Now if you have 1,000 programs then just take one week off from work and
try this method during that week.

Good luck.

 

[Paul]

I appreciate the info, but yikes! Quite a bit more complicated than I
was hoping for I did hear somewhere that Process Explorer might also
be a way to get the answers, but I think it still boils down to checking
each program individually. Not sure the effort is worth the cost, at
this point. Perhaps another poster has a simpler way ...

One reason I didn't go into the details, is the method isn't refined
enough for duplication.

After looking at the results of my little experiment, it still looks
like a custom bit of code would do the job best. A script isn't going
to do it. For one thing, the method I was using was too slow - it took
about 1 hour 50 minutes, to scan C: There's got to be a better way...

Paul

 

[Paul]

There is no other way to determine this except to rename the folder that
contains .Net files and then trying to run each and every program one by
one. If the program does not find the .Net files, it will complain and
you will know that program requires .Net files.

Now if you have 1,000 programs then just take one week off from work and
try this method during that week.

Good luck.

Actually, some .net programs do not complain intelligently.

All you see is a complaint about "mscoree.dll". And from that,
using your all-powerful intuition, you're supposed to figure out
what is missing.

http://support.microsoft.com/kb/316091

Paul

 

[Mayayana]

| One reason I didn't go into the details, is the method isn't refined
| enough for duplication.
|

It looks like the gist of what you want is this:

http://it.toolbox.com/blogs/coding-dotnet/net-portable-executable-file-11836

http://www.simple-talk.com/community/blogs/simonc/archive/2011/03/16/100839.aspx


they describe a CLR header near the start of a PE file.
If one had the details of that header it would be simple
to write something like a VBScript that goes through
a list of installed software (the Registry App Paths keys)
and reads the beginning of each executable to see
whether it's .Net, and what version it is. In a few minutes
of searching, though. I didn't come across a clear mapping
of the header and its location in a PE file.

 

[Paul]

| One reason I didn't go into the details, is the method isn't refined
| enough for duplication.
|

It looks like the gist of what you want is this:

http://it.toolbox.com/blogs/coding-dotnet/net-portable-executable-file-11836

http://www.simple-talk.com/community/blogs/simonc/archive/2011/03/16/100839.aspx


they describe a CLR header near the start of a PE file.
If one had the details of that header it would be simple
to write something like a VBScript that goes through
a list of installed software (the Registry App Paths keys)
and reads the beginning of each executable to see
whether it's .Net, and what version it is. In a few minutes
of searching, though. I didn't come across a clear mapping
of the header and its location in a PE file.

I've seen enough variations, while scanning my C: drive, to
not attempt to write my own C: code. I'm not finding the
magic string value "BSJB" in all the files I've looked at.
And the offset of that string, varies a bit. It's not static.
The format seems variable, calling for parsing according
to some recipe. On some files this program identifies as
..net, I'm not finding BSJB anywhere in there. This program
uses hints inside a file, rather than the file extension,
to identify things. It's a port from Unix/Linux world.

http://gnuwin32.sourceforge.net/packages/file.htm

The thing is, I'm not confident if I used a hacker approach
to this, my coverage would extend to 100% (i.e. using a hex
editor and making my own recipe). I'd likely get it wrong,
unless I use the docs for parsing PE and Net assemblies.
I may not have enough code samples here, to get all the
variations right.

As far as distributing solutions to others, giving out binaries
isn't a very good idea (the trust problem). Giving out source,
then nobody knows how to compile it. (I use DJGPP for some
things here. Don't have any Microsoft tools installed.) If I use
a scripting language, then it's possible for others to follow
along, using the same downloads I'm using. But so far, my
results aren't good enough.

I have a copy of "ildasm" here, but I haven't been able to get
"dumpbin" working. If I do any more work on it, I'll be running
the questionable files through ildasm for a look.

Paul

 

[000-111-000]

Come again?

In good working older

Eng 099 still recommended, Hot Text.

You maybe right


It's people like Ken Blake, Microsoft MVP,
Why Microsoft do not do NNTP,
News Groups no more,