Azure web.config для каждой среды
У меня есть проект Azure (Azure 1.3) в VS2010. Есть 2 веб-ролика, один проект веб-страницы и один проект WCF. В режиме отладки я хочу, чтобы веб-проект использовал web.config для среды DEV, и при публикации web.config для PROD должен использоваться.
Каков наилучший способ сделать это?
В настоящее время у меня возникают проблемы при использовании Web.Debug.config с XSLT-преобразованием. Кажется, это не работает в Azure....
5 ответов
Решите вашу проблему по-другому. Представьте, что web.config всегда статичен и никогда не меняется при работе с Azure. Что изменится, так это ваш ServiceConfiguration.cscfg.
Мы создали нашего собственного провайдера конфигурации, который сначала проверяет ServiceConfiguration.cscfg, а затем возвращается к web.config, если строка настройки / подключения отсутствует. Это позволяет нам запускать серверы в IIS/WCF непосредственно во время разработки, а затем иметь другие параметры при развертывании в Azure. Есть некоторые обстоятельства, когда вы должны использовать web.config (да, я имею в виду WCF здесь), и в этих случаях вы должны писать код и создавать соглашения вместо хранения всего в web.config. У меня есть запись в блоге, где я показываю пример того, как я это делал, имея дело с WIF (Windows Identity Foundation) и Azure.
Я согласен с Моисеем, отличный вопрос!
Visual Studio 2010 включает решение для этого типа проблемы, преобразования web.config. Если вы посмотрите на свою веб-роль, вы заметите, что она включает в себя Web.Debug.config и Web.Release.config вместе с традиционным web.config. Эти файлы используются для преобразования файла web.config во время развертывания.
Канонический пример: "Мне нужны разные строки подключения к базе данных для разработки и выпуска", но это также подходит для вашей ситуации.
Есть отличная запись в блоге от команды разработчиков Visual Web, которая объясняет, как использовать эту функцию (не беспокойтесь о документах MSDN, я знаю, как она работает, и до сих пор не понимаю документы). Проверьте http://blogs.msdn.com/b/webdevtools/archive/2009/05/04/web-deployment-web-config-transformation.aspx
Мне нравится этот вопрос!
Для рабочих ролей я решил эту проблему, обнаружив среду во время выполнения и запустив свое "приложение" в новом домене приложений с пользовательской конфигурацией:
- bot.cloud.config
- bot.dev.config
- bot.win.config
Это невероятно эффективно!
Я хотел бы сделать то же самое с веб-проектами, потому что использование конкретной конфигурации Azure - большая проблема:
- Оба конфига не находятся в одном месте, что отнимает много времени при отладке
- Вы должны изучить новый способ написания чего-то, что должно быть стандартным
- Иногда вы будете удивляться, если приложение вернулось к web.config из-за глупой синтаксической ошибки.
Я все еще ищу правильный способ сделать это, как в этом посте
Другое возможное решение состоит в том, чтобы иметь два проекта CloudService, каждый с определенным ServiceConfiguration.cscfg(dev/prod). Разработка с использованием Dev, но развертывание Prod.
В настоящее время у меня возникают проблемы при использовании Web.Debug.config с XSLT-преобразованием. Кажется, это не работает в Azure....
Это зависит от того, хотите ли вы заставить его работать на вашем локальном компьютере или внутри непрерывной интеграции.
- Для локальной машины я попытался ответить здесь: /questions/30218548/windows-azure-virtualnoe-prilozhenie/30218558#30218558
- Для непрерывной интеграции это еще проще. Когда вы строите из командной строки, указав значение свойства Configuration, ваши настройки будут преобразованы (независимо от того, что они делают, когда вы создаете внутри VS). Таким образом, правильное указание конфигураций сборки для облачного и веб-проекта даст вам правильный вывод в зависимости от параметров сборки.