Edit: after spending more than 60 hours on trying to deploy a .NET core on Azure. I have given up. This post will not take you all he way there. Also, they have changed the process with Visual Studio 2017 RC and there are still known issue as of December 11, 2017. As of that date, I am unable to deploy an application on Azure with .NET Core. I have fallen back on Web API 2 and ASP.Net MVC 4.
Have you tried to use the latest technology recently? If so, you are most likely dogfooding everything for the big companies. I have decided to try deploying my .NET Core application to Azure. My setup is not that unusual:
- Multiple projects in the same GIT repository
- .NET Core with Framework .NET 4.6
- One Common Class Library .csproj with Framework .NET 4.6
- TypeScript 2.*
- Angular 2.2
Have a look at how my journey started. I will show the error messages I get, maybe search engines can pick it up and hopefully can help you out if you faced the same errors.
It’s important to notice that the project works great on my computer… The nightmare starts when you try to deploy on Azure.
Deploying without Mentioning the Correct Solution
You will get your first error that will look like this:
Unable to determine which solution file to build. D:\home\site\repository\path\solution1.sln, D:\home\site\repository\path\solution2.sln
Quite legitimate, I’m not holding Azure accountable for this one.
Deploying on Azure with the “Project” Application Setting as .xproj
This is (was?) the recommended way to deploy a solution that might have multiple projects. You had to point to the exact .csproj. So let’s try to point to the exact .xproj
You get this error:
The specified project 'D:\home\site\repository\path\project\project.xproj' is not valid. It needs to point to either a csproj/vbproj file or to a directory.
Deploying on Azure with “Project” Application Setting as Folder
Uh-oh, you are supposed to point to the folder where the .xproj is. This will work great, but if you are using a csproj dependency, you might face this bug NuGet/Home#2865.
You will get this error:
Unable to resolve 'Project' for '.NETFramework,Version=v4.6'
Fallback with Manual deploy.cmd; Problem with azure-cli
If you follow some of the links in GitHub, you will find Scott Hanselman’s blog post saying the tooling is not fully ready and so we should fallback to msbuild instead.
OK, I’m up for the task, so let’s create the deploy.cmd from the Azure CLI. You can follow KUDU online tutorial to create this file. However, it is worth mentioning that as of today, you will get blocked and will not find this “azure site” command.
This is because the command line is not in the correct mode. They changed the default and you will need to change it to ASM. See Azure/azure-xplat-cli#3245.
Once you have created your deploy.cmd, the most important code is here:
:: 1. Restore nuget packages
call :ExecuteCmd nuget.exe restore "%DEPLOYMENT_SOURCE%\path\to\solution.sln" -packagesavemode nuspec
IF !ERRORLEVEL! NEQ 0 goto error:: 2. Build
call :ExecuteCmd "%MSBUILD_PATH%" "%DEPLOYMENT_SOURCE%\path\to\solution.sln" /nologo /verbosity:m /p:AutoParameterizationWebConfigConnectionStrings=false;Configuration=Release;UseSharedCompilation=false %SCM_BUILD_ARGS%
IF !ERRORLEVEL! NEQ 0 goto error:: 3. Publish
call :ExecuteCmd "%MSBUILD_PATH%" "%DEPLOYMENT_SOURCE%\path\to\project\project.xproj" /nologo /verbosity:m /t:GatherAllFilesToPublish /p:AutoParameterizationWebConfigConnectionStrings=false;Configuration=Release;UseSharedCompilation=false;PublishOutputPathNoTrailingSlash="%DEPLOYMENT_TEMP%" %SCM_BUILD_ARGS%
IF !ERRORLEVEL! NEQ 0 goto error
Incorrect Version of NuGet
If you are using the deployment script, the nuget.exe should be the latest. If you ever checked in nuget.exe as part as your build, verify that you have the latest. I had an old version which will cause trouble when it’s time to build.
error : The 'Microsoft.NETCore.Platforms 1.1.0' package requires NuGet client version '2.12' or above, but the current NuGet version is '2.8.60717.93'
Multiple Assemblies with Equivalent Identity
What is this error? Seriously!? I don’t face this problem on my computer, but Azure is not happy. I was lucky — some of my projects were referencing dead references. I simply removed them.
CSC : error CS1703: Multiple assemblies with equivalent identity have been imported: 'D:\home\site\repository\my\packages\System.Xml.ReaderWriter.4.3.0\lib\net46\System.Xml.ReaderWriter.dll' and 'D:\Program Files (x86)\Reference Assemblies\Microsoft\Framework\.NETFramework\v4.6\Facades\System.Xml.ReaderWriter.dll'. Remove one of the duplicate references. [D:\home\site\repository\path\csproj\project.csproj]
Incorrect Version of TypeScript
After fixing the build/linker error, I am now getting a TypeScript issue:
VSTSC : error TS5023: Build: Unknown compiler option 'typeRoots'.
Apparently, Azure is not using the latest version of TypeScript. They must be using 1.8 because this “typeRoots” is a valid 2.0 TypeScript tsconfig.
Add the following in your .xproj to force the version:
<TypeScriptToolsVersion>2.0.10</TypeScriptToolsVersion>
It’s Building Now, but NPM Didn’t Install the Dependencies
Plenty of TypeScript errors not finding the correct dependencies for @angular. NPM runs… let’s run it before we build in deploy.cmd.
After searching online how to install in another folder, you will find the most common answer on StackOverflow to use –prefix.
If you do so, you will end up with plenty of .cmd and sh files in the folder then will crash later. CD in the right folder then run npm install.
:: 2.0 NPM Install
cd "%DEPLOYMENT_SOURCE%\path\project"
call :ExecuteCmd npm install
cd "%DEPLOYMENT_SOURCE%"
NPM/Node is Not the Correct Version
Azure defaults to an outdated version. You need to update NPM and/or Node. You can see which version is running in the log with this line (if you get a warning from a package…).
npm WARN engine angular2-cookie@1.2.5: wanted: {"node":">=5.0.0"} (current: {"node":"4.4.7","npm":"2.15.8"})
To update, add the Application Settings:
- WEBSITE_NODE_DEFAULT_VERSION : 4.4.7
- WEBSITE_NPM_DEFAULT_VERSION : 3.10.3
Still Not Building?
Hold on… It’s building just fine on my machine! But on Azure it still fails with plenty of TypeScript errors… Why is that? That is STRANGE! Looking at the log from my machine I see the following:
C:\Program Files\dotnet\dotnet.exe build "D:\git\clients\path\project" --configuration Release --no-dependencies
Why is this being called — seriously? I have literally no clue why this is happening. But since it works, why not do the same thing on Azure… Let’s replace the MSBUILD ::2 from the deploy.cmd with this line:
call :ExecuteCmd dotnet build "%DEPLOYMENT_SOURCE%\path\project" --configuration Release --no-dependencies
Project File Does Not Exist?
Dotnet is complaining with the following error:
MSBUILD : error MSB1009: Project file does not exist.
You cannot build with the latest dotnet preview3. If you go in the xproj folder and compile, you will get the following error:
D:\home\site\repository\path\project\project.xproj(8,3): error MSB4019: The imported project "D:\Program Files (x86)\dotnet\sdk\1.0.0-preview3-004056\Extensions\Microsoft\VisualStudio\v14.0\DotNet\Microsoft.DotNet.Props" was not found. Confirm that the path in the <Import> declaration is correct, and that the file exists on disk.
Now let’s compare the dotnet I have on my machine by running “dotnet –info”.
Product Information:
Version: 1.0.0-preview2-1-003155
Searching more and more, preview3 is not a valid dotnet build for compiling web apps with project.json. To fix it, you need a global.json at the complete root of your repository. Where deploy.cmd is:
{
"sdk": {
"version": "1.0.0-preview2.1-003155"
}
}
It Compiles! …But Does Not Publish
We are almost there… Now the compilation worked… But the publishing failed with:
D:\Program Files (x86)\MSBuild\Microsoft\VisualStudio\v14.0\DotNet\Microsoft.DotNet.Publishing.targets(149,;5): error : events.js:141 [D:\home\site\repository\path\project\project.xproj]
Replace the :: 3 Publish section with:
cd "%DEPLOYMENT_SOURCE%\path\project
call :ExecuteCmd dotnet publish -c Release -o "%DEPLOYMENT_TEMP%"
IF !ERRORLEVEL! NEQ 0 goto error
cd "%DEPLOYMENT_SOURCE%"
Same trick here: I did not put the path after the publish keyword.
Thread was Being Aborted?
Getting that error on Azure? Your deployment got stuck randomly… Redeploy.
Let’s Compile on a New Machine
EDIT: This is actually a problem if you are using NuGet 3.4. Azure is shipping with NuGet 3.5 and you shouldn’t hit this problem.
I hope that all these compilation tricks did not leave any remnant objects as the machine tried to compile multiple times. This would make it complicated to deploy. I ran this same deployment on a new machine, and received an error:
Object reference not set to an instance of an object.
D:\Program Files (x86)\dotnet\dotnet.exe compile-csc @D:\home\site\repository\path\project\obj\Release\net46\dotnet-compile.rsp returned Exit Code 1
Are you serious Azure? Someone has been experiencing the same thing, reported at dotnet/cli#4085. It seems to be some data corruption.
I have noticed that the nuget packages are missing netcoreapp1.0 in “microsoft.aspnetcore.server.iisintegration.tools”
Run the nuget restore on the xproj directly
nuget restore D:\home\site\repository\path\project\project.xproj -packagesavemode nuspec
This should be necessary only once per build machine. Redeploy.
File is Missing
error CS0006: Metadata file 'D:\home\site\repository\path\project\csproj\bin\Release\project.dll' could not be found
It seems that the csproj didn’t get compiled. Let’s add this line in the :: 2. Build, before the dotnet build.
call :ExecuteCmd "%MSBUILD_PATH%" "%DEPLOYMENT_SOURCE%\path\to\csproj\project.csproj" /nologo /verbosity:m /p:AutoParameterizationWebConfigConnectionStrings=false;Configuration=Release;UseSharedCompilation=false %SCM_BUILD_ARGS%
Conclusion
I spent a good 25h to figure this out. Then I decided to write this blog post to help people out, and hopefully let Microsoft developers/PMs know about this.
It does not make sense to make this deployment so complicated.
Web Architect Consultant - Passionate about web projects! Expert in barcodes, automation, and JavaScript