IE handling of exe files

  • Thread starter Thread starter Mike Smith
  • Start date Start date
M

Mike Smith

If I put an old exe file on a web site and create a link to it then IE will
ask "open or save to disk?" when clicked. When I create an exe with VS.NET
it does not ask anything, it just tries to run it. Is there a bit I can set
somewhere that will tell IE to treat this like a "classic" exe? It make is
kind of hard to create setup.exe style applications using VS.NET with this
default behavior.

Mike
 
If the exe is in a directory that has execute permissions, then IE will not
ask what to do with the file, it will just execute it. Whether the exe is a
..NET exe or not won't make a difference.
 
If the exe is in a directory that has execute permissions, then IE will
not
ask what to do with the file, it will just execute it. Whether the exe is a
.NET exe or not won't make a difference.
Click to expand...

I tried placing a win32 version of the same exe on the server in the same
directory and IE treated it normally (open or save dialog). IE is
definitely treating the .NET exe file differently. When I access the url it
goes away for about a minute and finally put up a dialog that says:

IEExec.exe - Common Language Runtime Debugging Services
Application has generated an exception that could not be handled.
Process id=0xa8(168), Thread id=0x5e4(1508)
Click OK to terminate the application.
Click CANCEL to debug the application.

As a test I created a simple "Hello World" app called "Hello.exe" in VS.NET
and uploaded that to the server and tried to access it. The error log on
the server reports the following errors:

File does not exist: /public_html/404.shtml
File does not exist: /public_html/bin/Hello/Hello.EXE
File does not exist: /public_html/404.shtml
File does not exist: /public_html/bin/Hello.EXE
File does not exist: /public_html/404.shtml
File does not exist: /public_html/Hello/Hello.EXE
File does not exist: /public_html/404.shtml
File does not exist: /public_html/Hello.EXE
File does not exist: /public_html/404.shtml
File does not exist: /public_html/bin/Hello/Hello.DLL
File does not exist: /public_html/404.shtml
File does not exist: /public_html/bin/Hello.DLL
File does not exist: /public_html/404.shtml
File does not exist: /public_html/Hello/Hello.DLL
File does not exist: /public_html/404.shtml
File does not exist: /public_html/Hello.DLL
File does not exist: /public_html/404.shtml
File does not exist: /public_html/Hello.exe.config
File does not exist: /public_html/404.shtml
File does not exist: /public_html/Hello.exe.config
File does not exist: /public_html/404.shtml
File does not exist: /public_html/favicon.ico

This entire stream of errors was the result of one access attempt. It
appears IE is doing it's best to find something to execute. This is a
simple executable created using the VS wizard selecting "Windows
Application" as the project type. Should IE be trying to run applications
created as "Windows Applications" over the net? That doesn't seem right.

Mike
 
Mike,

I think the problem is that the .NET exe's you are uploading are
encountering errors that are preventing them from running. I don't think
this is an IE issue at all.

When I create a directory on my web server (and very importantly...give that
folder permission to run executables) and then put Notepad.exe (a win32 app)
in that folder, I can ask for the file and (without being prompted for
open/save), Notepad.exe will run. This is how exe's placed into folders
with execute permissions have always worked. If I place a .NET exe in the
folder, it will run as well.

I suspect 3 possibilities:

1. Your web server does not have the .NET framework installed or properly
installed and this is causing the CLR error messages you are getting when
you try to run those apps.

2. Your .NET exe's aren't written properly to be run remotely.

3. The directory you are placing the files in does not have the appropriate
execute permissions set.
 
Hey there, Mike.

You are absolutely right. Later versions of IE will attempt to run .NET
exe files after they are downloaded. These .NET executables are run by an IE
process called IEExec... .NET executables that are run in this way via IE
are executed with a VERY limited permission set [by default]. That exception
is being thrown because your .NET exe is very likely trying to do something
that it isn't allowed to do such as write to a file or to the registry or
perhaps open a network connection. The default permission set allows your
EXE to do very little.

All of those attempts to open other files are being generated by the
..NET runtime on the client machine. Whenever you attempt to execute a .NET
exe, even on your local machine, the .NET runtime looks for numerous other
files [.config files, culture specific DLLs, resource files, etc.] It all
happens so quickly on your local machine that you never notice it... but
over an HTTP connection when the .NET exe is remote, this can become a real
pain. There are ways around this though. For now, there are two approaches
that you might want to take:

1) If this EXE of yours is really a setup file, package it as an MSI
file instead of an EXE. That way, IE will know to just download it instead
of executing it.

2) You can instruct your users to right-click the EXE link instead of
left-clicking it. This will bring up a context menu in IE at which point the
user can click "save target as..." to save the EXE to his machine without
executing it.
 
