11

I have searched the Internet and I can't seem to find anything related to this topic. I would think there would have been some discussion on it. I just can't find it.

Basically, what I'm looking for is good reasons to use an existing .NET assembly to do the same thing an (older) command-line executable would do. Therefore, if I used the assembly, I'd include it and begin using it in my C# code. To us the old command-line tool, I'd do a Process.Start(...) and so forth.

Background on this is:

I have a requirement to perform PGP encryption and decryption on files transferred to and from our system. My current options are to use the command-line GPG tool (http://www.gnupg.org/) or the Bouncy Castle .NET assembly.

I have been asked why I don't just "automate" the old GPG command-line tool within my code. I'd like to answer this with some intelligence. Right now, I can only think of two reasons:

  1. Error handling: I should be able to not only get better error information using the .NET assembly, but handle them better via the try/catch with exceptions, etc. I could even roll my own exceptions as needed, etc.

  2. Code portability: Anything I build with the .NET assembly is more or less stand alone. I don't need to find and copy the GPG executable to each place I copy the application(s) I write using it.

  3. Performance: Possibly. I don't have any experience or data regarding this.

I'd appreciate any input on this topic.

DOK
  • 32,337
  • 7
  • 60
  • 92
Dan7el
  • 1,995
  • 5
  • 24
  • 46
  • I think your three points should already be enought to know what you should do, particularly if the command line tool is older... – Christoph Fink Jan 24 '12 at 15:12
  • 2
    4. Security. If it is possible to replace your GPG executable, then all the cryptography starts to make less sense. – zrslv Jan 24 '12 at 15:14
  • Honestly, your three reasons are a little weak, imo. If I was paying the bill to have you rewrite something, I would whole lot more cost/benefit analysis to justify rewriting something that works, and is proven. Upgrading to the newest technology is often more fun, but not for the person paying the bill. – E.J. Brennan Jan 24 '12 at 15:15
  • @zrxq: Good point, but you need to use strong named assembly to prevent the same from happening with a .net-Dll. – Christoph Fink Jan 24 '12 at 15:16
  • 1
    @E.J.Brennan: Where does he write something about rewriting something - the .net-Dll is also existent according to his question so I even think it may be faster to implement the usage! – Christoph Fink Jan 24 '12 at 15:18
  • Bit of a no brainer this. Question should be why should I have an external executable, and the only real reason I could see is it could be called from non .net apps, and it could be easily patched just by overwriting. Course the latter "benefit" is a tad dubious, given what it is. :( – Tony Hopkinson Jan 24 '12 at 15:19
  • @chrfin well, yes, if someone already has enough access to replace the executable, every other measure is just a question of how much effort they are willing to put. – zrslv Jan 24 '12 at 15:21

4 Answers4

6

Honestly, I would go with the .NET assembly as it seems to be a simpler solution and a more tightly contained solution than launching a new process. Some of the reasons I feel that way are as follows:

  1. With the command line tool, you're launching a new process. So it's a completely separate process ID running, and will run outside of the scope and application domain of your existing application. All communication between your application and the process will be across process boundaries and would have to be done either with a service call, some sort of shared memory, or some other approach, which could be cumbersome (especially when dealing with issues).
  2. With launching a new process, you basically lose control of that process from your application. If your application dies or shuts down, you're going to have to explicitly kill that process - otherwise you may have handles left open, files locked, etc.
  3. Including the .NET assembly in your application allows everything to run within the same context (generally), which allows for better communication between components, easier debugging and trouble-shooting (generally), and a single process being managed.
  4. You have a little more control over your code. Launching a process is basically a black-box -- you have no idea what's going on inside of it. Granted, with the .NET assembly you also have a similar black-box scenario, but since it's in the same process, you may have some additional insight into how the calls are being made, where exceptions are being thrown, etc. Basically, you have a little more insight into the component with a .NET assembly rather than launching a new process.

Those are just some thoughts off the top of my head. I hope this helps. If you have questions, let me know and I'll elaborate my answers. Good luck!!

David Hoerster
  • 28,421
  • 8
  • 67
  • 102
  • Thank you all for the quick answers. I will definitely use this information as further information on why I would prefer to use the *already existing* .NET assembly. – Dan7el Jan 24 '12 at 15:26
3

I personally would use a .Net assembly instead of a command-line tool when possible.

Pros:

  • easier to deploy (you don't have to copy the executable)
  • better portability (depending on the commande-line tool compilation options, it could not work on some platforms; on the other hand, pure .Net managed assemblies compiled to target AnyCPU should work fine on x86/x64 machines)
  • easier manipulation of the third party library (function parameters vs command line parsing/formatting)
  • choose whether you call your methods synchronously or not; in the other hand, a separate process must be asynchronous. Threads/processes synchronization is not a trivial job.
  • you won't have to deal with IPC as everything is in a single process
  • much more easier to debug (step by step debug...etc.)
  • exception management also easier (you'll get a full stack trace, not just a dummy process exit code)
  • use of .Net concepts (object oriented programming, Exceptions, events...etc.)
ken2k
  • 48,145
  • 10
  • 116
  • 176
2

I agree with 1, 2, and 3. Starting a new process for each encrypt/decrypt is definitely more expensive than performing it in process. This get even more crucial if you need to perform multiple encrypt/decrypt concurrently, which reading your question I expect you do.

In addition, is there a 64 bit version of the command line tool? This may be an argument against.

Myles McDonnell
  • 12,943
  • 17
  • 66
  • 116
2

It's simpler to do. Two of your three items all come back to this.

The third is possibly true, because there's less processes to have going and no need to communicate between them, or false because the executable happens to give much better performance than the assembly and that out-weighs this effect.

But simplicity buys a hell of a lot, and it keeps on giving (you may have to support this application for some time). Probably there are a good few other "pros" that can be thought of that come down to this in the end.

Really, when something is simpler (and really simpler, rather than the siren-call of the over-simple that ends up being more complicated in the long-run), you need some really compelling counter-arguments to out-weigh that.

Jon Hanna
  • 110,372
  • 10
  • 146
  • 251