ASP.NET Core- wrong processPath in generated web.config - asp.net-core

Question

I have rather strange problem.
One of the applications we are working on stopped working after publish to Azure Web App. Everything works ok locally. After long investigation, the culprit is that the web.config generated by the build (in VSTFS) has this:
<aspNetCore processPath=".\SomeServiceName.Api " stdoutLogEnabled="false" stdoutLogFile=".\logs\stdout" />
While the correct one is:
<aspNetCore processPath=".\SomeServiceName.Api.exe" stdoutLogEnabled="false" stdoutLogFile=".\logs\stdout" />
Note the missing .exe.
The build output of the project is set to Console Application. It's ASP.NET Core app, running on full framwork. The build is run using Visual Studio Build task in VSTS, with following MSBuildArguments:
/p:DeployOnBuild=true /p:WebPublishMethod=Package /p:PackageAsSingleFile=true /p:SkipInvalidConfigurations=true /p:PackageLocation="$(build.artifactstagingdirectory)"
If I run the build on my dev machine, using MSBuild cli, with the same command line arguments, I get this:
<aspNetCore processPath="dotnet" arguments=".\SomeServiceName.Api.exe" stdoutLogEnabled="false" stdoutLogFile=".\logs\stdout" />
The project is using <Project Sdk="Microsoft.NET.Sdk.Web">.
I'm guessing I could just add web.config to the project (it's not there at all now) and have it in source control the way I want, that should fix my immidiate problem of broken deployments. But I would like to know:
The web.config genrated by build on VSTS is obviously wrong. Is that a bug in Microsoft.NET.SDK.Web thing?
I don't have access to the actuall build server. I'm guessing that the only reasonable explanation is that someone updated .net core SDK, which is why the behaviour changed. Does this make sense? Does the msbuild targets come from .NET Core SDK, or is that part of visual studio?
I'm getting different web.config on my machine. Why is that?
Update:
For anyone who stumbles here, here's the link for issue on github:
https://github.com/aspnet/websdk/issues/408
Looks like this is now fixed and will be part of some release some day (No idea what's the release cycle though).

Answer 1

I had exactly the same problem, and I solved it last week.
We had 2 ASP.Net Core projects, one showing the issue, the other didn't have the issue. So we compared the 2 .csproj files.
Turns out that in our case, all we needed to do was delete the
<PropertyGroup Condition="'$(Configuration)|$(Platform)'=='Debug|AnyCPU'">
<PlatformTarget>AnyCPU</PlatformTarget>
</PropertyGroup>
properties from the .csproj; once that was done, MSBuild correctly created the web.config, including the .exe at the end of the processPath.

Answer 2

I had exactly the same problem, and I solved it last week. We had 2 ASP.Net Core projects, one showing the issue, the other didn't have the issue.
Firstly check C:\Program Files\dotnet path, if the 'sdk' folder is not available then you need to install the ASP.NET Core SDK. If you install this package then the problem is resolved and the app is running with:
<aspNetCore processPath="dotnet" arguments=".\yourapp.dll" stdoutLogEnabled="false" stdoutLogFile=".\logs\stdout"/>

Answer 3

A few options for getting the .exe in there. Each of these methods worked for me:
Switch the build configuration from Debug (the default) to Release:
dotnet publish -c Release or msbuild argument /p:Configuration=Release
Create a web.config the way you want it in the root of your project and then tell the SDK not to touch it by adding the following to your project file:
<PropertyGroup>
<IsTransformWebConfigDisabled>true</IsTransformWebConfigDisabled>
</PropertyGroup>
Specify your target runtime as one of the win-* runtimes listed at https://learn.microsoft.com/en-us/dotnet/core/rid-catalog. Here's the code that appears to be adding the exe extension:
https://github.com/aspnet/websdk/blob/6b898ad0a39329ab5f0db281a9c1712e4303ed61/src/Publish/Microsoft.NET.Sdk.Publish.Targets/netstandard1.0/TransformTargets/Microsoft.NET.Sdk.Publish.TransformFiles.targets#L44