I'm sorry, I should have made this more clear up front. The application is
not made to be run remotely, it is an application similar to a single file
setup.exe executable which is downloaded and run locally. It works fine
locally. The server is not IIS but that's part of my point. I can put
something like the setup.exe which comprises the .NET redistributable on any
web site, IIS with or without execute permissions, UNIX/Linux servers,
whatever, and I can be guaranteed the user can click on that link and be
presented with the "open or save to disk" dialog. That is what I'm looking
for. A setup.exe kind of application which the user does not have to unzip
first, that can be archived somewhere, put on a web server and downloaded,
and something the user can run by double-clicking on it without installing
something first.

If I have to wrap this in a win32 executable then so be it but I find it
hard to believe. Fast forward to some day in the future when the team at
Microsoft who builds the install scripts to create the .NET redistributable
now have to build the single giant setup.exe executable using VS.NET. Are
they going to throw their hands up and say "sorry, that's just the way it
is. People using non-Microsoft browser will have no problems but IE users
will crash if the server is IIS mis-configured with execute permissions or
if downloaded from a non-IIS server". I'm thinking there must be a way to
make an executable in VS.NET that tells IE "don't even think about trying to
run this". Or not(?)

Mike
 
Thanks for your reply. How feasible would it be to set it up to actually
run over the net with zero permissions but in a sort of demo mode (assuming
that would make sense for this application and in this case it does). Maybe
a dialog would inform the user that it is about to run in demo mode but if
they want to download it they should right-click the download link and
choose "Save Target As..." like you suggested. Then non-IE browsers would
just download it but IE users would get a chance to preview the application
they are about to download, they just can't save to disk, etc. Then the
same executable running locally would detect that fact and "Save as..."
would become enabled as would other permission-based features. Can you
point to a place where issues involving running applications with no
permission over the web is discussed? I'm trying to get in step with how
..NET does things but maybe I'm just too thick headed or something :-)

Mike
 
Thanks for your reply. How feasible would it be to set it up to actually
run over the net with zero permissions but in a sort of demo mode (assuming
that would make sense for this application and in this case it does).
Click to expand...

I've been where you are and have posted the very same questions that
you're posting now and can tell you that the path you're on leads to a dead
end. Here's the basic scoop on this:

Around the time that .NET was released, Microsoft started hyping
something called zero-touch deployment. The idea is that you place a .NET
executable on a web server (be it IIS, Apache, or whatever). Internet
Explorer would then download the EXE. At some point IE would look at the
executable and determine if it were a .NET exe. If so, it would try to run
it, automatically downloading all of your custom assemblies on which your
EXE depends. The idea was cool, but it had problems:

First of all, it was slow. Not only would your app hang while the .NET
runtime tried to download all of your other assemblies, but as posted in the
last message, .NET likes to "probe" for culture specific assemblies. Aside
from the slowness, with .NET 1.0, the downloaded assembly didn't have access
to do much. Pretty much anything your app tried to do, even doing seemingly
innocuous things like opening a new form, would lead to some kind of warning
that the user would have to read. Other operations would just throw
exceptions. If that weren't enough, your app was loaded into the IEExec
process which means that if you're application made use of certain legacy
COM components (i.e. the web browser control), you'd end up with all kinds
of weird threading exceptions if you didn't configure everything just right.

Around the time .NET 1.1 came out, Microsoft was getting some bad press
for virus vulnerabilities. So, to score some press points, they announced
that they were making .NET 1.1 "more secure"... part of this initiative
included tightening the security in such a way that .NET exes located on a
web server wouldn't even *execute.* So much for zero-touch deployment over
the Internet.

With the next release of .NET, Microsoft will reverse course again,
allowing these remote EXEs to execute and with more permissions than 1.0.
Exactly what those permissions are I'm not sure. I don't think it's been
announced. But as you can see, the damage is already done. You as the
developer have no idea whether your users will be using 1.0, 1.1, or this
new Whidbey version of .NET so this idea of putting an EXE on a web server
and have users run it just a no good. This idea is only practical in certain
types of Intranet scenarios... and from what I can tell, there's no way to
force the IE user to get a the "Save As.." dialog without forcing him
through the context menu.

If you absolutely refuse to use an MSI file for deployment, you're going
to have to find a clever way to get the user to run your executable with
FullTrust. One thing I've done in the past is put some instructions on the
site telling users to right-click the exe link, save it to their harddisk,
and run it. That way the EXE runs with full permissions. As part of the
startup code, you can modify the security settings on the user's computer so
that it grants FullTrust to all other EXEs originating from your domain. I
don't really recommend this though. Then you're assuming that the user has
administrative access to his own machine, etc. There also might be a
backdoor through ActiveX [browser-based unmanaged code] that would allow you
to modify the user's security settings, but I haven't tried this.

I think for now you're stuck using an MSI file. :(
 
Wow! Thanks for that long, thoughtful reply. That pretty much sums it up.
BTW, I looked at your web site and I'm in a related bussines. I might be in
contact with you later when this project is further along. Strange
coicidence.

Thanks again, you saved me a ton of wasted time!

Mike
 
Back
Top