У меня есть один простой вопрос.
Я знаю, что могу ссылаться на исполняемый файл .net в моем проекте С#.
Я не хочу делать ненужный проект с помощью "Тип вывода: приложение Windows", чтобы вызвать некоторые DLL.
Я просто хочу знать, нормально ли это, или это плохая практика, чтобы отредактировать exe файл?
Да, это можно рассматривать как плохую практику по следующим причинам:
Плохая архитектура проекта
Если вам нужно вызвать какую-то логику из .exe, то эта логика там неправильно размещена. Вместо этого вы должны поместить его в отдельную dll и ссылаться на ту же самую .dll как из исполняемого файла, на который вы ссылаетесь в настоящее время, так и из приложения, которое ссылается на исполняемый файл. Как предлагается в комментариях ниже, извлечение логики в библиотеку может помочь вам избежать некоторых ограничений архитектуры ЦП, которые я опишу в следующем пункте, поскольку библиотека может быть построена для работы с любым ЦП.
Ограничения архитектуры
Упомянутый исполняемый файл мог быть создан для оптимального обращения к 32-битным или 64-битным компьютерам или даже к конкретным процессорам (таким как Itanium). Библиотека может быть построена без этих спецификаций 1 чтобы быть кросс-CPU-совместимой, и, таким образом, впоследствии на нее будет ссылаться любой проект. Если вы ссылаетесь на исполняемый файл с конкретными настройками архитектуры, вы должны использовать совместимые настройки для ссылочного проекта. Это я считаю ограничением, так как вы не сможете распространять конечный продукт на определенных платформах.
Усложнить юнит-тестирование
Как намекает Абель в комментариях, ваши модульные тесты войдут в свою собственную DLL, и они также должны будут ссылаться на исполняемый файл. Это может быть сложно проверить, если вы не предоставляете некоторые внутренние методы/поля с помощью атрибута InternalsVisibleTo или используете отражение (что является медленной альтернативой) для проверки и утверждения какого-либо невидимого для публики состояния ваших объектов. Исполняемые файлы не могут быть собраны с набором атрибутов InternalsVisibleTo, и если вы откатитесь на рефлексию, вы можете столкнуться с проблемами безопасности .NET, мешающими вам отразить членов исполняемого файла (например, потому что набор тестов был выполнен в рамках более строгой настройки),
Вы также столкнетесь с вышеупомянутыми архитектурными ограничениями, которые приведут к использованию той же архитектуры для ваших модульных тестов. Это может быть проблемой, если ваши тестовые наборы выполняются на удаленной машине, как часть автоматизированной сборки (например, в TravisCI, Bamboo, TeamCity и т.д.). Затем агент CI должен соответствовать архитектуре ЦП исполняемого файла и набора тестов. Если подходящих агентов нет, тесты не проводятся. Кроме того, если вы используете общедоступную CI-платформу для создания своего приложения и выполнения тестов, это может считаться распространением исполняемого файла в юридическом смысле. Возможно, вы нарушите исполняемую лицензию - подробности смотрите в следующем разделе.
Потенциальные проблемы с лицензированием
Вы должны тщательно распространять свое выражение. Если для использования указанного исполняемого файла требуются дополнительные лицензии или сборы, вы должны будете заставить пользователей принять эту исполняемую лицензию вместе с лицензией вашего приложения (и заплатить за нее при необходимости), в противном случае вы рискуете сделать незаконное распространение. об этом с вашим программным обеспечением. Это также подразумевает, что вы имеете право ссылаться на исполняемый файл в первую очередь.
Неизвестные последствия
Исполняемый файл будет скопирован в папку bin и установлен вместе с вашим приложением. Невозможно сказать, что может произойти, если кто-то просматривает папку bin и запускает ее. Есть несколько проблем с этим:
Исполняемый файл аварийно завершает работу или ведет себя неправильно из-за неправильного ввода. Обычно это происходит, если у него нет графического интерфейса пользователя (например, если пользователь дважды щелкнул по программе командной строки, он не получит никакого ввода в виде аргументов командной строки и, следовательно, потерпит неудачу или будет плохо себя вести).
Исполняемый файл не предназначен для использования владельцем вашей программы, поскольку это будет юридически или логически противоречить тому, что делает ваше программное обеспечение.
Тем не менее, в некоторых случаях ссылки на исполняемый файл могут быть оправданы, но они достаточно редки:
Пока последнее не относится к вам, особенно если вы разрабатываете исполняемый файл, на который ссылаются сами, я определенно рекомендую извлечь необходимую логику в отдельную библиотеку.
1 На самом деле, вы также можете создать исполняемый файл для любого процессора, как упомянуто в комментарии Доминика Кекселя. Возможно и обратное - создать библиотеку для конкретного ЦП, но она встречается реже, так как обычно исполняемый файл предназначен для аппаратного обеспечения. Итак, чтобы прояснить свои соображения, я имел в виду ссылку на сторонний исполняемый файл или тот, который не может быть перестроен по другим причинам, и этот исполняемый файл уже оптимизирован для какой-то конкретной архитектуры. Если вы можете перестроить и изменить целевой процессор этих исполняемых файлов, то вы определенно можете извлечь необходимую логику в dll.
Если вы включаете исполняемый файл в качестве ресурса в свой проект, то я полагаю, что это не имеет большого значения, если он решает вашу проблему и работает (хотя в теории было бы более правильным выделять общую логику в отдельный .dll, который может быть использован в нескольких проектах).
Однако: Возможно, вы захотите включить этот .exe в качестве встроенного ресурса, чтобы он не отображался непосредственно в выходном каталоге при создании проекта:
Щелкните правой кнопкой мыши узел проекта и выберите Add > Existing Item и найдите файл .exe. Теперь щелкните правой кнопкой мыши в обозревателе решений, выберите properties и установите для Build Action значение Embedded Resource.
Файл будет "встроен" в ваши собственные .dll или .exe или что-то, что вы создаете, вместо того, чтобы просто копироваться в ваш выходной каталог.
.NET DLL или EXE, оба являются сборками, вы можете использовать exe или dll, ссылаясь на них. Нет проблем с доставкой exe с вашим кодом, пока вы не захотите, чтобы этот exe выполнялся отдельно.
Это нормально, если это поможет вам своевременно отправить товар.
Это не нормально в долгосрочной перспективе. Так что вы можете просто оставить себе записку, чтобы пересмотреть ее, как только у вас будет необходимое время, чтобы сделать это лучше.
Но сначала, если у вас нет времени для этого сейчас, это нормально: заставьте его работать и отправить его.