Kudu: Add "Build Tools for Visual Studio 2017" to Azure App Service

[niklaslundberg]

Would it be possible to add "Build Tools for Visual Studio 2017" to Azure App Service VMs?

[davidebbo]

Can you give more details on your scenario that requires that? Is it related to .NET Core, or non-Core?

We'll definitely get there, but it may take a little while.

[niklaslundberg]

The scenario involves mixed solutions with .NET Core, .NET Standard and .NET Framework projects. MSBuild 14 does not work, MSBuild on .NET Core does not work. However, MSBuild 15 works running on .NET Framework.

[davidebbo]

Yep, that does require new tools. /cc @watashiSHUN

[watashiSHUN]

Yes, we are already discussing bringing msbuild15 to Azure. the issue is that dotnet restore will not work for class lib targeting .netframework(old project system), so when we have a dotnet core web app referring to this kind of library, build process will fail.

I created a test repo

[lfoust]

I think I am hitting this same problem but I want to be sure. Also, I am wondering if there is a workaround.

So we have an asp.net core project hosted on service fabric. The solution includes our .net core project (new style .csproj) as well as some service fabric projects (.sfproj) and some regular csharp project (old style .csproj). If I do a "dotnet build" on my solution it seems to only build the dotnet core project. If I do an msbuild on my project it fails on my dotnet core project.

Somehow vs2017 can build and deploy the solution on my local machine - but on the build server it fails (just like it does using the command line on my local machine).

So is this the same scenario being discussed? Is there a work around.

[davidebbo]

@lfoust if you are using Azure Service Fabric, your case is definitely different. The discussion here only relates to Azure App Service (i.e. Web Apps).

[ctaggart]

I would love to see support for MSBuild 15! Please add Build Tools for Visual Studio 2017 to the image.

[memark]

This would be really useful. (And to be frank, I expect nothing less than the latest development tools by the same company being available.) Right now several of our migrated projects are blocked from using the simple Kudu deployment anymore.

[mookid8000]

Another reason why MSBuild 15 would be neat on App Service VMs for Kudu to use: C# 7!

[watashiSHUN]

@ctaggart @memark @mookid8000 what kind of project are you deploying?
if it's dotnet core, you can use C#7 out of the box in Azure.
if it's ASP.NET, you need to reference "Microsoft.Net.Compilers" nuget package.

Based on our tests, a mixed project (as I mentioned above)
or if you are using the C#7 syntax in a library, you will likely encounter some issues.

if you project is neither of these cases, and it still failed in Azure.
please leave a simple github repo and I will take a look

[ctaggart]

@watashiSHUN So you aren't going to make MSBuild 15 available yet? One project is a F# project that can't upgrade to dotnet core yet, but MSBuild 15 has several nice features we'd like to use.

[watashiSHUN]

