Ответ 1
Для развертывания веб-проекта или веб-проекта api тот факт, что нет $(TargetName) $(TargetExt).config, не имеет большого значения. Во время выполнения IIS будет использовать Web.config для определения всего, что нужно для вашей сборки.
НО!
Если вы используете веб-приложение или проект Web Api в качестве основы для тестирования *, вы можете поразить некоторые коряги. В частности, когда речь идет о переадресации связывания сборки (как в случае с чем-то в недрах MVC, который по-прежнему полагается на Newtonsoft.Json 4.5.0, когда текущая версия на момент написания составляет 7.0.0). У коллеги была аналогичная проблема с другой сборкой, в которой его тестовый проект зависел.
Теперь, когда вы запускаете свои тесты через Visual Studio (например, через Resharper), все они работают нормально. Однако, когда ваши тесты попадают на CI-сервер, и они запускаются nunit-консолью, вы увидите ошибки загрузки сборки. Не красиво. Это из-за описанного поведения, когда VS скрытно копирует файл .config в правильный вывод, а msbuild - нет. Однако вы можете обойти это с событием сборки после сборки:
copy $(ProjectDir). Web.Config $(TargetDir) $(TargetName) $(TargetExt).config
Это разрешило мои проблемы с перенаправлением. Надеюсь, это поможет кому-то другому.
- Вы можете спросить: "Зачем использовать проект веб-приложения или веб-API в качестве тестового проекта?". Проект Web * намного удобнее иметь в качестве основы для тестового проекта, который занимается сборками .net и JavaScript-тестами, поскольку JavaScript правильно распознается (подсветка синтаксиса), и есть папка Scripts, в которой есть быстрый "Добавить" - Javascript File "для себя и потомков, поэтому я предпочитаю использовать это вместо простого проекта библиотеки классов.