I want to create a command executor like Start > Run. The application has a TextBox and when a user enters a command eg : notepad "C:\test.txt" it should open notepad with this file or %PROGRAMFILES% it should open 'Programs Files' directory.
For %PROGRAMFILES% and other Windows variables I can use Environment.ExpandEnvironmentVariable and get their path and pass to Process.Start
and for notepad, I can split the with space and first part goes in FileName and rest of string goes in Arguments of ProcessStartInfo.
But what I want to know is, how does Start > Run work ? is there something like I can execute the whole command without splitting command-line or expanding the variables ? Maybe with pinvoke ?
To the very best of my knowledge, the run dialog is implemented with a call to ShellExecuteEx. You can achieve the same with Process.Start and UseShellExecute. You do need to expand the environment variables, and split the command into filename and arguments. You already describe how to do that in your question, and, again to the best of my knowledge, there is no programmatic interface to the functionality of the Run dialog.
However, what you can do programmatically is show the Run dialog. Create an instance of the Shell object requesting the IShellDispatch interface, and then call the FileRun method.
Related
I have a requirement to execute several commands with elevated rights, something like:
call program that modifies a .config file of a service (needs admin rights)
net stop myservice (needs admin rights)
net start myservice (needs admin rights)
All of this dynamic, e. g. the first line could contain proxy settings, including user name and password, or any other modification to the settings file. (Settings file is in program folder, program to modify the settings file is externally provided. The actual info would be user entered through a GUI.)
I thought to create a very flexible solution, using a cmd.exe process with redirected stdin and stdout. But.. it looks like "runas" (needs ShellExecute) and redirected in-/output are exclusive.
(Also, I noticed that redirection and cmd.exe are quite hard to handle.. I had to write my own functions e. g. as a replacement for ReadLine, since the ReadLine expects a NewLine at the end and waits e. g. if there is a command prompt (meaning you have text in the line like c:\bla> but no NewLine. Still, not knowing what one gets as a result makes writing something generic difficult.)
There are 3 alternatives I can think of:
get the UAC prompt for every single command (I would not like that)
start a process that is elevated, this can then call whatever it wants -> needs an additional project (.exe) which I would like to avoid, also makes deployment more difficult (additional file)
create a batch file on the fly, run it elevated. This I also want to avoid, since there could be password information in plain text in that file (e. g. user/password for proxy). I would at least have to make sure to always overwrite its contents and then delete it.
How to handle this?
I think you've already diagnosed the issue, and enumerated your available options. To my mind the best option is to use runas to create a new elevated process, and get that process to do the work.
The other process need not be a different executable it could be your existing executable started with particular command line arguments. Once you have another process running elevated, you can certainly use cmd with redirected stdin/stdout to do the work. However, why use net stop/start rather than the service API? And can you do the .config file modification without starting a separate process?
I'm executing command lines containing passwords in C#, if I display the optional "Command Line" column in the windows task manager ("Processes" tab) it contains all the arguments including the passwords,
could you think of a way to hide this, like only showing the ".exe" file or something ?
Thanks
If you have control over the program you are calling, you could modify it to read the data from standard input instead of passing the passwords on the command line. This would prevent it from being part of the command line itself, which would "hide" it.
If you cannot change the program, there will be no way to hide the command line used to start the process, as there are Windows API calls that can query this for open processes (which is what is being used by Task Manager).
Well, fist off: In my opinion you should really not do something like passing credentials in a human readable format! Passing a path to a file containing encrypted credentials is not hard to do and much safer.
I don't think that hiding the commandline is even possible. Correct me if I'm wrong.
See: What is the easiest way to encrypt a password when I save it to the registry?
I just want to know how to pass arguments to windows services . The problem is , i am developed a windows application and then called it from Onstart() method . Now , i want to call the particular function from another project .
protected override void OnStart(string[] args)
{
Process.Start("C:\\Program Files\\macro.exe");
}
I want to call a function inside the macro.exe project with arguments . Any suggestions
If you want to use arguments passed to service, you can try:
Process.Start(#"C:\Program Files\macro.exe", String.Join(" ", args))
Note that using #Tudor answer you can have better control on started process, redirect input/output/error, show/hide window and many other nice things.
I wonder if at all you can call a function inside another EXE.
May be you can make a common DLL and refer it in macro.exe and your own application. If thats not a choice then you can either use sockets or file system to communicate with the EXE.
For eg. you pass your EXE 2 command line arguments "MyFunction", "Hello" as shown in previous comments above and the Exe grabs those args deduces that it needs to call MyFunction with argument Hello and to get back the result the EXE writes it to a predefined path and you read it from the file.
If the Exe is running and you can not pass command line to it, then may be the Exe keeps scanning an input file to get commands from external sources like your app. Or better still it listens on a port on which you fire commands to it.
I am not sure if there can be another more starightforward solution.
I've been working on a small and simple program that I drop files onto and, based on certian rules, they are moved to diffrent places.
The program works fine unless I drop more than a few files, then it kicks back an error (that appears to be more Windows than anything) that the start up command "c:\myapp.exe \file \file \file" is too long.
I realize I could set up a background proccess, but I really would prefer that this program not run in the backround (where it would be idle most of the time).
Is there a way around this limitation?
From this blog:
The maximum command line length for the CreateProcess function is 32767 characters. This limitation comes from the UNICODE_STRING structure.
If you are using the CMD.EXE command processor, then you are also subject to the 8192 character command line length limit imposed by CMD.EXE.
If you are using the ShellExecute/Ex function, then you become subject to the INTERNET_MAX_URL_LENGTH (around 2048) command line length limit imposed by the ShellExecute/Ex functions.
The maximum size of your environment is 32767 characters. The size of the environment includes all the variable names plus all the values.
So you're gonna have to settle with some of the mentioned workarounds (also, there's another workaround on the msdn blog I linked).
If you want to drop files with respect of Windows Explorer, then you can implement your own Drop Handlers as a Shell Extension Handlers see:
How to Create Drop Handlers (Windows)
Creating Shell Extension Handlers
On The Complete Idiot's Guide to Writing Shell Extensions you will find a good introduction how to write such extensions.
The part VI gives an example of Drop Handler (for a little other use case, but it dose not matter).
With respect of Drop Shell Extension Handler your program will receive full information about all dropped files and you need not start a child program with all the files as command like parameters.
I think the drag and drop handler is possibly one way to go, but it seems quite heavy.
An alternative solution is to use a Explorer Context Menu handler. With this in place, you would select all the files, but rather than dragging them, right click, and choose your new menu item "Send to ".
When the menu item is selected, it passes the list of commands to your program. There are a couple of ways of doing this:
launch your program, and feed the list of files to standard input
write the list of files to a temporary file, and launch your program with just one command argument - the temporary file listing the files to process. List files are usually prefixed with '#' on the command line to distinguish them from ordinary file names.
When the files are drag&dropped onto your application write the list of files names out to a text file, then give the location of this file to your program. The target program can then read in this file and process it line-by-line. This way you only ever pass a single file name.
I'd modify the application to pick up the files from a specific location (e.g. specific folder on a filesystem) rather than specifying each file on the command line.
UPDATE:
If the requirement is to be able to drag an item onto an .exe via Windows Explorer to start the application as Mark mentioned then you could put all of your files into one folder and drop the entire folder on the .exe.
I think the easiest solution is to modify your application to accept a directory as the parameter as opposed to a list of files. This would allow you to copy the multiple files into a single directory. You can then drag and drop the folder onto your executable. It would then run a command like "c:\myapp.exe \folder-with-files-in-it" which should not run into the command line parameter limitation that you are experiencing now.
I experienced a similar issue when I was trying to get security details on a long path.
My solution was to map drives whenever the path length got too long. Check out my solution on
How do I get the security details for a long path?
Unix commands frequently have one or two parameters that can be of unbounded length. Several of these commands have added parameters which can source those arguments from a file, or from standard input. So you have one command which gins up the list of arguments, and either pipes them to a temporary file, or pipes them to stdout.
See also, xargs, which can take a list of arguments and either invoke your command with all of the parameters, or in batches.
How to get around the command line length limit? Write your whole command to a batch file, e.g. to "C:\Users\Johnny\Documents\mybatch.bat". Write it as you would in the cmd (no need to escape anything). Then, in your code simply call that file:
strCmdText = "C:\\Users\\Johnny\\Documents\\mybatch.bat";
ProcessStartInfo ProcessInfo = new ProcessStartInfo("cmd.exe", "/K " + strCmdText);
ProcessInfo.CreateNoWindow = true;
ProcessInfo.UseShellExecute = true;
Process.Start(ProcessInfo);
I have been using Process.Start to launch executables (.exe) files. Now I need to execute a .pl file with some arguments. can I still use Process.Start or I need a different approach?
EDIT :- I am having to mark this question unanswered as I am getting the following error when I try to call the perl file from the CSharp code:- (When I call the same from the commandline with the same path and parameters, It works fine)
System.ApplicationException: StartProcess Failed
System.ComponentModel.Win32Exception: The specified executable is not a valid application for this OS platform)
Please note that when I try to call an .exe file from my C# code, I dont see the above error.
EDIT:-
Checking the following link now:- How do I call Perl script in C# application?
It seems that the ProcessStartInfo constructor has two parameters - fileName and the arguments. You should set Perl.exe as the fileName and the "argument" would be your perl file (.pl) with other arguments It accepts. Checking now....
You certainly can :) you can also pass it arguments by adding them after the file name in
Process.Start(file.pl args1 args 2);
It will load the file with your default application for .pl files, the other option is to specify the software then pass your file as a parameter providing you have the right software to handle the file it should be fine
Process.Start() can be pointed at any file and it will be opened using the default software or that which you specify, it need not be an executable.
Yes you can, Process.Start() takes a string parameter, what you pass for this parameter does exactly the same thing it would do if you entered the same string in the windows start -> run dialog.