Process.Run and App.Config

[PMac]

I'm trying to execute a stand-alone console application from an aspx page
when a use clicks a button on that page. On the aspx page is the following
lines of pertinent code:

private void btnStartApp(object sender, System.EventArgs e)
{
Process procID;
string procName;
ProcessStartInfo psi = new ProcessStartInfo();


procName=System.Configuration.ConfigurationSettings.AppSettings["Application
Name"].ToString();
psi.FileName = procName;
psi.Arguments="-noOp";
psi.WorkingDirectory=procName.SubString(0,procName.LastIndexOf('\\');

procID = Process.Start(psi);

}

In the console application that starts, it starts in the correct directory,
starts as user ASPNET, and gets the command line parameters fine, but
there's a line of code in the console app where it tries to read a
configuration string from the App.Config file. And it always fails on the
read and subsequently the application will fail because it doesn't have this
string value. I checked and the permissions on the working directory are
full for user ASPNET.

Where would the shell be looking for the App.Config file if not in the
working directory?
Does anyone have any experience with this to tell me why the console app is
not looking for the App.Config file in the working directory when it's run
like this as user ASPNET? It works fine when run from the command line in
"normal" mode.

Any thoughts/comments/help would be greatly appreciated ... I would hate to
have to just hard code the config string, it seems like you should still be
able to use the App.Config file for this time of run.

 

[mikeb]

I'm trying to execute a stand-alone console application from an aspx page
when a use clicks a button on that page. On the aspx page is the following
lines of pertinent code:

private void btnStartApp(object sender, System.EventArgs e)
{
Process procID;
string procName;
ProcessStartInfo psi = new ProcessStartInfo();


procName=System.Configuration.ConfigurationSettings.AppSettings["Application
Name"].ToString();
psi.FileName = procName;
psi.Arguments="-noOp";
psi.WorkingDirectory=procName.SubString(0,procName.LastIndexOf('\\');

procID = Process.Start(psi);

}

In the console application that starts, it starts in the correct directory,
starts as user ASPNET, and gets the command line parameters fine, but
there's a line of code in the console app where it tries to read a
configuration string from the App.Config file. And it always fails on the
read and subsequently the application will fail because it doesn't have this
string value. I checked and the permissions on the working directory are
full for user ASPNET.

Just taking some stabs at this (no time to test this right now):

Try setting "psi.UseShellExecute = false". This will cause
Process.Start() to use CreateProcess() behind the scenes instead of
ShellExecuteEx().

Are you using ConfigurationSettings.AppSettings() to read the app.config
file or some other method? Is the item you're reading in a user-defined
configuration section, or is it in <appSettings>?

If you're using ConfigurationSettings, try reading the file using
System.IO classes (ie., as a stream) and see if you get an access denied
error (or some other error).

Where would the shell be looking for the App.Config file if not in the
working directory?

As far as I know, the 'working directory' should not be a factor - the
framework doesn't look in the 'working directory', it looks in the
application's base directory. The config file should be in the exact
same location as the .exe file (which looks to be the case in your
example, since your code sets the working directory to the .exe's
directory).

 

[PMac]

Mikeb - Thanks for your help ...

yes, I am using ConfigurationSettings.AppSettings() to read the
configuration string from app.config. I tried setting psi.UseShellExecute =
false and that didn't help. I also did my own reading from the app.config
file and was able to open and read it as ASPNET. Apparently there's
something in the ConfigurationSettings.AppSettings() that doesn't get set
when in the shell.

I'm trying to execute a stand-alone console application from an aspx page
when a use clicks a button on that page. On the aspx page is the following
lines of pertinent code:

private void btnStartApp(object sender, System.EventArgs e)
{
Process procID;
string procName;
ProcessStartInfo psi = new ProcessStartInfo();


procName=System.Configuration.ConfigurationSettings.AppSettings["Application
Name"].ToString();
psi.FileName = procName;
psi.Arguments="-noOp";
psi.WorkingDirectory=procName.SubString(0,procName.LastIndexOf('\\');

procID = Process.Start(psi);

}

In the console application that starts, it starts in the correct directory,
starts as user ASPNET, and gets the command line parameters fine, but
there's a line of code in the console app where it tries to read a
configuration string from the App.Config file. And it always fails on the
read and subsequently the application will fail because it doesn't have this
string value. I checked and the permissions on the working directory are
full for user ASPNET.

Just taking some stabs at this (no time to test this right now):

Try setting "psi.UseShellExecute = false". This will cause
Process.Start() to use CreateProcess() behind the scenes instead of
ShellExecuteEx().

Are you using ConfigurationSettings.AppSettings() to read the app.config
file or some other method? Is the item you're reading in a user-defined
configuration section, or is it in <appSettings>?

If you're using ConfigurationSettings, try reading the file using
System.IO classes (ie., as a stream) and see if you get an access denied
error (or some other error).

Where would the shell be looking for the App.Config file if not in the
working directory?

As far as I know, the 'working directory' should not be a factor - the
framework doesn't look in the 'working directory', it looks in the
application's base directory. The config file should be in the exact
same location as the .exe file (which looks to be the case in your
example, since your code sets the working directory to the .exe's
directory).

Does anyone have any experience with this to tell me why the console app is
not looking for the App.Config file in the working directory when it's run
like this as user ASPNET? It works fine when run from the command line in
"normal" mode.

Any thoughts/comments/help would be greatly appreciated ... I would hate to
have to just hard code the config string, it seems like you should still be
able to use the App.Config file for this time of run.

 

[mikeb]

Mikeb - Thanks for your help ...

yes, I am using ConfigurationSettings.AppSettings() to read the
configuration string from app.config. I tried setting psi.UseShellExecute =
false and that didn't help. I also did my own reading from the app.config
file and was able to open and read it as ASPNET. Apparently there's
something in the ConfigurationSettings.AppSettings() that doesn't get set
when in the shell.

I had a chance last night to run a simple test app like what you
describe. My console app had no problem getting settings via
ConfigurationSettings.AppSettings[] as long as the ASPNET user had
access rights to the directory (tested with Full Access rights).

My test was run on WinXP SP1 with .NET 1.1 installed.

Are you running on Win Server 2003 by any chance? If so, it might be
that MS has bumped up some security that causes this problem (another stab).

PMac wrote:

I'm trying to execute a stand-alone console application from an aspx

page

when a use clicks a button on that page. On the aspx page is the

following

lines of pertinent code:

private void btnStartApp(object sender, System.EventArgs e)
{
Process procID;
string procName;
ProcessStartInfo psi = new ProcessStartInfo();

procName=System.Configuration.ConfigurationSettings.AppSettings["Application

Name"].ToString();
psi.FileName = procName;
psi.Arguments="-noOp";

psi.WorkingDirectory=procName.SubString(0,procName.LastIndexOf('\\');

procID = Process.Start(psi);

}

In the console application that starts, it starts in the correct

directory,

starts as user ASPNET, and gets the command line parameters fine, but
there's a line of code in the console app where it tries to read a
configuration string from the App.Config file. And it always fails on

the

read and subsequently the application will fail because it doesn't have

this

string value. I checked and the permissions on the working directory

are

full for user ASPNET.

Just taking some stabs at this (no time to test this right now):

Try setting "psi.UseShellExecute = false". This will cause
Process.Start() to use CreateProcess() behind the scenes instead of
ShellExecuteEx().

Are you using ConfigurationSettings.AppSettings() to read the app.config
file or some other method? Is the item you're reading in a user-defined
configuration section, or is it in <appSettings>?

If you're using ConfigurationSettings, try reading the file using
System.IO classes (ie., as a stream) and see if you get an access denied
error (or some other error).

Where would the shell be looking for the App.Config file if not in the
working directory?

As far as I know, the 'working directory' should not be a factor - the
framework doesn't look in the 'working directory', it looks in the
application's base directory. The config file should be in the exact
same location as the .exe file (which looks to be the case in your
example, since your code sets the working directory to the .exe's
directory).

Does anyone have any experience with this to tell me why the console app

is

not looking for the App.Config file in the working directory when it's

run

like this as user ASPNET? It works fine when run from the command line

in

"normal" mode.

Any thoughts/comments/help would be greatly appreciated ... I would hate

to

have to just hard code the config string, it seems like you should still

be

able to use the App.Config file for this time of run.