Как указать файлы при публикации проекта веб-роли в Azure в VS 2010

Неа. Это невозможно с облачными сервисами. Это означает, что если вы измените файл web.config, вам придется заново развернуть всю роль.

Вот почему может быть уместно взглянуть на файл .cscfg — файл конфигурации облачной службы. Так как ничего там можно менять на лету (пока ваша роль запущена). Это, конечно, добавит некоторые начальные накладные расходы, так как вам придется изменить (если они используются где-либо) все ссылки на строку подключения вида <%$ ConnectionStrings:MyNorthwind%>. Но как только вы измените все параметры, связанные с конфигурацией, на чтение из независимого от платформы источника (будь то web.config или конфигурация облачной службы или даже хранилище таблиц Azure), у вас появятся очень гибкие варианты развертывания приложений. Единственное, что пока нельзя изменить с помощью конфигурации службы, — это раздел system.serviceModel файла web.config. Поскольку автоматическая проводка WCF в значительной степени зависит от него. Это только в том случае, если вы используете службы WCF. Но даже службы WCF можно динамически настроить.

ОБНОВЛЕНИЕ (после комментария)

Вы должны выполнить повторное развертывание, потому что это общедоступное облако, предлагающее платформу как услугу. Это включает в себя автоматическое «лечение» аппаратных сбоев, исправления/обновления ОС, обновления среды выполнения (.net), неограниченную масштабируемость. Материал PaaS не имеет состояния. Без сохранения состояния означает, что никакое состояние не сохраняется в процессах восстановления/перезапуска/сбоя системы/масштабирования/масштабирования. То, что вы подготавливаете для системы (файлы .cspkg и .cscfg), используется в качестве «базового образа» для формирования облачной службы, когда что-то происходит (начальное развертывание, развертывание для восстановления и т. д.).

Я лично не считаю перераспределение таким трудоемким. Возможно, я не сталкивался с достаточно большим развертыванием. Но в качестве наилучшей практики я загружаю свои CSPKG/CSCFG в контейнер хранилища BLOB-объектов, а затем развертываю/обновляю оттуда. Если мне нужно «повторно развернуть», я просто выполняю «Автоматическое обновление», а платформа Azure Fabric (это та интеллектуальная штука, которая гарантирует, что мой сервис работает и работает) позаботится обо всем остальном. Остальное — удаление экземпляров из балансировщика нагрузки, обновление моего пакета, перемещение экземпляров обратно в ротацию балансировщика нагрузки и т. д. для каждого домена обновления.

К сожалению, azure не позволяет обновлять пакет файл за файлом. Весь пакет должен быть перераспределен. Это настоящая боль при наличии пакетов большого размера. Загрузка моего решения обычно занимает около 45 минут.

Я предлагаю создать виртуальную машину на Azure и разместить там свой веб-сайт. Не забудьте открыть http-порт 80 в качестве конечной точки, и если вы планируете иметь машины с балансировкой нагрузки, файлы должны быть реплицированы на всех серверах. Виртуальные машины имеют состояние, а не без него (веб-роли vms), поэтому ваши настройки и данные будут сохранены.