0

Running an executable file (.exe) can be done with quite simple code, as demonstrated in this question. However, I rarely see anyone doing this and probably for a good reason.

I can understand, that it is probably affects the performance quite a bit (in a negative direction), but are there other pitfalls aside from that? A benefit could be, as I see it, a quite clean separation of code.

I have a specific case in mind, where I have to make a script which opens IE, navigates to a URL and fills a web form. The script will then be called from the main program (made in C#). So the overhead cost of running an .exe file in this case, would be relatively small. And the bonus would be, that others could make those IE automation scripts, without even knowing how my code works.

Am I missing something? Or do I actually have a decent idea?

Jakob Busk Sørensen
  • 5,599
  • 7
  • 44
  • 96
  • 2
    It's not commonly done because it's not a common requirement, not that there's something horribly wrong on doing so. In your case, it's not really useful. You could just create a new Library project and reference it, and anyone who wants to use it can reference it. It's easier to both use and manage – Camilo Terevinto Jan 14 '18 at 21:38
  • 1
    It's has and is being done all the time. I myself thought it was clever in 2003 and made a app that would open IE, go to my the site I chose like my BankOfAmerica, and then sign me in. It worked and I thought it was cool until I found out I haven't done anything new or clever. So yeah, you have a decent idea and no you're not missing anything. This is why we have startup arguments and can call Process.Start to begin with. – Michael Puckett II Jan 15 '18 at 01:13
  • @CamiloTerevinto there is always a twist. In my case, the twist is, that we have some existing code in Visual Basic. I believe that the easiest way to access this code, is by running its executable file. Otherwise, I agree with your input. – Jakob Busk Sørensen Jan 15 '18 at 07:09

1 Answers1

2

One of the drawbacks of starting other programs is, as stated, how long it can take to start child programs.

Another drawback is the dependence of your program on the other program running correctly. If the program you start doesn't run as expected, or perhaps even doesn't start at all, it's more difficult to trace what went wrong from your program, and even more difficult to handle any faults. Depending on the program you're creating, it may become useless without the child program functioning correctly.

Compatibility can be a major issue. Your program may be incompatible with the child program you're calling, and as such data may not be passed between them as desired. Although you can verify that your program is compatible with the target machine's operating system, it's more difficult to assess compatibility between a child program that you haven't created and the operating system.

If you include a copy of any child programs that you're using in the installation files for your program many of these issues are not a problem; however this may not be possible for legal reasons if your child programs are not created by you.

Similarly you may not be authorised to use any program not created by you in your program.

On the other hand it can be very useful at times to utilise existing programs as it can save you a lot of time. It may also be able to offer a service which you cannot create yourself. It is essential to call other programs from your own in many cases.

0liveradam8
  • 752
  • 4
  • 18