|
The execPath is invalid for a WorkingDirectory. Just don't put one, or make it "C:\".
|
|
|
|
|
That's certainly true of the line:
string filePath = execPath + "HSMDiskStatus.exe";
But that line isn't really being used. This line:
System.Diagnostics.Process.Start("HSMDiskStatus.exe ", @"/F E:\DPSanChart\" + servername + ".txt");
Is being used, and the OS doesn't find "HSMDiskStatus.exe " in the current directory. (Should probably get rid of that SPACE too.)
|
|
|
|
|
Unless I'm mistaken, the UNC path
string execPath = @"\\" + servername + @"\E:\datacenter\";
is illegal. You can't have a colon in the share name, so the path is invalid.
|
|
|
|
|
True, but I don't think he's using that value at this time... but I sure wish the code were cleaned up. I've seen some pretty messy snippets on here today.
|
|
|
|
|
Oh crap! I saw that he went through the trouble of putting a ProcessStartInfo together and then I thought actually used it... 
|
|
|
|
|
Dave,
I took out the colon: in the UNC path. I have included the path and directory in the System.Diagnostics.Process.Start(). I am getting a new error when I try this: "No process is associated with this object." I physically went to the directory and execute the HSMDiskStatus.exe w/o any problem. How do I know whether my code connected to the remote machine or it's looking in my local machine for the HSMDiskStatus.exe?
Here is my code:
string password = "password";
Process proc = new Process();
proc.StartInfo.Domain = servername;
proc.StartInfo.FileName = "HSMDiskStatus.exe";
proc.StartInfo.UserName = @"domain\user";
System.Security.SecureString secret = new System.Security.SecureString();
foreach (char c in password)
{
secret.AppendChar(c);
}
proc.StartInfo.UseShellExecute = false;
proc.StartInfo.Password = secret;
System.Diagnostics.Process.Start(@"\\" + servername + @"\E$\datacenter\HSMDiskStatus.exe ", @"/F E:\DPSanChart\" + servername + ".txt");
while (!proc.HasExited)
{
proc.Refresh();
}
proc.Close();
|
|
|
|
|
donjuanwu wrote: How do I know whether my code connected to the remote machine or it's looking in my local machine for the HSMDiskStatus.exe?
The code is loading the .EXE from the path specified by "\\servername\E$\datacenter\HSMDiskStatus.exe". Are you trying to get the process to run on the local machine, or are you trying to get the remote machine to run this HSMDiskStatus??
If you're trying to get the remote machine to run this app, you're wasting your time. You cannot use the Process class to get a remote machine to launch an app.
|
|
|
|
|
when you said the code is loading the .EXE from the path, are you saying the code is copy the .EXE from the specified path and execute the .EXE from the local machine? I would like to execute the .EXE from the remote machine since the .EXE is in the remote machine. do you know of a class that I can use to execute the .EXE from the remote machine?
Thanks,
|
|
|
|
|
donjuanwu wrote: when you said the code is loading the .EXE from the path, are you saying the code is copy the .EXE from the specified path and execute the .EXE from the local machine?
The .EXE is being loaded and run on the local machine, just as if you ran it from your own hard drive.
donjuanwu wrote: I would like to execute the .EXE from the remote machine
You mean execute the .EXE ON the remote machine?? No, there is no .NET class that does this because it's a HUGE security risk.
It CAN be done though, using WMI's Win32_Process[^] class, though with very large restrictions. The process you launch cannot be interactive, meaning there will be no user interface showing on the remote machine, and it runs with limited access to machine resources.
|
|
|
|
|
What I've tried (and I think it worked) is writing a BAT file on the remote system that will run the EXE and then use SCHTASKS to create a task on the remote system to run it. Total Kludge, but it could solve the problem. Still no interface of course.
|
|
|
|
|
Yeah, I'v seen PSEXEC being used too. The problem with that is it's on everybody's virus scanners "Potentialy Unwanted Program" list.
If all he's looking for is the disk space information, it's far easier to use WMI to get it than running a remote proc.
|
|
|
|
|
if I don't include the path and the filename"
string execPath = @"\\" + servername + @"\E:\datacenter\";
string filePath = execPath + "HSMDiskStatus.exe";
proc.StartInfo.FileName = filePath;
how would the code know to connect to the remote server? Also, I comment out the code line:
// proc.StartInfo.WorkingDirectory = execPath;
I still get the incorrect parameter error.
proc.StartInfo.UseShellExecute = false;
proc.StartInfo.Password = secret;
// proc.StartInfo.WorkingDirectory = execPath;
System.Diagnostics.Process.Start("HSMDiskStatus.exe ", @"/F E:\DPSanChart\" + servername + ".txt");
|
|
|
|
|
Dave,
I have tried the following and I still not able to make it work:
// proc.StartInfo.WorkingDirectory = @"C:\";
proc.StartInfo.WorkingDirectory = @"C:\";
proc.StartInfo.WorkingDirectory = @"E:\datacenter";
I still get the parameter is in correct.
|
|
|
|
|
Use PIEBALDconsultant's suggestion and PLEASE change that throw ex; in your catch to just be throw; If you rethrow the exception the way you are doing it, you will hide the stack trace.
Process also has a FileName property that you can use to set the path/name of the executable. So if you use FileName property with the Arguments, you only need to do a Process.Start() without any parameters.
|
|
|
|
|
Hi Chris,
I changed my code to use the Process.StartInfo.Argument to set the command lines and I still get an error. My error is "the parameter is incorrect."
private void ConnectToDataServer(string servername)
{
try
{
string execPath = @"\\" + servername + @"\E:\datacenter\";
string filePath = execPath + "HSMDiskStatus.exe";
string password = "password";
Process proc = new Process();
proc.StartInfo.Domain = servername;
proc.StartInfo.FileName = filePath;
proc.StartInfo.Arguments =@"/F e:\DPSanChart\" + servername + ".txt";
proc.StartInfo.UserName = @"domain\user";
System.Security.SecureString secret = new System.Security.SecureString();
foreach (char c in password)
{
secret.AppendChar(c);
}
proc.StartInfo.UseShellExecute = false;
proc.StartInfo.Password = secret;
proc.StartInfo.WorkingDirectory = execPath;
proc.Start();
while (!proc.HasExited)
{
proc.Refresh();
}
proc.Close();
}
catch (Exception ex)
{
throw;
}
On a different note what is the advantage of seeing the stack. What is the stack? I look at the detail of the error within the catch block and the error looks the same to me...)
|
|
|
|
|
What line is it dying on? I've never actually tried to use the Process class on a remote server, so I'm not sure what else to tell you. I don't see anything too glaring while looking over the code.
The Call Stack contains the list of methods that have occured during the current execution. Sometimes errors aren't so easy to find just by the error message and the stack helps you see what execution path your app took to create that error.
|
|
|
|
|
The code broke right after it execute @ proc.Start() and jump straight to the catch(Exception ex). Is there another way to execute a remote executable with switches on a remote server? I have looked into WMI but it doesn't allow me to execute an executable. I will be glad to try other ways if you show me how. Also, how do you look at the methods of the stack?
Thanks,
|
|
|
|
|
Maybe this will be of help? This person seemed to have the same issue and it turned out to be a permissions issue
http://forums.asp.net/t/1129890.aspx[^]
The call stack is displayed in the debugger when you hit a breakpoint. It's a window that can be displayed along side the output window.
Debug -> Windows -> Call Stack (CTRL-ALT-C)
|
|
|
|
|
Let's start over...
Do you have to run the EXE on the remote machine? Or do you run it on the local machine and tell it to gather data from the remote machine?
|
|
|
|
|
In my 27 years of coding for a living, I have never had to deal regular expressions. When you've recovered from your disbelief that anyone could for so long without having been exposed to this ungainly quagmire of coding fecal matter, here's my question:
I'm converting some php code to C#, and I ran into this line of php code:
preg_replace("/\:\/\/.*/", "", $blah)
The $blah string looks something like this:
php:
-- moved at 0:47 Wednesday 19th September, 2007
"Why don't you tie a kerosene-soaked rag around your ankles so the ants won't climb up and eat your candy ass..." - Dale Earnhardt, 1997
-----
"...the staggering layers of obscenity in your statement make it a work of art on so many levels." - Jason Jystad, 10/26/2001
|
|
|
|
|
Hi John,
I just bought RegexBuddy instead and let it do the hard work.
regards,
|
|
|
|
|
Can you run that through regexbuddy and tell me what it does?
"Why don't you tie a kerosene-soaked rag around your ankles so the ants won't climb up and eat your candy ass..." - Dale Earnhardt, 1997
-----
"...the staggering layers of obscenity in your statement make it a work of art on so many levels." - Jason Jystad, 10/26/2001
|
|
|
|
|
It looks like it's removing the path, etc. so you are left with:
This is removed:
//www/owl/htdocs/index_sso.php --url=http://www.my.server/owl/
leaving:
php:browse.php
preg_replace("/\:\/\/.*/", "", $blah)
The '\' character in the regular expression escapes the following character so that any special meaning is ignored.
|
|
|
|
|
John Simmons / outlaw programmer wrote: this ungainly quagmire of coding fecal matter
Yep. It's not for ordinary mortals!
Kevin
|
|
|
|
|
PHP RegExp tester
looks like that one grabs the "php" (or "html" or whatever comes before the ':' ) off the front of the string.
|
|
|
|
General 
News 
Suggestion 
Question 
Bug 
Answer 
Joke 
Praise 
Rant 
Admin 
Submit an article or tip
