Не удается развернуть предварительно скомпилированный, объединенный webapp в Azure

Question

Я пытаюсь развернуть веб-приложение ASP.NET для Azure. Это гибридные веб-формы, MVC и WebAPI, и есть TON из файлов aspx/ascx, так что их действительно нужно предварительно скомпилировать, или каждое развертывание покажет сайт вялым на некоторое время.

Я пытаюсь развернуть через интеграцию SCM с GitHub через kudu, с предварительно скомпилированными видами, все они объединены с одной сборкой.

Обратите внимание, что:

• Deploy отлично работает с отключенной прекомпиляцией.
• Deploy прекрасно работает с Visual Studio
• Сборка работает нормально, если я копирую команду msbuild из журнала Azure, заменяю соответствующие пути и запускаю ее локально на моей машине с Windows 8.1.

Я настроил параметры Advanced PreCompile как:

• Не допускать предкомпилированный сайт, чтобы быть udpatable
• Не испускает отладочную информацию
• Объединить все страницы и выходы в одной сборке = AppViews.dll

Вот .deployment файл для Azure

[config] 
project = WebSite/WebSite.csproj 
SCM_BUILD_ARGS=/p:Configuration=Release;PublishProfile=azure-prod /v:n 

Вы заметили, я посылаю многословие /v к «нормальным» для дополнительной диагностической информации.

Вот информация я к хвосту журнала развертывания:

AspNetPreCompile: 
    D:\Windows\Microsoft.NET\Framework\v4.0.30319\aspnet_compiler.exe -v \ -p D:\home\site\repository\WebSite\obj\Release\AspnetCompileMerge\Source -c D:\home\site\repository\WebSite\obj\Release\AspnetCompileMerge\TempBuildDir 
GenerateAssemblyInfoFromExistingAssembleInfo: 
    Creating directory "obj\Release\AssemblyInfo". 
    D:\Windows\Microsoft.NET\Framework\v4.0.30319\Csc.exe /out:obj\Release\AssemblyInfo\AssemblyInfo.dll /target:library Properties\AssemblyInfo.cs 
AspNetMerge: 
    Running aspnet_merge.exe. 
    D:\Program Files (x86)\Microsoft SDKs\Windows\v8.0A\bin\NETFX 4.0 Tools\aspnet_merge.exe D:\home\site\repository\WebSite\obj\Release\AspnetCompileMerge\TempBuildDir -w AppViews.dll -copyattrs obj\Release\AssemblyInfo\AssemblyInfo.dll -a 
aspnet_merge : error 1003: The directory 'D:\home\site\repository\WebSite\obj\Release\AspnetCompileMerge\TempBuildDir' does not exist. [D:\home\site\repository\WebSite\WebSite.csproj] 
Done Building Project "D:\home\site\repository\WebSite\WebSite.csproj" (Build;pipelinePreDeployCopyAllFilesToOneFolder target(s)) -- FAILED. 

Build FAILED. 

Похоже работает aspnet_compiler.exe, но не делать то, что он должен, поэтому каталог TempBuildDir (предполагается, для вывода компилятора) не существует во времени для цели AspNetMerge. Сравните это с моей системой, где эта директория действительно существует, содержащую маркер aspx/ascx/etc. файлы, статический контент, файл PrecompiledApp.config и целый беспорядок в каталоге bin.

aspnet_compiler.exe имеет -errorstack флаг, но это мне не ясно, как я мог бы получить MSBuild, чтобы добавить этот раз с помощью файла .deployment, или даже если это приложение действительно даже бросает ошибку.

Я мог бы просто развернуть через Visual Studio, но я бы действительно хотел бы воспользоваться интеграцией SCM, чтобы я мог просто нажать на мою ветку prod и отпустить ее. Какие-либо предложения?

Answer 1

Примечание: This GitHub issue on projectkudu будет в конечном итоге сделать это решение устаревшим, но тем временем, этот вопрос подается в качестве Отставание, и это работает прямо сейчас.

Благодарим вас, Дэвид Эббо. С помощью этой информации я смог загрузить мою сборку для работы на короткий срок.

Сначала я загрузил aspnet_compiler.exe из экземпляра Azure с помощью диагностической консоли, доступной по адресу https://{WEBSITE_NAME}.scm.azurewebsites.net/DebugConsole, и добавил ее в свой собственный репозиторий. Таким образом, нет никаких сомнений в различиях между 32/64-битными и т. Д. Я переименовал его в azure_aspnet_compiler.exe в моем репозитории.

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

public class AzureAspNetCompiler : Microsoft.Build.Tasks.AspNetCompiler 
{ 
    private string _toolName = "aspnet_compiler.exe"; 

    protected override string ToolName 
    { 
     get { return _toolName; } 
    } 

    public string CustomToolName // Because ToolName cannot have a setter 
    { 
     get { return _toolName; } 
     set { _toolName = value; } 
    } 
} 

Далее мне нужно заменить AspNetPreCompile задачу MSBuild, но я не мог понять, как сделать это непосредственно. Но эта задача не была , делая что угодно, так почему бы просто не запустить сразу после нее?

