By using this site, you agree to our updated Privacy Policy and our Terms of Use. Manage your Cookies Settings.
425,967 Members | 815 Online
Bytes IT Community
+ Ask a Question
Need help? Post your question and get tips & solutions from a community of 425,967 IT Pros & Developers. It's quick & easy.

Executing "unknown" command line in C#

P: n/a
[Reposting this in this group since a helpful soul pointed out that
microsoft.public.dotnet.csharp.general has very low traffic, despite one
probably accurate answer, I'll try my luck here as well]

Hi,

I've been trying to figure this one out, but my experience just doesn't
have what it takes... :|

I am writing an application that reads an XML file and displays the
contents in various ways to the end user. This works fine. My challenge
lies in the fact that these XML files are generated by various (third
party) applications. Which application generates them depends on the
user, the country they are in, their personal preferences, the features
of the applications etc. Basically, there can be any number of them, and
I probably don't even know 10% of the alternatives.

However, since I am a thoughtful developer that wants to listen to my
users, I don't want them to have to do this XML-grabbing by themselves.
Sure, some do it the old way in a DOS box, others just download the file
from the web somewhere, others make scheduled tasks in Windows etc. The
thing they have in common is that there is always a command line to grab
a fresh copy of the XML file. So I implemented a simple scheduler in my
app that should run the XML file generator/grabber of choice once a day,
once a week or whatever.

Here comes the problem; I want the user to be able to easily tell my
application what it needs to do in order to grab the file. So let's say
we have three users X, Y and Z who need to run these commands in order
to grab their stuff:

X: superblala.exe -grab
Y: justgrabit.exe
Z: complexthing.exe /x /fwahey.xml /b /u /g

What I've done is to add a "..." button to allow the user to browse for
the executable. Then they have to manually type in the arguments
afterwards (well, not Y, since he has a dedicated .exe for grabbing).

So you may begin to see my problem. I have a string that needs to be
executed. And it works fine if you execute it from a DOS box, a
scheduled task in the OS, or Start -> Run. However, if I want to do it
the proper .net way (as far as I can tell), I have to use one of the
System.Diagnostics.Process ways of doing it. And this creates the core
of my problem - to do this, I have to divide my command line into two
strings - one for the .exe (or whatever) file, another for the
arguments. The way I see it, these are my options:

1) Create two text boxes. One for the exe file (connected to the Browse
button), another for the arguments.

2) Do some magic on the string and figure out what part of it is the
actual command, and what part is the arguments.

3) Create a temporary .bat file on the fly and execute it.

4) Use the super magic happy solution that one of the people reading
this post who knows a lot more than me about C# and .net comes up with
that allows me to just tell the OS to run the damn thing and never mind
where the command stops and the parameters start.

So I have thought quite a bit about this. 1 might be the way to go, but
for me, an old command line warrior, it feels a bit counter-intuitive
and wrong. Solution 2 is the Rambo way of doing it, and is far from
impossible, but sounds like quite a bit of work and time that I would
rather spend on other aspects of my application. Number 3 is the easy
way out for sure, but also feels kinda like a cheat. So what I'm hoping
for is that this post will make someone come up with a beautiful and
elegant version of solution 4, where I just push my string into the
operating system somewhere, and then it does its job of figuring such
things out, instead of burdening poor me with it.

So, what do you say? Am I doomed? Or is there hope?

Thanks for any insight!

Rune
Jan 2 '06 #1
Share this Question
Share on Google+
1 Reply


P: n/a
Rune,

Try passing the full command line to the ProcessStartInfo instance as
the filename. Also, make sure that UseShellExecute is set to false (since
you know the name of the exe, you shouldn't need to use shell execution).

It should then call CreateProcess, which will pass the full command line
to CreateProcess as the command line attribute (with the executable name).

Hope this helps.
--
- Nicholas Paldino [.NET/C# MVP]
- mv*@spam.guard.caspershouse.com

"Rune Jacobsen" <rune.jacobsen@no_spam.broadpark.no> wrote in message
news:43********@news.broadpark.no...
[Reposting this in this group since a helpful soul pointed out that
microsoft.public.dotnet.csharp.general has very low traffic, despite one
probably accurate answer, I'll try my luck here as well]

Hi,

I've been trying to figure this one out, but my experience just doesn't
have what it takes... :|

I am writing an application that reads an XML file and displays the
contents in various ways to the end user. This works fine. My challenge
lies in the fact that these XML files are generated by various (third
party) applications. Which application generates them depends on the user,
the country they are in, their personal preferences, the features of the
applications etc. Basically, there can be any number of them, and I
probably don't even know 10% of the alternatives.

However, since I am a thoughtful developer that wants to listen to my
users, I don't want them to have to do this XML-grabbing by themselves.
Sure, some do it the old way in a DOS box, others just download the file
from the web somewhere, others make scheduled tasks in Windows etc. The
thing they have in common is that there is always a command line to grab a
fresh copy of the XML file. So I implemented a simple scheduler in my app
that should run the XML file generator/grabber of choice once a day, once
a week or whatever.

Here comes the problem; I want the user to be able to easily tell my
application what it needs to do in order to grab the file. So let's say we
have three users X, Y and Z who need to run these commands in order to
grab their stuff:

X: superblala.exe -grab
Y: justgrabit.exe
Z: complexthing.exe /x /fwahey.xml /b /u /g

What I've done is to add a "..." button to allow the user to browse for
the executable. Then they have to manually type in the arguments
afterwards (well, not Y, since he has a dedicated .exe for grabbing).

So you may begin to see my problem. I have a string that needs to be
executed. And it works fine if you execute it from a DOS box, a scheduled
task in the OS, or Start -> Run. However, if I want to do it the proper
.net way (as far as I can tell), I have to use one of the
System.Diagnostics.Process ways of doing it. And this creates the core of
my problem - to do this, I have to divide my command line into two
strings - one for the .exe (or whatever) file, another for the arguments.
The way I see it, these are my options:

1) Create two text boxes. One for the exe file (connected to the Browse
button), another for the arguments.

2) Do some magic on the string and figure out what part of it is the
actual command, and what part is the arguments.

3) Create a temporary .bat file on the fly and execute it.

4) Use the super magic happy solution that one of the people reading this
post who knows a lot more than me about C# and .net comes up with that
allows me to just tell the OS to run the damn thing and never mind where
the command stops and the parameters start.

So I have thought quite a bit about this. 1 might be the way to go, but
for me, an old command line warrior, it feels a bit counter-intuitive and
wrong. Solution 2 is the Rambo way of doing it, and is far from
impossible, but sounds like quite a bit of work and time that I would
rather spend on other aspects of my application. Number 3 is the easy way
out for sure, but also feels kinda like a cheat. So what I'm hoping for is
that this post will make someone come up with a beautiful and elegant
version of solution 4, where I just push my string into the operating
system somewhere, and then it does its job of figuring such things out,
instead of burdening poor me with it.

So, what do you say? Am I doomed? Or is there hope?

Thanks for any insight!

Rune

Jan 2 '06 #2

This discussion thread is closed

Replies have been disabled for this discussion.