dotnet publish does not respect target framework from publish profile
See original GitHub issueDescription
Running dotnet publish -p:PublishProfile=Anything.pubxml
ignores the fact that the TargetFramework
is specified within given .pubxml
file and informs you (displays error) that you must specify the framework manually.
Current behavior
Error is displayed and publish process is stopped
The ‘Publish’ target is not supported without specifying a target framework. The current project targets multiple frameworks, please specify the framework for the published application.
Expected behavior
TargetFramework
should be retrieved from the .pubxml
file.
Steps to reproduce
dotnet new console
.- In
.csproj
setTargetFrameworks
tonetcoreapp2.1;netcoreapp3.1
.
<Project Sdk="Microsoft.NET.Sdk">
<PropertyGroup>
<OutputType>Exe</OutputType>
<TargetFrameworks>netcoreapp2.1;netcoreapp3.1</TargetFrameworks>
<RootNamespace>dotnet_publish_issue</RootNamespace>
</PropertyGroup>
</Project>
- Open up with VS, create any folder publish profile for
netcoreapp2.1
. Created profile should look like this
<?xml version="1.0" encoding="utf-8"?>
<Project ToolsVersion="4.0" xmlns="http://schemas.microsoft.com/developer/msbuild/2003">
<PropertyGroup>
<PublishProtocol>FileSystem</PublishProtocol>
<Configuration>Release</Configuration>
<Platform>Any CPU</Platform>
<TargetFramework>netcoreapp2.1</TargetFramework>
<PublishDir>bin\Release\netcoreapp2.1\publish\</PublishDir>
</PropertyGroup>
</Project>
- Executing
dotnet publish -p:PublishProfile=Properties\PublishProfiles\FolderProfile.pubxml
results in error:
C:\Program Files\dotnet\sdk\3.1.100\Sdks\Microsoft.NET.Sdk\targets\Microsoft.NET.Sdk.CrossTargeting.targets(27,5): error : The 'Publish' target is not supported without specifying a target framework. The current project targets multiple frameworks, please specify the framework for the published application. [C:\dotnet publish issue\dotnet publish issue.csproj]
Executing dotnet publish -p:PublishProfile=Properties\PublishProfiles\FolderProfile.pubxml -f:netcoreapp2.1
works fine, but why does .pubxml
’s <TargetFramework>
node is ignored?
Issue Analytics
- State:
- Created 3 years ago
- Reactions:1
- Comments:8 (4 by maintainers)
Top Results From Across the Web
Azure publish profile Target Framework .NET Core 3.0 ...
1 Answer 1 ... Right click your Blazor WebAssembly App and click Edit Project File . ... The target framework will turn to...
Read more >dotnet publish command - .NET CLI
The dotnet publish command calls MSBuild, which invokes the Publish target. If the IsPublishable property is set to false for a particular ...
Read more >Keeping Content Out of the Publish Folder for WebDeploy
I've run into issues with keeping files from publishing with WebDeploy on numerous occasions. When working with large projects it's not ...
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 >Publish a .NET Application | Office File API
This article describes how to deploy a .NET application. The following deployment modes are available: Self-Contained: Creates an ...
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 FreeTop 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
Top GitHub Comments
I’m still seeing this in .NET 6
Yep, we need to do an evaluation and then trigger the Publish with the properties from the selected PublishProfile, which is exactly what VS does. I call this a ‘two-phase’ publish, and I have a draft PR for this here. I need to get feedback from the VS Publish folks on the exact set of properties that are lifted from the PublishProfile, and write tests, but I am halfway working on proposing this for 7.0.300.
The reason this two-phase approach is needed is because of MSBuild props/targets ordering - the PublishProfile evaluation is done long after certain ‘core’ properties like the RID, TFM, etc are set - and in fact many of these properties can be set by the CLI itself. When this occurs they are ‘global properties’ for the build, and as such can’t be overwritten (which is what a naieve Import of the Publish Profile would do).