@ctaggart it's in progress, because the Build Tools for Visual Studio 2017 installer has less features than VS2017's msbuild (ie, it does not have F#)

These Build Tools allow you to build native and managed MSBuild-based applications without requiring the Visual Studio IDE. There are options to install the Visual C++ compilers and libraries, MFC, ATL, and C++/CLI support.

I need to do some hacking and registry tricks, it will be out once it passed all the tests

[watashiSHUN]

I summarized some workaround for mixed project and ASP.NET web app. you can read it on stackoverflow. let me know if it still doesn't unblock you

[mookid8000]

if you are using the C#7 syntax in a library, you will likely encounter some issues

It's an old school class library targeting .NET 4.5.

@watashiSHUN I read your answer and it turned out that it worked when I added Microsoft.Net.Compilers to ALL of my projects.

Thanks 😄 👍 🎉

[jirihelmich]

Have the same issue. After updating the reference to new version of StyleCopAnalyzers 1.1.0-beta004 (with VS2017 support), the build stopped working on Kudu (and also our TeamCity CI server). I have fixed the CI server by installing VS2015 Update 3 there as suggested here: https://stackoverflow.com/questions/42536506/could-not-load-file-or-assembly-microsoft-codeanalysis-version-1-3-1-0-cultu/42596568#42596568

I have had a case with Microsoft, where the support "fixed" the issue for me by adding reference "Microsoft.Net.Compilers" NuGet package on Solution level.

But as I pointed out, it does not feel right if the solution builds locally, but not on Kudu and I have nothing extra special on my computer, just a pretty normal version of VS.

[watashiSHUN]

copied from #2376:

we actually have msbuild15.3 preview in Azure (same as VS2017), but it is not turned on by default.
you can see its location in kudu console:

D:\home>set msbuild
MSBUILD_15_DIR=D:\Program Files (x86)\MSBuild-15.3-preview\MSBuild\15.0\Bin
MSBUILD_PATH=D:\Program Files (x86)\MSBuild\14.0\Bin\MSBuild.exe

to use it you will need to have a custom deployment script with at least these two modification:

1. pass the msbuild15.3 directory to nuget (nuget4 has dependency on it):
   nuget.exe restore "{your .sln file path}" -MSBuildPath "%MSBUILD_15_DIR%"
2. use msbuild15.3 to build and publish:
   "%MSBUILD_15_DIR%\MSBuild.exe {your build arguments}"

here is an example

[tynorton]

Any update on this? I'm getting this error when using the deployment functionality built into App Services. I am using the new csproj format, and targeting netstandard2.0 on some assemblies.

D:\home\site\repository\src\xxx\xxx.csproj(1,1): error MSB4041: The default XML namespace of the project must be the MSBuild XML namespace. If the project is authored in the MSBuild 2003 format, please add xmlns="http://schemas.microsoft.com/developer/msbuild/2003" to the <Project> element. If the project has been authored in the old 1.0 or 1.2 format, please convert it to MSBuild 2003 format.

[davidebbo]

The final msbuild 15 is now deployed, and MSBUILD_15_DIR gives its path. Are you using a custom script as suggested by @watashiSHUN?

[watashiSHUN]

@tynorton Kudu does not automatically recognize the new csproj, you need to write a custom deployment script to override Kudu's project detection logic (as I described above) and the latest MSBUILD_15_DIR will points to MSBuild-15.3.409.57025

[ashmind]

Kudu does not automatically recognize the new csproj

Is it in scope for this ticket, or is there a separate one (to subscribe to)?

[davidebbo]

Probably should track separately. But first, let's convincing ourselves that it can work by trying it with a custom script (which is quite easy). Hopefully someone can give that a shot.

[watashiSHUN]

Recognizing new csproj is the first step of building, once kudu detects the project type it will go ahead and trigger the corresponding deployment script (which for now run msbiuld14) something like:

  nuget restore "%DEPLOYMENT_SOURCE%\{SolutionPath}"
  "%MSBUILD_PATH%" {MSBuildArguments}

taken from this template
we could change this for every single template (append MSBUILD_PATH to nuget restore, and set its value to latest msbuild15)

Which will gives us a break from frequent msbuild15 version update, but it has some risks

1. changing almost all templates in kuduscript, and most of our tests run with batch?
2. relying on nuget to keep consuming the msbuild path argument (which is only introduced with 4.X)...if not we have to go back to the willowAPI

@davidebbo I can start an issue tracking this, also there's going to be some DLL and registry hacks(not required to build function app, But necessary if we want to build all projects)

[harrisse]

@watashiSHUN Adding your steps to our deploy.cmd fixed errors about loading the new csproj format, but added new errors for Typescript:

D:\Program Files (x86)\MSBuild-15.3.409.57025\MSBuild\Microsoft\VisualStudio\v15.0\TypeScript\Microsoft.TypeScript.targets(77,4): error MSB4019: The imported project "D:\Program Files (x86)\Microsoft SDKs\TypeScript\build\Microsoft.TypeScript.targets" was not found. Confirm that the path in the <Import> declaration is correct, and that the file exists on disk.

[ahmelsayed]

@harrisse do you have a sample csproj that repros this?

[harrisse]

@ahmelsayed I don't have one that I can share and don't have capacity to create and test an example project right now, but the line in particular from our csproj that seems to be the source of this issue is <Import Project="$(MSBuildExtensionsPath32)\Microsoft\VisualStudio\v$(VisualStudioVersion)\TypeScript\Microsoft.TypeScript.targets" Condition="Exists('$(MSBuildExtensionsPath32)\Microsoft\VisualStudio\v$(VisualStudioVersion)\TypeScript\Microsoft.TypeScript.targets')" />

Not sure, but this could potentially be related? https://github.com/Microsoft/TypeScript/issues/16758
I'm going to try the nuget workaround from that issue and see if it helps anything.

[harrisse]

Adding the deploy.cmd fix above and the nuget workaround from the linked issue seems to have resolved everything.

[markusjohnsson]

I'm also getting TypeScript-related errors when using msbuild 15:

Command: deploy.cmd
Handling .NET Web Application deployment.
Using Msbuild from 'D:\Program Files (x86)\MSBuild-15.3.409.57025\MSBuild\15.0\Bin'.
All packages listed in packages.config are already installed.
D:\Program Files (x86)\MSBuild-15.3.409.57025\MSBuild\Microsoft\VisualStudio\v15.0\TypeScript\Microsoft.TypeScript.targets(77,4): error MSB4019: The imported project "D:\Program Files (x86)\Microsoft SDKs\TypeScript\build\Microsoft.TypeScript.targets" was not found. Confirm that the path in the <Import> declaration is correct, and that the file exists on disk. [D:\home\site\repository\Source\xyz\xyz.csproj]
Failed exitCode=1, command="D:\Program Files (x86)\MSBuild-15.3.409.57025\MSBuild\15.0\Bin\MSBuild.exe" "D:\home\site\repository\Source\xyz\xyz.csproj" /nologo /verbosity:m /t:Build /t:pipelinePreDeployCopyAllFilesToOneFolder /p:_PackageTempDir="D:\local\Temp\8d514ac2abfb8c6";AutoParameterizationWebConfigConnectionStrings=false;Configuration=Release;UseSharedCompilation=false /p:SolutionDir="D:\home\site\repository\Source\\"
An error has occurred during web site deployment.
\r\nD:\Program Files (x86)\SiteExtensions\Kudu\66.61008.3066\bin\Scripts\starter.cmd deploy.cmd

[watashiSHUN]

@markusjohnsson
can you try adding this line in your csproj?

<PropertyGroup>
    <TypeScriptToolsVersion>2.5</TypeScriptToolsVersion>
</PropertyGroup>

this seems to be a bug when msbuild is installed without Visual Studio
please give it try and let me know

[jsgoupil]

ToolsVersion="14.0" with NuGet Compilers package 2.6.0 fails with this error:
"Microsoft.Net.Compilers is only supported on MSBuild v15.0 and above"

ToolsVersion="15.0" with NuGet Compilers package 2.6.0 fails with this error:
MSBuild auto-detection: using msbuild '14.0'...

ToolsVersion="15.0" with NuGet Compilers package 2.0.1 works.

[RajaniJillaGit]

Hi Team,

Am facing the same issue. Can you help me moving in right direction ?

I tried keeping below in deploy.cmd
nuget restore "%DEPLOYMENT_SOURCE%{SolutionPath}"
"%MSBUILD_PATH%" {MSBuildArguments}
but facing error for {MSBuildArguments} Is it like something need to be replaced in the place of {MSBuildArguments}. Am new to continuous deployment using kudu. Please correct me here.

Also i tried keeping
nuget.exe restore "{your .sln file path}" -MSBuildPath "%MSBUILD_15_DIR%" but it is saying -MSBuildPath is not recognised command as the build version is getting auto detected as 14. Can you please correct me how the change of auto detection will happen as below:

Handling .NET Web Application deployment.
Using Msbuild from 'D:\Program Files (x86)\MSBuild-15.3.409.57025\MSBuild\15.0\Bin'.

Currently my deploy.cmd is as below. Please help on what could be wrong in the configuration.

@if "%SCM_TRACE_LEVEL%" NEQ "4" @echo off

:: ----------------------
:: KUDU Deployment Script
:: Version: 1.0.15
:: ----------------------

:: Prerequisites
:: -------------

:: Verify node.js installed
where node 2>nul >nul
IF %ERRORLEVEL% NEQ 0 (
  echo Missing node.js executable, please install node.js, if already installed make sure it can be reached from current environment.
  goto error
)

:: Setup
:: -----

setlocal enabledelayedexpansion

SET ARTIFACTS=%~dp0%..\artifacts

IF NOT DEFINED DEPLOYMENT_SOURCE (
  SET DEPLOYMENT_SOURCE=%~dp0%.
)

IF NOT DEFINED DEPLOYMENT_TARGET (
  SET DEPLOYMENT_TARGET=%ARTIFACTS%\wwwroot
)

IF NOT DEFINED NEXT_MANIFEST_PATH (
  SET NEXT_MANIFEST_PATH=%ARTIFACTS%\manifest

  IF NOT DEFINED PREVIOUS_MANIFEST_PATH (
    SET PREVIOUS_MANIFEST_PATH=%ARTIFACTS%\manifest
  )
)

IF NOT DEFINED KUDU_SYNC_CMD (
  :: Install kudu sync
  echo Installing Kudu Sync
  call npm install kudusync -g --silent
  IF !ERRORLEVEL! NEQ 0 goto error

  :: Locally just running "kuduSync" would also work
  SET KUDU_SYNC_CMD=%appdata%\npm\kuduSync.cmd
)
IF NOT DEFINED DEPLOYMENT_TEMP (
  SET DEPLOYMENT_TEMP=%temp%\___deployTemp%random%
  SET CLEAN_LOCAL_DEPLOYMENT_TEMP=true
)

IF DEFINED CLEAN_LOCAL_DEPLOYMENT_TEMP (
  IF EXIST "%DEPLOYMENT_TEMP%" rd /s /q "%DEPLOYMENT_TEMP%"
  mkdir "%DEPLOYMENT_TEMP%"
)

**IF DEFINED MSBUILD_PATH goto MsbuildPathDefined
SET MSBUILD_PATH=%ProgramFiles(x86)%\MSBuild\14.0\Bin\MSBuild.exe
:MsbuildPathDefined**

::::::::::::::::::::::::::::::::::::::::::::::::::::::::::::::::::::::::::::::::::::::::::::::::::::::::::::::::::::::::::::::::::
:: Deployment
:: ----------

echo Handling .NET Web Application deployment.

:: 1. Restore NuGet packages
IF /I "slnpath" NEQ "" (
  call :ExecuteCmd nuget restore "%DEPLOYMENT_SOURCE%\slnpath"
  IF !ERRORLEVEL! NEQ 0 goto error
)


:: 2. Build to the temporary path
IF /I "%IN_PLACE_DEPLOYMENT%" NEQ "1" (
  call :ExecuteCmd "%MSBUILD_PATH%" "%DEPLOYMENT_SOURCE%\csprojpath" /nologo /verbosity:m /t:Build /t:pipelinePreDeployCopyAllFilesToOneFolder /p:_PackageTempDir="%DEPLOYMENT_TEMP%";AutoParameterizationWebConfigConnectionStrings=false;Configuration=Release;UseSharedCompilation=false /p:SolutionDir="%DEPLOYMENT_SOURCE%\solnpath\\" %SCM_BUILD_ARGS%
) ELSE (
  call :ExecuteCmd "%MSBUILD_PATH%" "%DEPLOYMENT_SOURCE%csprojpath" /nologo /verbosity:m /t:Build /p:AutoParameterizationWebConfigConnectionStrings=false;Configuration=Release;UseSharedCompilation=false /p:SolutionDir="%DEPLOYMENT_SOURCE%\solnpath\\" %SCM_BUILD_ARGS%
)

IF !ERRORLEVEL! NEQ 0 goto error

:: 3. KuduSync
IF /I "%IN_PLACE_DEPLOYMENT%" NEQ "1" (;
  call :ExecuteCmd "%KUDU_SYNC_CMD%" -v 50 -f "%DEPLOYMENT_TEMP%" -t "%DEPLOYMENT_TARGET%" -n "%NEXT_MANIFEST_PATH%" -p "%PREVIOUS_MANIFEST_PATH%" -i ".git;.hg;.deployment;deploy.cmd"
  IF !ERRORLEVEL! NEQ 0 goto error
)

::::::::::::::::::::::::::::::::::::::::::::::::::::::::::::::::::::::::::::::::::::::::::::::::::::::::::::::::::::::::::::::::::
goto end

:: Execute command routine that will echo out when error
:ExecuteCmd
setlocal
set _CMD_=%*
call %_CMD_%
if "%ERRORLEVEL%" NEQ "0" echo Failed exitCode=%ERRORLEVEL%, command=%_CMD_%
exit /b %ERRORLEVEL%

:error
endlocal
echo An error has occurred during web site deployment.
call :exitSetErrorLevel
call :exitFromFunction 2>nul

:exitSetErrorLevel
exit /b 1

:exitFromFunction
()

:end
endlocal
echo Finished successfully.

[davidebbo]

@RajaniJillaGit you say you are "facing error for {MSBuildArguments}", but don't provide details. What error are you getting specifically?

[RajaniJillaGit]

Hi @davidebbo . Thanks a lot for your response. Here is the error that i was getting when using {MSBuildArguments}.

MSBuild Error MSB1001
Unknown Switch : {MSBuildArguments}.

[davidebbo]

@watashiSHUN do you know what's going on here?

[watashiSHUN]

@RajaniJillaGit what is the deploy.cmd that gives you error, the example you provided seems to be generated by kudu. At deployment time, {MSBuildArguments} will be replaced by actual arguments, and yes, the final version of deploy.cmd cannot contain {MSBuildArguments} since passing this string to msbuild does tell it what to build. It is used as a placeholder in skeleton template

[watashiSHUN]

if you are trying to use msbuild15 for your project, you need to edit on top of kudu generated deploy.cmd

1. change restore code

:: 1. Restore NuGet packages
IF /I "slnpath" NEQ "" (
  :: replace origin with
  call :ExecuteCmd nuget restore "%DEPLOYMENT_SOURCE%\slnpath" -MSBuildPath "%MSBUILD_15_DIR%"
  IF !ERRORLEVEL! NEQ 0 goto error
)

1. change build code

:: 2. Build to the temporary path
IF /I "%IN_PLACE_DEPLOYMENT%" NEQ "1" (
  :: replace origin with
  call :ExecuteCmd "%MSBUILD_15_DIR%\MSBuild.exe" "%DEPLOYMENT_SOURCE%\csprojpath" /nologo /verbosity:m /t:Build /t:pipelinePreDeployCopyAllFilesToOneFolder /p:_PackageTempDir="%DEPLOYMENT_TEMP%";AutoParameterizationWebConfigConnectionStrings=false;Configuration=Release;UseSharedCompilation=false /p:SolutionDir="%DEPLOYMENT_SOURCE%\solnpath\\" %SCM_BUILD_ARGS%
) ELSE (
  :: replace origin with
  call :ExecuteCmd "%MSBUILD_15_DIR%\MSBuild.exe" "%DEPLOYMENT_SOURCE%csprojpath" /nologo /verbosity:m /t:Build /p:AutoParameterizationWebConfigConnectionStrings=false;Configuration=Release;UseSharedCompilation=false /p:SolutionDir="%DEPLOYMENT_SOURCE%\solnpath\\" %SCM_BUILD_ARGS%
)

In my previous response you can see that I have included an example: https://github.com/projectkudu/kudu/issues/2350#issuecomment-315436296

[RajaniJillaGit]

Thanks a lot team. I kept the above code and removed the below snippet. It worked. Thanks.

IF DEFINED MSBUILD_PATH goto MsbuildPathDefined
SET MSBUILD_PATH=%ProgramFiles(x86)%\MSBuild\14.0\Bin\MSBuild.exe
:MsbuildPathDefined

[jboarman]

The instructions for the workaround are indeed simpler than I first thought ... well, except for the fact that I added the two files (.deployment and deploy.cmd) to the root of my repo and they currently _seem_ to be ignored. Any pointers on what could possibly go wrong there?

Both files are definitely in the root, mostly untouched from what is downloaded from Kudo, and don't update the deploy script located at D:\home\site\deployments\tools\deploy.cmd (which is just where I assume it should go once a build is triggered).

I've tried avoiding this whole process b/c who the heck wants to deal with deployment scripts that are likely to be brittle and not very future-proof. Is there any chance I won't need to fool around with this mess and can instead rely on auto-deploy from a GitHub push any time soon?! 😦

[watashiSHUN]

I need to take a look at your .deployment and deploy.cmd, or can you share your website name this way

[jboarman]

@watashiSHUN Thanks for your quick response. After deleting the deploy.cmd and deploymentCacheKey files from D:\home\site\deployments\tools\, I expected them to be regenerated. However, they were not, and it started using my deployment script as a result. That's either all just a coincidence or maybe that's just how it works -- I have no clue.

After getting past that issue, I'm now facing this error:

D:\Program Files (x86)\MSBuild-15.3.409.57025\MSBuild\Microsoft\NuGet\15.0\Microsoft.NuGet.targets(178,5): error : Your project.json doesn't have a runtimes section. You should add '"runtimes": { "win": { } }' to your project.json and then re-run NuGet restore.

I'm using a normal csproj file, so I'm not sure why I'm getting the above error. That error happens after calling this line in the deploy script:

D:\home\site\repository>call "D:\Program Files (x86)\MSBuild-15.3.409.57025\MSBuild\15.0\Bin\MSBuild.exe" "D:\home\site\repository\MyProject\MyProject.csproj" /nologo /verbosity:m /t:Build /t:pipelinePreDeployCopyAllFilesToOneFolder /p:_PackageTempDir="D:\local\Temp\8d5944093448291";AutoParameterizationWebConfigConnectionStrings=false;Configuration=Release;UseSharedCompilation=false /p:SolutionDir="D:\home\site\repository\.\\" /p:Configuration=Debug /p:PublishProfile=Dev

For MS support purposes: The web app instance is named something like "____-dev" and is in the same app service plan as support-locator-app.azurewebsites.net

[watashiSHUN]

After deleting the deploy.cmd and deploymentCacheKey files from D:\home\site\deployments\tools\, I expected them to be regenerated. However, they were not

once you "command = deploy.cmd" in .deployment, it basically tells kudu to not bother generating default deployment script since one is already provided by user

As for your error, it does not seem to be kudu related, I found something here: https://github.com/dotnet/cli/issues/6294#issuecomment-293335661

I assume you can build the project locally, do you know which version of msbuild you were running?

[mjozwiak-kpmg]

Hi, what is a status of adding Build Tools for Visual Studio 2017 to Azure App Service?
After updating Microsoft.Net.Compilers to latest version I had to change deployment script in order to use MSBuild 15.0.
But now I have another porblem, this time with Stylecop.Analyzers. MSBuild can not locate Code Analysis tool.

Non of these answers helped me https://stackoverflow.com/questions/42536506/could-not-load-file-or-assembly-microsoft-codeanalysis-version-1-3-1-0-cultu/42596568#42596568

This is console output:

D:\Program Files (x86)\MSBuild-15.3.409.57025\MSBuild\Microsoft\VisualStudio\v15.0\CodeAnalysis\Microsoft.CodeAnalysis.targets(292,5): error : MSBuild could not locate the Code Analysis tool at ''. If MSBuild is being run from within the "Visual Studio Command Prompt", specify the path to the Code Analysis tool by setting the FXCOPDIR environment variable. [...]
...
D:\Program Files (x86)\MSBuild-15.3.409.57025\MSBuild\Microsoft\VisualStudio\v15.0\CodeAnalysis\Microsoft.CodeAnalysis.targets(292,5): error : MSBuild could not locate the Code Analysis tool at ''. If MSBuild is being run from within the "Visual Studio Command Prompt", specify the path to the Code Analysis tool by setting the FXCOPDIR environment variable. [...]
D:\Program Files (x86)\MSBuild-15.3.409.57025\MSBuild\15.0\Bin\Microsoft.CSharp.CurrentVersion.targets(134,9): warning MSB3884: Could not find rule set file "ManagedMinimumRules.ruleset". 
...
Failed exitCode=1, command="D:\Program Files (x86)\MSBuild-15.3.409.57025\MSBuild\15.0\Bin\MSBuild.exe" "[...].csproj" /nologo /verbosity:m /t:Build /t:pipelinePreDeployCopyAllFilesToOneFolder /p:_PackageTempDir="D:\local\Temp\8d5cf891931bb1c";AutoParameterizationWebConfigConnectionStrings=false;Configuration=Release;UseSharedCompilation=false /p:SolutionDir="D:\home\site\repository\.\\"
An error has occurred during web site deployment.
\r\nD:\Program Files (x86)\SiteExtensions\Kudu\73.10510.3399\bin\Scripts\starter.cmd deploy.cmd

Is there a solution for it?

[jsgoupil]

I am still facing this issue, with another project, with no .deploy file and Microsoft.Net.Compilers of 2.8.2. .NET4.6
I fix this issue with installing the NuGet package version 2.0.1

[davidebbo]

We are deploying the change that makes it default to VS 2017 msbuild. It should complete tomorrow. In the meantime, if you'd like to try it, you can create a test site in West Central US, which has the change.

Then it'll be interesting to find out what problems may be left after this change.

[watashiSHUN]

Actually, the default msbuild15 is likely going to be from visual studio build tools

we are currently testing its impact against some broken cases (ie silver-light) I will make sure its availability comes with an official announcement (this issue will be @ ed), david was referring to some other change regarding msbuild15 path in kudu, which does not affect this case in particular

[wilsonson]

I have tried to build the latest version of "master", and deployed it the artifact with Build Tools for Visual Studio 2017 on a new standalone server. When I deploys a simple ASP.NET WAP (for testing), nuget can restore packages without issue. But looks like deployment script has hard coded the default path of msbuild.exe as "%ProgramFiles(x86)%\MSBuild\14.0\Bin\MSBuild.exe", and therefore kudu failed to build the project with Build Tools for Visual Studio 2017.

As a workaround, I need to add a customer property "MSBUILD_PATH" with the exact path of msbuild.exe in Kudu projects.

[SidShetye]

@watashiSHUN : Is Kudu abandoned? Even newly created Azure App Services seem to work with msbuild14. This ticket is open since early 2017. Meanwhile VS2017 came and went. Then VS2019 is here. C# 8.0 is here. The customer expectation is that if code compiles in VS2019, it should compile in Azure too, perhaps with a minimal amount of fiddling.

EDIT: We're using C# 8.0 compiler features, for an ASP.NET WebAPI app running on .NET 4.6.2 runtime with devs on VS2019. Kudu deploy seems hopelessly broken.

[suwatch]

Please open a new issue for VS 2019 support.

[nicholastic]

I asked this question on Stack Overflow: https://stackoverflow.com/questions/58617182/azure-deployment-error-msb4041-the-default-xml-namespace-of-the-project-must-b. To be clear, are web apps still using msbuild 14.0? It looks like my app is, even though locally I'm using VS 2019.

If Azure can now use msbuild 15.0 (can it use 16.0?), could I please have detailed instructions on how exactly to get my web app building with the equivalent of VS 2017 or VS 2019? Azure can't build the web app when the Entity Framework 6.3 package is installed, so I'm stuck using 6.2.

[nicholastic]

Is there an easy way to change the build version of an Azure website? EF 6.3.0 still doesn't work with a normal Azure web app. Upgrading packages shouldn't break stuff, and there should be an easy way (like clicking a button in the interface) to choose a later version, or better yet it should just work without configuring anything.

[suwatch]

Could you open a new issue for this? In addition, could you help us help you by scope down your repro to a simple repo that we can clone and push to repro your issue?

[nicholastic]

It might be better if you open the issue, since I don't know for sure if there's already a solution. The problem seems to be that Azure app service apps are using msbuild 14 (which is now several major versions old), and there doesn't seem to be any way to make app service apps use a later version. So upgrading packages (like EF 6.3.0) breaks the build on the server and we have to revert.

[epalm]

@nicholastic using an answer from https://stackoverflow.com/questions/55621822/how-do-you-get-kudu-to-use-msbuild-15 I set an MSBUILD_PATH environment variable to %MSBUILD_15_DIR%\msbuild.exe and that did the trick to build with msbuild 15. I dropped into the console and echo %MSBUILD_15_DIR% prints D:\Program Files (x86)\MSBuild-15.9.21.664\MSBuild\15.0\Bin