Ответ 1
Да, это можно рассматривать как плохую практику по следующим причинам:
-
Плохая архитектура проекта
Если вам нужно вызвать какую-то логику из .exe, то эта логика там неправильно размещена. Вместо этого вы должны поместить его в отдельную dll и ссылаться на ту же самую .dll как из исполняемого файла, на который вы ссылаетесь в настоящее время, так и из приложения, которое ссылается на исполняемый файл. Как предлагается в комментариях ниже, извлечение логики в библиотеку может помочь вам избежать некоторых ограничений архитектуры ЦП, которые я опишу в следующем пункте, поскольку библиотека может быть построена для работы с любым ЦП. -
Ограничения архитектуры
Упомянутый исполняемый файл мог быть создан для оптимального обращения к 32-битным или 64-битным компьютерам или даже к конкретным процессорам (таким как Itanium). Библиотека может быть построена без этих спецификаций 1 чтобы быть кросс-CPU-совместимой, и, таким образом, впоследствии на нее будет ссылаться любой проект. Если вы ссылаетесь на исполняемый файл с конкретными настройками архитектуры, вы должны использовать совместимые настройки для ссылочного проекта. Это я считаю ограничением, так как вы не сможете распространять конечный продукт на определенных платформах. -
Усложнить юнит-тестирование
Как намекает Абель в комментариях, ваши модульные тесты войдут в свою собственную DLL, и они также должны будут ссылаться на исполняемый файл. Это может быть сложно проверить, если вы не предоставляете некоторые внутренние методы/поля с помощью атрибутаInternalsVisibleToили используете отражение (что является медленной альтернативой) для проверки и утверждения какого-либо невидимого для публики состояния ваших объектов. Исполняемые файлы не могут быть собраны с набором атрибутовInternalsVisibleTo, и если вы откатитесь на рефлексию, вы можете столкнуться с проблемами безопасности .NET, мешающими вам отразить членов исполняемого файла (например, потому что набор тестов был выполнен в рамках более строгой настройки),Вы также столкнетесь с вышеупомянутыми архитектурными ограничениями, которые приведут к использованию той же архитектуры для ваших модульных тестов. Это может быть проблемой, если ваши тестовые наборы выполняются на удаленной машине, как часть автоматизированной сборки (например, в TravisCI, Bamboo, TeamCity и т.д.). Затем агент CI должен соответствовать архитектуре ЦП исполняемого файла и набора тестов. Если подходящих агентов нет, тесты не проводятся. Кроме того, если вы используете общедоступную CI-платформу для создания своего приложения и выполнения тестов, это может считаться распространением исполняемого файла в юридическом смысле. Возможно, вы нарушите исполняемую лицензию - подробности смотрите в следующем разделе.
-
Потенциальные проблемы с лицензированием
Вы должны тщательно распространять свое выражение. Если для использования указанного исполняемого файла требуются дополнительные лицензии или сборы, вы должны будете заставить пользователей принять эту исполняемую лицензию вместе с лицензией вашего приложения (и заплатить за нее при необходимости), в противном случае вы рискуете сделать незаконное распространение. об этом с вашим программным обеспечением. Это также подразумевает, что вы имеете право ссылаться на исполняемый файл в первую очередь. -
Неизвестные последствия
Исполняемый файл будет скопирован в папку bin и установлен вместе с вашим приложением. Невозможно сказать, что может произойти, если кто-то просматривает папку bin и запускает ее. Есть несколько проблем с этим:-
Исполняемый файл аварийно завершает работу или ведет себя неправильно из-за неправильного ввода. Обычно это происходит, если у него нет графического интерфейса пользователя (например, если пользователь дважды щелкнул по программе командной строки, он не получит никакого ввода в виде аргументов командной строки и, следовательно, потерпит неудачу или будет плохо себя вести).
-
Исполняемый файл не предназначен для использования владельцем вашей программы, поскольку это будет юридически или логически противоречить тому, что делает ваше программное обеспечение.
-
Тем не менее, в некоторых случаях ссылки на исполняемый файл могут быть оправданы, но они достаточно редки:
- Исполняемый файл поставляется сторонним разработчиком, и не существует никакой библиотеки с такой же функциональностью, и нет другого способа ссылки на эту функциональность. Это также может быть явным требованием для вашего проекта, установленным вашим работодателем или клиентом.
- Исполняемый файл написан на другом языке, и вам нужно общаться с ним через взаимодействие.
Пока последнее не относится к вам, особенно если вы разрабатываете исполняемый файл, на который ссылаются сами, я определенно рекомендую извлечь необходимую логику в отдельную библиотеку.
1 На самом деле, вы также можете создать исполняемый файл для любого процессора, как упомянуто в комментарии Доминика Кекселя. Возможно и обратное - создать библиотеку для конкретного ЦП, но она встречается реже, так как обычно исполняемый файл предназначен для аппаратного обеспечения. Итак, чтобы прояснить свои соображения, я имел в виду ссылку на сторонний исполняемый файл или тот, который не может быть перестроен по другим причинам, и этот исполняемый файл уже оптимизирован для какой-то конкретной архитектуры. Если вы можете перестроить и изменить целевой процессор этих исполняемых файлов, то вы определенно можете извлечь необходимую логику в dll.