Я добавил это в начало моего файла Website.csproj, чтобы импортировать DLL, содержащую класс AzureAspNetCompiler. Обратите внимание, что путь относится к файлу Website.csproj, который я редактирую.

<UsingTask TaskName="AzureBuildTargets.AzureAspNetCompiler" 
      AssemblyFile="..\DeploymentTools\AzureBuildTargets.dll" /> 

Затем я добавил это прямо под ним, который в основном крадет целевое определение MSBuild из AspNetPreCompile из C:\Program Files (x86)\MSBuild\Microsoft\VisualStudio\v11.0\Web\Transform\Microsoft.Web.Publishing.AspNetCompileMerge.targets, с некоторыми из собственности заходящей вещей вблизи верхней части его опущен (поскольку исходная задача будет делать для нас в любом случае.) Просто обратите внимание на значения ToolPath и CustomToolName в нижней части (переименованного) элемента AzureAspNetCompiler.

<PropertyGroup> 
     <!--Relative to solution root apparently--> 
     <LocalRepoDeploymentTools>.\DeploymentTools</LocalRepoDeploymentTools> 
     <AzureAspnetCompilerPath>$([System.IO.Path]::GetFullPath($(LocalRepoDeploymentTools)))</AzureAspnetCompilerPath> 
</PropertyGroup> 

<Target Name="NoReallyAspNetPreCompile" AfterTargets="AspNetPreCompile"> 

<AzureAspNetCompiler 
    PhysicalPath="$(_PreAspnetCompileMergeSingleTargetFolderFullPath)" 
    TargetPath="$(_PostAspnetCompileMergeSingleTargetFolderFullPath)" 
    VirtualPath="$(_AspNetCompilerVirtualPath)" 
    Force="$(_AspNetCompilerForce)" 
    Debug="$(DebugSymbols)" 
    Updateable="$(EnableUpdateable)" 
    KeyFile="$(_AspNetCompileMergeKeyFile)" 
    KeyContainer="$(_AspNetCompileMergeKeyContainer)" 
    DelaySign="$(DelaySign)" 
    AllowPartiallyTrustedCallers="$(AllowPartiallyTrustedCallers)" 
    FixedNames="$(_AspNetCompilerFixedNames)" 
    Clean="$(Clean)" 
    MetabasePath="$(_AspNetCompilerMetabasePath)" 
    ToolPath="$(AzureAspnetCompilerPath)" 
    CustomToolName="azure_aspnet_compiler.exe" 
    /> 

<!-- 
    Removing APP_DATA is done here so that the output groups reflect the fact that App_data is 
    not present 
    --> 
<RemoveDir Condition="'$(DeleteAppDataFolder)' == 'true' And Exists('$(_PostAspnetCompileMergeSingleTargetFolderFullPath)\App_Data')" 
      Directories="$(_PostAspnetCompileMergeSingleTargetFolderFullPath)\App_Data" /> 


<CollectFilesinFolder Condition="'$(UseMerge)' != 'true'" 
    RootPath="$(_PostAspnetCompileMergeSingleTargetFolderFullPath)" > 
    <Output TaskParameter="Result" ItemName="_AspnetCompileMergePrecompiledOutputNoMetadata" /> 
</CollectFilesinFolder> 

<ItemGroup Condition="'$(UseMerge)' != 'true'"> 
    <FileWrites Include="$(_PostAspnetCompileMergeSingleTargetFolderFullPath)\**"/> 
</ItemGroup> 

При этом на месте, все работает, как я бы ожидать, что она.

Answer 2

Я ответил на https://github.com/projectkudu/kudu/issues/1341, но копируя мой ответ здесь, в случае кто-то приземляется здесь ...

Путь назад, мы обнаружили, что aspnet_compiler.exe не работает в Azure сайты из-за того, как он имел дело с профилем папка. Мы сделали изменения в то время, когда это было немного взломать, но заставили нас идти: мы превратили его в no-op, указав HKEY_LOCAL_MACHINE\SOFTWARE\Microsoft\Windows NT\CurrentVersion\Image File Execution Options\aspnet_compiler.exe на наш собственный манекен exe (D:\Program Files (x86)\aspnet_compiler\KuduAspNetCompiler.exe).

Но, попробовав это сейчас, похоже, что он работает правильно сегодня, вероятно, благодаря улучшениям в среде веб-сайтов Azure Websites. Поэтому мы попытаемся избавиться от этого взлома и выполнить полный пробный проход, чтобы убедиться, что он не вызывает серьезных регрессий. Если все будет хорошо, мы можем получить это в производство, что должно позволить эти сценарии.

В краткосрочной перспективе, вы можете быть в состоянии работать вокруг этого, когда Ваш скрипт сборки:

• копию aspnet_compiler.exe из D:\Windows\Microsoft.NET\Framework\v4.0.30319 в свои собственные файлы сайта, но под другим именем (например, aspnet_compiler2.exe)
• убедить MSBuild использовать, что один