Pros and cons of using an existing .NET assembly versus a command-line tool for same purpose [closed]

Question

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.

Answer 1

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!!

Answer 2

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.)

Answer 3

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.