Размещение веб-роли Azure с виртуальным приложением отправляет весь проект и не обрабатывает преобразования конфигурации

Это довольно длинный вопрос, но он довольно хорошо его объясняет.

У меня есть веб-роль с корневым сайтом, который перенаправляет виртуальные приложения под этим сайтом. Мой проект отлично работает локально и почти отлично работает в облаке. Я использую новую конфигурацию сборки, чтобы заставить web.config моего сайта работать в Azure (поскольку мне нужно использовать состояние сеанса sql).

Во всяком случае, при проверке моего размещенного сайта я вижу 3 сайта в папках 0, 1, 2 соответственно. 0 представляет мой корень, и содержимое этой папки является минимальным для размещенного приложения, только моя корзина, default.aspx, пакеты и web.config. Это прекрасно работает, и я вижу, как это работает, отслеживая сеансы в моей базе данных.

Однако при проверке любой из других (идентичных) папок, представляющих виртуальные приложения, я вижу ВЕСЬ проект визуальной студии как есть. Файлы кода, преобразования web.config и т. д. Более того, преобразования на самом деле не обрабатываются. Весь проект просто свален туда.

Я использовал Visual Studio 2010 для публикации своего приложения в своей веб-роли. Я не вижу ничего очевидного в настройках, чтобы контролировать это поведение. Вот часть моего файла определения службы, если это поможет.

<WebRole name="root" vmsize="Small">
    <Sites>
      <Site name="Web">
        <VirtualApplication name="en" physicalDirectory="../../../sitefolder" />
        <VirtualApplication name="en-gb" physicalDirectory="../../../sitefolder" />
        <Bindings>
          <Binding name="Endpoint1" endpointName="Endpoint1" />
        </Bindings>
      </Site>
    </Sites>
    <Endpoints>
      <InputEndpoint name="Endpoint1" protocol="http" port="80" />
    </Endpoints>
    <Imports>
      <Import moduleName="Diagnostics" />
      <Import moduleName="RemoteAccess" />
    </Imports>
  </WebRole>
<WorkerRole name="emailer" vmsize="ExtraSmall">
    <Imports>
      <Import moduleName="Diagnostics" />
      <Import moduleName="RemoteAccess" />
      <Import moduleName="RemoteForwarder" />
    </Imports>
</WorkerRole>

Там также есть настройки конфигурации, но я их пропустил. Большое спасибо за любую помощь здесь.

РЕДАКТИРОВАТЬ 1 Вот мой файл проекта для проекта Windows Azure в моем решении после того, как были реализованы описанные здесь изменения: http://michaelcollier.wordpress.com/2013/01/14/multiple-sites-in-a-web-role/

<?xml version="1.0" encoding="utf-8"?>
<Project ToolsVersion="4.0" DefaultTargets="Build" xmlns="http://schemas.microsoft.com/developer/msbuild/2003">
*** entire content as normal and untouched manually ***
<!-- Import the target files for this project template -->
  <PropertyGroup>
    <VisualStudioVersion Condition=" '$(VisualStudioVersion)' == '' ">10.0</VisualStudioVersion>
    <CloudExtensionsDir Condition=" '$(CloudExtensionsDir)' == '' ">$(MSBuildExtensionsPath)\Microsoft\VisualStudio\v$(VisualStudioVersion)\Windows Azure Tools\2.0\</CloudExtensionsDir>
  </PropertyGroup>
  <PropertyGroup Condition=" '$(Configuration)' == 'Staging01' ">
    <OutputPath>bin\Staging01\</OutputPath>
  </PropertyGroup>
  <PropertyGroup>
    <!-- Inject the publication of "secondary" sites into the Windows Azure build/project packaging process. -->
    <CoreBuildDependsOn>
      CleanSecondarySites;
      PublishSecondarySites;
      $(CoreBuildDependsOn)
    </CoreBuildDependsOn>
    <!-- This is the directory within the web application project directory to which the project will be "published" for later packaging by the Azure project. -->
    <SecondarySitePublishDir>azure.publish\</SecondarySitePublishDir>
  </PropertyGroup>
  <!-- These SecondarySite items represent the collection of sites (other than the web application associated with the role) that need special packaging. -->
  <ItemGroup>
    <SecondarySite Include="..\bobblejob.com\bobblejob.com.csproj" />
  </ItemGroup>
  <Target Name="CleanSecondarySites">
    <RemoveDir Directories="%(SecondarySite.RootDir)%(Directory)$(SecondarySitePublishDir)" />
  </Target>
  <Target Name="PublishSecondarySites" Condition="'$(PackageForComputeEmulator)' == 'true' Or '$(IsExecutingPublishTarget)' == 'true' ">
    <MSBuild Projects="%(SecondarySite.Identity)" Targets="Build;_WPPCopyWebApplication" Properties="Configuration=$(Configuration);Platform=$(Platform);WebProjectOutputDir=$(SecondarySitePublishDir)" />
  </Target>
  <Import Project="$(CloudExtensionsDir)Microsoft.WindowsAzure.targets" />
