Azure web.config для среды

Ответ 1

Решите свою проблему по-другому. Подумайте о том, что web.config всегда статичен и никогда не меняется при работе с Azure. Что такое изменение вашего ServiceConfiguration.cscfg.

Мы создали собственный поставщик конфигурации, который сначала проверяет ServiceConfiguration.cscfg, а затем возвращается к web.config, если строка настройки/подключения отсутствует. Это позволяет нам запускать серверы в IIS/WCF непосредственно во время разработки, а затем иметь разные настройки при развертывании в Azure. Есть некоторые обстоятельства, когда вам нужно использовать web.config(да, я имею в виду WCF здесь), и в этих случаях вам нужно написать код и создать соглашение, а не хранить все в web.config. У меня есть сообщение в блоге, где я показываю пример того, как я это делал при работе с WIF (Windows Identity Foundation) и Azure.

Ответ 2

Я согласен с Мосом, отличный вопрос!

Visual Studio 2010 включает решение для этого типа проблем, преобразование web.config. Если вы посмотрите на свою веб-роль, вы заметите, что она включает Web.Debug.config и Web.Release.config вместе с традиционным web.config. Эти файлы используются для преобразования web.config во время развертывания.

Канонический пример: "Мне нужны разные строки подключения к базе данных для разработки и выпуска", но это также подходит для вашей ситуации.

В Visual Team Developer Team есть отличная запись в блоге, в которой объясняется, как использовать эту функцию (не беспокойтесь о документах MSDN, я знаю, как она работает и до сих пор не понимает документы). Проверьте http://blogs.msdn.com/b/webdevtools/archive/2009/05/04/web-deployment-web-config-transformation.aspx

Ответ 3

Мне нравится этот вопрос!

Для рабочих ролей я решил эту проблему, обнаружив среду во время выполнения и запустив мое приложение в новом AppDomain с настраиваемой конфигурацией:

• bot.cloud.config
• bot.dev.config
• bot.win.config

Это невероятно эффективный!

Я хотел бы сделать то же самое с веб-проектами, потому что использование конкретной конфигурации Azure - это много проблем:

• Оба конфигуратора не находятся в одном месте, что отнимает много времени при отладке
• Вам нужно изучить новый способ написания чего-то, что может быть стандартным.
• Иногда вы задаетесь вопросом, отменилось ли приложение на web.config из-за глупой синтаксической ошибки.

Я все еще ищу правильный способ сделать это, как в этом сообщении

Ответ 4

Еще одно возможное решение - иметь два проекта CloudService, каждый из которых имеет определенный ServiceConfiguration.cscfg(dev/prod). Разработайте с помощью Dev, но разверните Prod.

Ответ 5

В настоящее время я сталкиваюсь с проблемами при использовании Web.Debug.config с преобразовать XSLT. Кажется, он не работает в Azure....

Это зависит от того, хотите ли вы заставить его работать на вашей локальной машине или внутри непрерывной интеграции.

• Для локальной машины я попытался ответить здесь: fooobar.com/info/158523/...
• Для непрерывного интегрирования это еще проще. Когда вы строите из командной строки с указанием значения свойства Configuration, ваши конфигурации будут преобразованы (независимо от того, что они делают, когда вы строите внутри VS). Поэтому правильное определение конфигураций сборки для облачного и веб-проекта даст вам правильный результат в зависимости от параметров сборки.