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

Running an exe on a remote machine

P: n/a
Liz
Greetings.

Again, I'm hoping I'm answering an absurdly simple
question. My current situation is this: I have an .exe
file that contains numerous Shell commands that run an
external program that exists only on a specific production
machine. Various users on my network will need to be able
to activate this executable from their own desktops, as
they cannot have access to the physical machine with the
software or VNC access. Being new to the .NET environment
(and to Visual Basic), I'm not entirely sure how to make
the call to the .exe on the production machine such that
the executable will run on it's host machine and not on
the calling machine.

Do I need to investigate .NET Remoting, or is there a
simple solution to my problem?

Thanks in Advance.
Liz
Nov 20 '05 #1
Share this Question
Share on Google+
2 Replies


P: n/a
Hi Liz,

You cannot execute the executable just through the UNC path otherwise it
will make a local copy and execute from there.

So remoting is an option of course. If you want to kinda make it easy on
yourself, I would use a windows service to ensure the application is
executed on your production machine, basically call the service and tell it
to do something (this is actually a pretty good instance of webservices I
think) and then if you want something back, you can get it.

Hope it helps.

-CJ
"Liz" <ch*********@earthlink.net> wrote in message
news:01****************************@phx.gbl...
Greetings.

Again, I'm hoping I'm answering an absurdly simple
question. My current situation is this: I have an .exe
file that contains numerous Shell commands that run an
external program that exists only on a specific production
machine. Various users on my network will need to be able
to activate this executable from their own desktops, as
they cannot have access to the physical machine with the
software or VNC access. Being new to the .NET environment
(and to Visual Basic), I'm not entirely sure how to make
the call to the .exe on the production machine such that
the executable will run on it's host machine and not on
the calling machine.

Do I need to investigate .NET Remoting, or is there a
simple solution to my problem?

Thanks in Advance.
Liz

Nov 20 '05 #2

P: n/a
Liz
Thanks, CJ. A Windows service it is.

Liz
-----Original Message-----
Hi Liz,

You cannot execute the executable just through the UNC path otherwise itwill make a local copy and execute from there.

So remoting is an option of course. If you want to kinda make it easy onyourself, I would use a windows service to ensure the application isexecuted on your production machine, basically call the service and tell itto do something (this is actually a pretty good instance of webservices Ithink) and then if you want something back, you can get it.
Hope it helps.

-CJ
"Liz" <ch*********@earthlink.net> wrote in message
news:01****************************@phx.gbl...
Greetings.

Again, I'm hoping I'm answering an absurdly simple
question. My current situation is this: I have an .exe
file that contains numerous Shell commands that run an
external program that exists only on a specific production machine. Various users on my network will need to be able to activate this executable from their own desktops, as
they cannot have access to the physical machine with the
software or VNC access. Being new to the .NET environment (and to Visual Basic), I'm not entirely sure how to make
the call to the .exe on the production machine such that
the executable will run on it's host machine and not on
the calling machine.

Do I need to investigate .NET Remoting, or is there a
simple solution to my problem?

Thanks in Advance.
Liz

.

Nov 20 '05 #3

This discussion thread is closed

Replies have been disabled for this discussion.