Different build behaviour for .net core web apps between local VS IDE and msbuild

From @fromorbonia on January 10, 2019 9:26

Steps to reproduce

Publishing a .NET Core web application with a FileSystem profile under VS2017 IDE creates a directory with an EXE (e.g. MyProject.exe) There is a Jenkins build server running msbuild, which correctly picks up the publish profile that was used and configured locally. Place the resulting files on a server (with IIS) and a previosuly configured Web Site, and the site should start correctly.

Expected behavior

I would expect the build server to create exactly the same set of files, as produced by the local VS2017 publish process. Specifically, in this case, it should include MyProject.exe with a matching web.config file - so that once the files being copied to the IIS server the web site starts correctly.

Actual behavior

The publish folder contains an apphost.exe and MyProject.dll, but not an EXE. The web.config points to the EXE that does not exist: <aspNetCore processPath=".\MyProject.exe"... The web site doesn’t not run on IIS.

Environment data

After some rounds of changes, I’ve ended up with the following key values (when looking at similar other posts people have asked about so have mentioned here) in the pubxml file:

    <UseAppHost>true</UseAppHost>
    <SelfContained>false</SelfContained>
    <_IsPortable>true</_IsPortable>
    <RuntimeIdentifier>win-x64</RuntimeIdentifier>

I’ve only set UseAppHost to true, because it on the local VS IDE it creates the correct combination of web.config and files so that the web site starts correctly on deployment. I don’t have a requirement to use or not use an apphost.exe file.

For the local VS2017 IDE this is: .NET Core SDK (reflecting any global.json): Version: 2.1.401 Commit: 91b1c13032

Runtime Environment: OS Name: Windows OS Version: 6.1.7601 OS Platform: Windows RID: win7-x64 Base Path: C:\Program Files\dotnet\sdk\2.1.401\

Host (useful for support): Version: 2.1.3 Commit: 124038c13e

.NET Core SDKs installed: 2.1.101 [C:\Program Files\dotnet\sdk] 2.1.202 [C:\Program Files\dotnet\sdk] 2.1.401 [C:\Program Files\dotnet\sdk]

.NET Core runtimes installed: Microsoft.AspNetCore.All 2.1.3 [C:\Program Files\dotnet\shared\Microsoft.AspNetCore.All] Microsoft.AspNetCore.App 2.1.3 [C:\Program Files\dotnet\shared\Microsoft.AspNetCore.App] Microsoft.NETCore.App 2.0.6 [C:\Program Files\dotnet\shared\Microsoft.NETCore.App] Microsoft.NETCore.App 2.0.9 [C:\Program Files\dotnet\shared\Microsoft.NETCore.App] Microsoft.NETCore.App 2.1.3 [C:\Program Files\dotnet\shared\Microsoft.NETCore.App]

For the Jenkins build server: 12:53:26 .NET Core SDK (reflecting any global.json): 12:53:26 Version: 2.1.502 12:53:26 Commit: c74ce8f29f 12:53:26 12:53:26 Runtime Environment: 12:53:26 OS Name: Windows 12:53:26 OS Version: 10.0.14393 12:53:26 OS Platform: Windows 12:53:26 RID: win10-x64 12:53:26 Base Path: C:\Program Files\dotnet\sdk\2.1.502
12:53:26 12:53:26 Host (useful for support): 12:53:26 Version: 2.1.6 12:53:26 Commit: 3f4f8eebd8 12:53:26 12:53:26 .NET Core SDKs installed: 12:53:26 2.1.401 [C:\Program Files\dotnet\sdk] 12:53:26 2.1.500 [C:\Program Files\dotnet\sdk] 12:53:26 2.1.502 [C:\Program Files\dotnet\sdk] 12:53:26 12:53:26 .NET Core runtimes installed: 12:53:26 Microsoft.AspNetCore.All 2.1.3 [C:\Program Files\dotnet\shared\Microsoft.AspNetCore.All] 12:53:26 Microsoft.AspNetCore.All 2.1.6 [C:\Program Files\dotnet\shared\Microsoft.AspNetCore.All] 12:53:26 Microsoft.AspNetCore.App 2.1.3 [C:\Program Files\dotnet\shared\Microsoft.AspNetCore.App] 12:53:26 Microsoft.AspNetCore.App 2.1.6 [C:\Program Files\dotnet\shared\Microsoft.AspNetCore.App] 12:53:26 Microsoft.NETCore.App 2.1.3 [C:\Program Files\dotnet\shared\Microsoft.NETCore.App] 12:53:26 Microsoft.NETCore.App 2.1.6 [C:\Program Files\dotnet\shared\Microsoft.NETCore.App]

Copied from original issue: aspnet/websdk#470

[fromorbonia]

@peterhuene - consistency is my main objective, so if consistency relies on publishing a profile, then that works for me. This also removes any ambiguity when changing .net core versions in the future. Thanks.

[peterhuene]

@fromorbonia I don’t believe the fix we made for 3.0 can be ported to a servicing release as it requires a coordinated change from both the .NET Core SDK and the Web SDK to make work. Combined with the fact that this isn’t a regression from previous versions and there is a simple-enough workaround, it won’t meet the servicing bar to backport to the 2.x versions.

With a “go live” preview of the 3.0 SDK coming soon, I hope you find it fixes this issue. Until then, I would use the workaround described in my comments above. As this is fixed in 3.0, I’m going to close this issue for now. Thanks again for reporting it to us.