.Net executable shows fine for some, as DOS .exe for others

[Guest]

I've run into a rather strange situation, and can't seem to find any details
on why this would even be happening, so here goes:

I've created an app to force users to update their pcAnywhere passwords.
This is a VB.Net project compiled against .Net 1.1. This executable is
placed on a terminal server in \Documents and Settings\All Users\Desktop and
up until recently worked just fine, with about 10 people utilizing it on a
recurring basis.

Recently, 2 new employees joined our team, and need access to this as well,
but we're encountering some strange things. First, when they try and run the
..exe, they get a boilerplate windows error (not the JIT type) stating they
don't have rights to access something (going through code now, just to make
sure that .exe is touching only what it needs) and the application will be
terminated. I've verified myself that both for this machine, and the domain
in general, these 2 users have the EXACT same rights as the people already
using this app, but still we get that message.

So I started looking to see if perhaps they were somehow pointing to a
different copy of the .exe, and I did so by right clicking on the .exe and
selecting properties. When looking at the properties, there's a stark
contrast between what these 2 new users see, and what everyone else sees.
For the new users, the properties tabs are those of a DOS executable. For
anyone else, they see the normal 3 or 4 tabs one would expect from a .Net
executable!!

As a last ditch before searching/posting here, I rebuilt the .exe from
source and placed the new copy in the same location as the original, with no
change in the results. Works fine for everyone but these 2 users, with the
above mentioned quirks still intact.

Thanks in advance for taking the time to read all this,

Eric

 

[Rob R. Ainscough]

I've noticed the EXACT same problem with some of my .NET exe, the appear to
registry as DOS apps rather than .NET windows apps, but not in all causes,
seems to vary from PC to PC.

If you find a solution, please let me know.

Just curious, did you try to install and then uninstall .NET framework? How
many versions of .NET framework are loaded on the client PC?

Rob.

 

[Guest]

Ok, after some digging and further testing, I think I've figured this out.

If any of the below is incorrect, someone please feel free to correct me.

Apparently, to run an executable, you need write access to the directory
you're launching the executable from. In this instance, the .exe itself
lived in C:\Documents and Settings\All Users\Desktop. The 2 new users, while
they need access to this app via the Terminal Server, are not IT folks, and
so were not given write access to All Users subtree.

Once I moved the .exe to a new folder where the users DID have write access,
they were able to see and run it fine. So to restore things to the way they
were, I deleted the .exe in the All Users\Desktop folder, and created a
shortcut to the new copy in another folder where the users had write access.
Double-clicking the shortcut, now does everything one would expect, as well
as fixing the properties problem.

My theory is this, you need write access to a folder from which you want to
launch an executable, as well as for reading the PE header (what explorer
does to display the file icons) to display the appropriate properties and
icon. I can neither confirm nor deny this, only state that in my case, once
the conditions listed above were met (.exe launched from or viewed in a
folder that the user has write access to) everything returned to normal.

HTH,

Eric

 

[Guest]

Almost forgot to answer your questions Rob!!

I didn't try the install/uninstall, but having found a fix, I'm not sure
that would have any effect. As I said in my intial response, although this
works, I'm still not sure that I have the scenario nailed down, or just got
lucky.

As for the versions, both 1.1 and 2.0 are installed on this particular
server and are up-to-date with any patches from MS.

Let me know if this works for you, and if not, we can keep plugging and
maybe find a more definitive answer to this problem.

Eric

 

[Rob R. Ainscough]

No, your fix sounds accurate and makes sense, however I don't understand why
a .NET application would require write access to the dir? I have seen the
same issue when I deployed web apps (.NET based) -- even precompiled ones.
Since I don't like to provide public write access to anything I located the
..NET account (don't recall the account name right now) and gave that account
write access to the dir.

Yeah, don't waste your time on re-installs of .NET framework (I use that as
my last resort).

Rob.

 

[Guest]

I thought the same thing, but I'm testing a similar scenario now using a
small VB6 app, to rule out .Net as a factor here.

I'll be sure and let you know what I find.

Eric