dotnet publish ignoring build configuration in pubxml
See original GitHub issueI have a Windows x64.pubxml
:
<?xml version="1.0" encoding="utf-8"?>
<!--
https://go.microsoft.com/fwlink/?LinkID=208121.
-->
<Project ToolsVersion="4.0" xmlns="http://schemas.microsoft.com/developer/msbuild/2003">
<PropertyGroup>
<Configuration>Release</Configuration>
<Platform>x64</Platform>
<PublishDir>artifact\</PublishDir>
<PublishProtocol>FileSystem</PublishProtocol>
<SelfContained>false</SelfContained>
<PublishReadyToRun>true</PublishReadyToRun>
<PublishReadyToRunShowWarnings>true</PublishReadyToRunShowWarnings>
<PublishSingleFile>true</PublishSingleFile>
</PropertyGroup>
</Project>
When I run dotnet publish -p:PublishProfile="Windows x64"
, I get:
ProjectA -> C:\ProjectA\bin\Debug\net5.0-windows\win-x64\ProjectA.dll
^^^ !!!
When I publish the project using Visual Studio:
2>------ Build started: Project: ProjectA, Configuration: Release x64 ------
2>ProjectA -> C:\ProjectA\bin\x64\Release\net5.0-windows\win-x64\ProjectA.dll
^^^ !!!
Is this intended?
Issue Analytics
- State:
- Created 2 years ago
- Reactions:4
- Comments:12 (3 by maintainers)
Top Results From Across the Web
dotnet publish profile ignores pubxml file
You need the use following command: dotnet build -c Release /p:DeployOnBuild=true /p:PublishProfile=FolderProfile. It's build , not publish ...
Read more >dotnet publish command - .NET CLI
dotnet publish - Publishes the application and its dependencies to a folder ... Forces the command to ignore any persistent build servers.
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 >Publish with Msbuild - Developer Community
It seems that msbuild just ignore “PublishProfile” parameter, ... If you have all the required settings in publish profile you can pass the ......
Read more >.NET SDK Support
Ignores project-to-project references and only restores the root project. noIncremental : boolean (optional). Marks the build as unsafe for incremental build.
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
We now know why this is - VS Publish operates in two phases while CLI publish operates in a single pass.
VS Publish first evaluates the project to discover which Publish Profile (if any) to use to apply to the publish. Then it applies specific properties (like Configuration, RuntimeIdentifier, etc) to the subsequent Publish operation as Global Properties. Note that other properties in the selected Publish Profile do apply, they are just imported later in the build.
CLI publish just goes straight through in a single pass, and as a result by the time the Publish Profile is imported, critical properties like Configuration and RuntimeIdentifier have already been ‘fixed’.
We’d need to perform this same two-phase logic in Publish to solve this problem. I’ve got a draft PR that I’ve used as a discussion point with @vijayrkn and @AngelosP, and we’d like to do this and a bit more unification work around Web and non-Web projects’ publish behaviors in the near term, perhaps for the 7.0.3xx cycle. That is still up for a bit of discussion though.
@sfoslund is there any update on this issue? I am using the syntax described here:
https://docs.microsoft.com/en-us/dotnet/core/tools/dotnet-publish
But neither the PublishProfile nor PublishProfileFullPath properties do anything at all. In fact, I can supply a non-existent profile name or path and it produces no errors or warnings, just goes about its default build. Clearly these properties are just being ignored. I’m using VS2019 and dotnet SDK 6.0.