</Project>

Чтобы сделать эту компиляцию, мне пришлось вручную создать папку «azure.publish» в моей папке bobblejob.com. Может ли ошибка заключаться в том, что вы сказали, что сборка должна выполняться только тогда, когда IsExecutingPublishTarget имеет значение true? Я хочу, чтобы это работало на моем устройстве разработки и во всех развертываниях, которые я настроил...

-- 09.11.13 - это все еще проблема. У кого-нибудь есть решение?


person Community    schedule 05.09.2013    source источник


Ответы (2)


Я думаю, вы столкнулись с проблемой, очень похожей на ситуацию, о которой я писал ранее в этом году. См. http://michaelcollier.wordpress.com/2013/01/14/multiple-sites-in-a-web-role/

По сути, когда Visual Studio упаковывает вашу веб-роль, она не «знает», что файлы, указанные атрибутом PhysicalDirectory, являются веб-проектами, и, следовательно, не выполняет никаких обычных операций сборки (компиляции, преобразования конфигурации и т. д.).

В моем сообщении в блоге описывается способ обойти это путем внедрения некоторых пользовательских действий в процесс сборки. Надеюсь, поможет!

person mcollier    schedule 05.09.2013
comment
Спасибо за ваш ответ, и да, ваша ссылка действительно отвечает на вопрос, который я задаю. Однако у меня возникли проблемы с тем, чтобы заставить его работать. Моя первая попытка была с альтернативным методом (поскольку мне не совсем удобно редактировать файл проекта вручную), однако, когда я запускал проект на своей машине, он полностью зависал. После 20 минут попыток получить контроль я в итоге жестко перезагрузил устройство! Я буду продолжать пробовать, и сообщу вам, как все идет... - person ; 06.09.2013
comment
Правильно, мне не удалось заставить это работать, используя оба метода в вашем сообщении в блоге. Однако я признаю, что никогда раньше не использовал MSBuild или какие-либо параметры конфигурации сборки, поэтому вполне возможно, что я допустил ошибку. Сначала я попробовал альтернативный метод на вашей странице. Одна из команд в разделе «Пост-сборка», по-видимому, состоит в том, чтобы снова запустить MSBuild, поэтому мой компьютер сошел с ума при ее запуске, поскольку каждый раз, когда он запускался, он порождал еще одну. Я не вижу, как это правильно в вашем сообщении. Затем я попробовал ваш первый метод и тщательно проделал каждый шаг. Я объясню больше в своем вопросе выше. - person ; 06.09.2013
comment
Обнаружена возможная причина проблемы с вашими скриптами: $(ProjectDir)..\bobblejob-azure\Sites\$(ProjectName) превращается в C:\Chaotic\Projects\bobblejob.com\bobblejob.com\..\bobblejob- azure\Sites\bobblejob.com - т.е. ваш .. не идет в обратном направлении каталог. - person ; 06.09.2013
comment
Интересно . . . Спасибо за информацию . . . Я должен изучить это. - person mcollier; 07.09.2013
comment
Я думаю, что разница между тем, что я делаю, и тем, что есть у вас, заключается в том, что вы размещаете несколько сайтов, но моя ситуация — это сайт с несколькими виртуальными приложениями под ним. Боюсь, я все еще не могу заставить это работать. Тем не менее, спасибо за ответ, я отметил его как полезный. - person ; 09.09.2013

Наконец-то у меня это работает, и это благодаря ссылке выше.

В первый раз, когда я попробовал этот метод, он не сработал. С тех пор я повторил попытку, и это сработало - перейдите по ссылке выше. Я полагаю, что между попытками обоих методов я прочитал о MSBuild, поэтому смог прочитать и понять, что происходит.

Единственное, что я сделал по-другому, это то, что я назвал свою временную папку публикации «azure_publish», а не «azure.publish». Я недостаточно читал, чтобы знать, является ли точка зарезервированным символом.

Спасибо Маколлиер. Убедитесь, что вы получаете комиссию от Microsoft за это. ;-)

person Community    schedule 11.09.2013