Problem shelling to local console app from production server

[Stephen Miller]

On my development machine (where the group 'Everyone' has full access
to every directory), the following code successfully shells to a
console application:

Dim objShell As System.Diagnostics.Process = New
System.Diagnostics.Process()
With objShell
.StartInfo.FileName = "C:\Project\MyApp\MyApp.exe"
.StartInfo.Arguments = " 123"
.StartInfo.WorkingDirectory = "C:\Project\MyApp\"
.StartInfo.CreateNoWindow = True
.StartInfo.UseShellExecute = False
.Start()
End With

When I transfer my ASP.Net project to the production server, the
console application starts (ie 'MyApp.exe' appears in Windows Task
Manager), but then hangs.

Using System.Security.Principal.WindowsIdentity.GetCurrent().Name() I
have checked that the ASP.Net application is running under the context
of MACHINE\ASPNET and I have given this user full access to the
directory "C:\Project\MyApp\" and execute permissions to
"C:\Project\MyApp\MyApp.exe".

I don't think the console app is throwing an error as the program with
arguments runs fine from the command prompt and the development
server. I have experimented with a simple console application that
simply writes to a log file in the working directory, however this
fails to executes, suggesting that the program has insufficient
read/write access to the working directory.

I suspect that the System.Diagnostics.Process requires read/write
access to a directory or process other then those given in the
FileName and WorkingDirectory properties. Can anyone help?

Both the Development and Production servers are running Win2K
5.00.2195 & .Net 1.1

Thanks,

Stephen

 

[Stephen Miller]

On my development machine (where the group 'Everyone' has full access

to every directory), the following code successfully shells to a
console application:

Dim objShell As System.Diagnostics.Process = New
System.Diagnostics.Process()
With objShell
.StartInfo.FileName = "C:\Project\MyApp\MyApp.exe"
.StartInfo.Arguments = " 123"
.StartInfo.WorkingDirectory = "C:\Project\MyApp\"
.StartInfo.CreateNoWindow = True
.StartInfo.UseShellExecute = False
.Start()
End With

When I transfer my ASP.Net project to the production server, the
console application starts (ie 'MyApp.exe' appears in Windows Task
Manager), but then hangs.

Using System.Security.Principal.WindowsIdentity.GetCurrent().Name() I
have checked that the ASP.Net application is running under the context
of MACHINE\ASPNET and I have given this user full access to the
directory "C:\Project\MyApp\" and execute permissions to
"C:\Project\MyApp\MyApp.exe".

I don't think the console app is throwing an error as the program with
arguments runs fine from the command prompt and the development
server. I have experimented with a simple console application that
simply writes to a log file in the working directory, however this
fails to executes, suggesting that the program has insufficient
read/write access to the working directory.

I suspect that the System.Diagnostics.Process requires read/write
access to a directory or process other then those given in the
FileName and WorkingDirectory properties. Can anyone help?

Both the Development and Production servers are running Win2K
5.00.2195 & .Net 1.1

Thanks,

Stephen

.... I'll answer my own question, because it might help other users.

When objShell.StartInfo.UseShellExecute was set to 'True', the server
console was displaying the error message "The application failed to
initialise properly (0xc0000022)", with each attempt at shelling
MyApp.exe from ASP.Net (I was using terminal services, so I wasn't
seeing the message). Searching for this error led me think that
MyApp.exe was attempting to call a DLL, for which the user
MACHINE\ASPNET did not have any execute privileges.

MyApp.exe was written in VB6 and using Visual Studio 6's 'Depends.exe'
(find it at '..\Microsoft Visual Studio\Common\Tools\') on the
production server I was able to determine that MACHINE\ASPNET did not
have execute privileges on the 'msvbvm60.dll'. I added permissions and
the ASP.Net was able to shell my program.

Stephen