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(obj ect sender, System.EventArg s e)
{
Process procID;
string procName;
ProcessStartInf o psi = new ProcessStartInf o();
procName=System .Configuration. ConfigurationSe ttings.AppSetti ngs["Applicatio n
Name"].ToString();
psi.FileName = procName;
psi.Arguments="-noOp";
psi.WorkingDire ctory=procName. SubString(0,pro cName.LastIndex Of('\\');

procID = Process.Start(p si);

}

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]

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(obj ect sender, System.EventArg s e)
{
Process procID;
string procName;
ProcessStartInf o psi = new ProcessStartInf o();
procName=System .Configuration. ConfigurationSe ttings.AppSetti ngs["Applicatio n
Name"].ToString();
psi.FileName = procName;
psi.Arguments="-noOp";
psi.WorkingDire ctory=procName. SubString(0,pro cName.LastIndex Of('\\');

procID = Process.Start(p si);

}

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.UseShellEx ecute = false". This will cause
Process.Start() to use CreateProcess() behind the scenes instead of
ShellExecuteEx( ).

Are you using ConfigurationSe ttings.AppSetti ngs() 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 ConfigurationSe ttings, 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

[PMac]

Mikeb - Thanks for your help ...

yes, I am using ConfigurationSe ttings.AppSetti ngs() to read the
configuration string from app.config. I tried setting psi.UseShellExe cute =
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 ConfigurationSe ttings.AppSetti ngs() that doesn't get set
when in the shell.

"mikeb" <ma************ @nospam.mailnul l.com> wrote in message
news:uZ******** ******@TK2MSFTN GP11.phx.gbl...

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(obj ect sender, System.EventArg s e)
{
Process procID;
string procName;
ProcessStartInf o psi = new ProcessStartInf o();
procName=System .Configuration. ConfigurationSe ttings.AppSetti ngs["Applicatio n Name"].ToString();
psi.FileName = procName;
psi.Arguments="-noOp";
psi.WorkingDire ctory=procName. SubString(0,pro cName.LastIndex Of('\\');
procID = Process.Start(p si);

}

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.UseShellEx ecute = false". This will cause
Process.Start() to use CreateProcess() behind the scenes instead of
ShellExecuteEx( ).

Are you using ConfigurationSe ttings.AppSetti ngs() 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 ConfigurationSe ttings, 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