У меня есть большой проект WCF, который структурирован во многих подпроектах (веб-сайт в веб-роли, серверная часть, клиент WPF, клиентская библиотека и т. д.). Каждый из этих проектов имеет 3 конфигурационных файла:
- app.config — для локального тестирования
- app.release.config — с продуктивными адресами сервисов
- app.test.config - с служебными адресами тестового сервера
Эти файлы переименовываются с помощью событий после сборки в соответствии с текущей конфигурацией решения (Debug/Release/Test). Таким образом, событие после сборки в разных проектах выглядит следующим образом (за исключением того, что в проекте веб-роли это «web.config», а не «app.config»):
if not "Release"=="$(ConfigurationName)" goto :nocopyrelease
del "$(TargetPath).config"
copy "$(ProjectDir)\App.release.config" "$(TargetPath).config"
:nocopyrelease
if not "Test"=="$(ConfigurationName)" goto :nocopytest
del "$(TargetPath).config"
copy "$(ProjectDir)\App.test.config" "$(TargetPath).config"
:nocopytest
Когда я создаю эти проекты, переименование выполняется в соответствии с текущей конфигурацией сборки, и все работает так, как ожидалось, поэтому я уверен, что события сборки в порядке, как сейчас. Но как только я публикую в Azure или упаковываю «Облачную службу Azure», в которой есть веб-роль, переименование не выполняется, когда я проверяю csx-Folder или содержимое cspkg-Package.
Есть ли разумный способ использовать разные конфигурации в зависимости от выбранной конфигурации сборки при публикации в Azure? Что я сделал до сих пор, так это переименовал файлы конфигурации во всех проектах перед публикацией. Но это довольно утомительная задача и чревата ошибками. Там должен быть лучший способ...
Я думал, что заставить это работать с конфигурацией решения и событиями сборки будет самым простым способом, так как изменение конфигурации решения в раскрывающемся списке между Test/Debug/Release будет обрабатывать все переименования конфигурации, если она работает правильно.
