Плюсы и минусы использования существующей сборки .NET по сравнению с инструментом командной строки для той же цели

Я искал Интернет, и я не могу найти ничего, что связано с этой темой. Я бы подумал, что в этом было бы некоторое обсуждение. Я просто не могу его найти.

В принципе, то, что я ищу, является веским основанием для использования существующей сборки .NET, чтобы сделать то же самое, что и предыдущий исполняемый файл командной строки. Поэтому, если бы я использовал сборку, я бы включил ее и начал использовать ее в своем коде на С#. Для нас старый инструмент командной строки, я бы сделал Process.Start(...) и т.д.

Справочная информация по этому вопросу:

У меня есть требование выполнить шифрование и дешифрование PGP для файлов, переданных в нашу систему и из нее. Мои текущие параметры - использовать инструмент командной строки командной строки (http://www.gnupg.org/) или сборку Bouncy Castle.NET.

Меня спросили, почему я не просто "автоматизирую" старый инструмент командной строки GPG в своем коде. Я хотел бы ответить на этот вопрос с некоторым умом. Сейчас я могу думать только о двух причинах:

Обработка ошибок: я должен иметь возможность не только получать более эффективную информацию об ошибках, используя сборку .NET, но лучше обрабатывать их с помощью try/catch с исключениями и т.д. Я мог бы даже свернуть свои собственные исключения по мере необходимости, и др.
Переносимость кода: все, что я собираю с помощью сборки .NET, более или менее автономно. Мне не нужно находить и копировать исполняемый файл GPG для каждого места. Я копирую приложение (ы), которое я пишу, используя его.
Производительность: возможно. У меня нет опыта или данных относительно этого.

Буду признателен за любые материалы по этой теме.

Ответ 1

Честно говоря, я пошел бы с сборкой .NET, поскольку это, кажется, более простое решение и более жесткое решение, чем запуск нового процесса. Некоторые из причин, по которым я так чувствую, следующие:

С помощью инструмента командной строки вы запускаете новый процесс. Таким образом, он запускает полностью отдельный идентификатор процесса и запускается за пределами области действия и области приложения существующего приложения. Вся связь между вашим приложением и процессом будет проходить через границы процесса и должна выполняться либо с помощью вызова службы, либо с помощью некоторой общей памяти, либо с помощью какого-либо другого подхода, который может быть громоздким (особенно при решении проблем).
При запуске нового процесса вы в основном теряете контроль над этим процессом из своего приложения. Если ваше приложение умирает или выключается, вам придется явно убить этот процесс, иначе у вас могут быть открытые ключи, заблокированные файлы и т.д.
Включение сборки .NET в ваше приложение позволяет запускать все в одном и том же контексте (обычно), что обеспечивает лучшую связь между компонентами, упрощает отладку и устранение неполадок (обычно) и управляется одним процессом.
У вас есть немного больше контроля над вашим кодом. Запуск процесса - это, в основном, черный ящик - вы не представляете, что происходит внутри него. Конечно, с сборкой .NET у вас также есть похожий сценарий с черным ящиком, но поскольку он находится в том же процессе, у вас может быть некоторое представление о том, как выполняются вызовы, где выбрасываются исключения и т.д. В принципе, вы имеют немного больше информации о компоненте с сборкой .NET, а не запускают новый процесс.

Это лишь некоторые мысли с головы. Надеюсь, это поможет. Если у вас есть вопросы, сообщите мне, и я уточню свои ответы. Удачи!

Ответ 2

Я лично использовал бы сборку .Net вместо инструмента командной строки, когда это было возможно.

Плюсы:

проще развернуть (вам не нужно копировать исполняемый файл)
улучшенная переносимость (в зависимости от параметров компиляции инструмента командной строки он не может работать на некоторых платформах, с другой стороны, чистые .Net управляемые сборки, скомпилированные для целевого AnyCPU, должны отлично работать на машинах x86/x64)
упрощение манипулирования библиотекой сторонних разработчиков (параметры функции vs разбор/форматирование командной строки)
выберите, будете ли вы синхронно вызывать свои методы; с другой стороны, отдельный процесс должен быть асинхронным. Синхронизация потоков/процессов - это не тривиальное задание.
вам не придется иметь дело с IPC, поскольку все в одном процессе
гораздо проще отлаживать (пошаговое отладка... и т.д.) Менеджмент исключений
также проще (вы получите полную трассировку стека, а не только код завершения фиктивного процесса).
использование .Net-концепций (объектно-ориентированное программирование, Exceptions, events... и т.д.)

Ответ 3

Я согласен с 1, 2 и 3. Запуск нового процесса для каждого шифрования/дешифрования определенно дороже, чем выполнение его в процессе. Это становится еще более важным, если вам нужно одновременно выполнять множественное шифрование/дешифрование, которое читает ваш вопрос, который я ожидаю от вас.

Кроме того, есть ли 64-разрядная версия инструмента командной строки? Это может быть аргументом против.

Ответ 4

Это проще сделать. Два из ваших трех предметов возвращаются к этому.

Третий, возможно, истинный, потому что там меньше процессов и нет необходимости обмениваться данными между ними или false, потому что исполняемый файл обеспечивает гораздо лучшую производительность, чем сборка, и это повышает вес этого эффекта.

Но простота приобретает чертовски много, и она продолжает давать (вам, возможно, придется поддерживать это приложение в течение некоторого времени). Наверное, есть и другие "плюсы", которые можно подумать о том, что в конце концов дойдет до этого.

Действительно, когда что-то более простое (и действительно более простое, а не сирена-вызов сверхпростого, который в конечном итоге становится более сложным), вам понадобится действительно контр-аргументы, чтобы взвесить это.