говоря, что app.configs на самом деле используются во время компиляции (в это я не верю).
ия VS, с которыми я часто работаю, состоят изодин исполняемый проект (консольное приложение, веб-приложение) имного проектов библиотеки классов на которые все ссылается исполняемый файл.
При работе с NuGet и установке пакетов часто возникаетapp.config файл, созданный для каждого проекта, обычно не содержащий ничего, кроме списка перенаправлений привязки, которые объединяют версии ссылочных сборок. Иногда есть какой-то сторонний специфичный для библиотеки контент (например, раздел конфигурации Entity Framework), но давайте пока оставим это в стороне.
Когда я собираю решение и использую двоичные файлы основного исполняемого проекта, я вижу все сборки проекта библиотеки классов в выходных данных сборки вместе с соответствующими*.config файлы (app.config файл переименовывается вAssemblyName.config когда построено).
При запуске основного исполняемого файла влияют ли какие-либо файлы конфигурации сборок библиотеки классов? Или это простоapp.config файл исполняемого файла, который оказывает влияние в этом случае? Что если в некоторых проектах библиотек классов установлены некоторые перенаправления привязки, а в основном исполняемом проекте - несколько разных перенаправлений привязки - как они объединяются, которые имеют приоритет?
Я пытался исследовать это онлайн, и из того, что я прочитал, мне кажется, чтоapp.config файлы для неисполняемых сборок бесполезны (в отношении обязательных перенаправлений). Может кто-то подтвердить это или уточнить немного по теме?
Если это так, то на самом деле нежелательно иметь этиapp.config файлы, созданные NuGet в библиотеках классов, если они содержат только перенаправления привязки? Мне кажется, что NuGet не должен создавать эти перенаправления привязки для проектов библиотеки классов, поскольку это только увеличит путаницу в отношении того, какие параметры фактически применяются.
Я нашел эти существующие вопросы переполнения стека по теме, но ихпринятые ответы на самом деле противоречивы, даже если они помечены как дубликаты друг друга.
Нужен ли файл bindingRedirect .config или все сборки в приложении?
Принятый ответ на первый вопрос упоминает, что файлы app.config фактически используются во время компиляции, что означает, что они могут иметь эффект. Источники какMSDN а такжеИсходный код MSBuild приводятся там как доказательство того, что он используется во время компиляции. К сожалению, я не достаточно опытен в MSBuild, чтобы понять, как он используется, и действительно ли это правильный аргумент.
Кто-нибудь может описать пример сценария, чтобы доказать, что app.config с перенаправлением привязки для библиотеки классов может делать все что угодно?