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