Incorrect publish output for netcoreapp1.1 on linux-x64 targets
See original GitHub issueRepro steps
- Install preview2 SDK
dotnet new console
- change TFM to netcoreapp1.1
dotnet restore
dotnet publish -r linux-x64 -c Release -o out
Expected behavior: Either this works and the output has the required runtime assets (host, System.Private.CoreLib.dll), or this is not a supported scenario, and I get an error message.
Actual behavior: Publish seems to succeed, but the published app contains no host or System.Private.CoreLib.dll. If I understand correctly, the linux-x64 rid isn’t supported for netcoreapp1.1 targets, so the SDK should detect this and emit an error message.
Issue Analytics
- State:
- Created 6 years ago
- Comments:12 (12 by maintainers)
Top Results From Across the Web
Ask Question
Visual Studio's publish was doing a full restore/build with its publish, and the publish profile had the <RuntimeIdentifier> set. I was doing ...
Read more >dotnet publish won't publish self contained exe without a ...
I'm having the same problem. Running dotnet publish --configuration Release --runtime linux-x64 on the solution gives error NETSDK1031: It is ...
Read more >Visual Studio publish profiles (.pubxml) for ASP.NET Core ...
Learn how to create publish profiles in Visual Studio and use them for managing ASP.NET Core app deployments to various targets.
Read more >Dotnet build linux. The answer you're looking for is basically
Sdk"> <PropertyGroup> … dotnet publish /p:target=package ... 1. peace When I deploy to Linux, I publish the application on Windows and copy the...
Read more >Unable to publish using target framework netcore3.1 and ...
I have desktop WPF app written in C# and using NetCore3.1. When I try to publish it to a folder, using target runtime...
Read more >
Top Related Medium Post
No results found
Top Related StackOverflow Question
No results found
Troubleshoot Live Code
Lightrun enables developers to add logs, metrics and snapshots to live code - no restarts or redeploys required.
Start Free
Top Related Reddit Thread
No results found
Top Related Hackernoon Post
No results found
Top Related Tweet
No results found
Top Related Dev.to Post
No results found
Top Related Hashnode Post
No results found
I am going to close this issue as I believe the checks we have in place and the remaining life time for 1.x are enough.
Do we think it is worth refining the check for 1.x or can we say that flagging all invalid RIDs for 2.x+ and most for 1.x+ is good enough?
Changing milestone because it was chosen based on an incorrect assumption that it would be fixed for free with #1857.