dotnet publish not same as publish from visual studio

[rekna1]

Describe the bug

When you publish a project using dotnet publish /p:PublishProfile=FolderProfile it doesn't behave the same as publish from Visual Studio which is very confusing for ci/cd scenario's.

Some examples are:

• If you specify a publishdir in the publish profile, dotnet publish ignores, I have to explicity specify it on the commandline with the -o parameter.

• If in my csproj contains <Target Name="RenameConfigOnPublish" AfterTargets="Publish"> it works only with dotnet publish if I also specify <IsTransformWebConfigDisabled>true</IsTransformWebConfigDisabled> in the csproj, while this is not needed from visual studio.

• If the publish profile contains <DeleteExistingFiles>true</DeleteExistingFiles> it seems to be ignored by dotnet publish, when publishing from Visual studio this runs fine. As far as I know there is even no commandline option to delete all files prior to publish

To Reproduce

see the examples in the description.

Further technical details

.NET SDK:
Version: 8.0.202
Commit: 25674bb2f4
Workload version: 8.0.200-manifests.8cf8de6d

Runtime Environment:
OS Name: Windows
OS Version: 10.0.22621
OS Platform: Windows
RID: win-x64
Base Path: C:\Program Files\dotnet\sdk\8.0.202\

.NET workloads installed:
There are no installed workloads to display.

Host:
Version: 8.0.3
Architecture: x64
Commit: 9f4b1f5d66

[rekna1]

Also dotnet publish seems not to restore correct versions of reference nuget packages, although it says
Determining projects to restore...
Restored ....
The resulting published exe referenced an older version of a nuget package.

(fyi : I have also a private nuget repository and the nuget package not updated was in this private nuget repository, I checked the configured nuget sources and it lists my private nuget repository as Enabled)

Update: apparently you have to explicitly add a list of nuget sources to the dotnet publish command to make it work:

dotnet publish --source "source1;source2"

[baronfel]

You are correct that dotnet CLI publish is not the same as VS publish. As you noted, Publish Profiles are not used the same on the command line as they are inside Visual Studio. It is possible to bring the two closer into alignment (I tried this here for example), but there are some VS-only workloads that the CLI may never support.

To investigate the differences in more detail, you could look at a binlog of both the VS publish and the CLI publish and see how they differ. Many of the differences are going to fall into one of two categories:

• CLI doesn't understand the PublishProtocol used in your Publish Profile
• CLI doesn't read and apply the properties from the Publish Protocol before invoking the build, so properties are not set in the way the publish expects, leading to different build behaviors.

[rekna1]

The problem is that this is making the development process less efficient as it could be:

I don't find it logical that:

• Multiple declarations in different places for the same outcome
• Error prone, often trial and error as it is not clear what the differences are and different locations (csproj, commandline parameters, ....)
• Currently I am talking about standard workloads : web application, wpf application, console application
• Up till now I have found for everything (after a lot off search and trial and error) ways to do the same with the commanline, so it looks to me, that in many cases it would be possible to make the dotnet publish work the same way as VS publish, except for deleting files in the publish folder , which only can be accomplished by manually deleting the publish folder.

You say the CLI doesn't understand the PublishProtocol but many example including Microsoft official documentation show that you can provide a publish profile using the dotnet command (https://learn.microsoft.com/en-us/dotnet/core/tools/dotnet-publish, dotnet publish -p:PublishProfile=FolderProfile) which gives the impression that it is supported.

I agree that it is probable more complicated than I can imagine, but you have to admit that is is not an ideal experience especially as both scenarios are common (VS for development and testing, dotnet publish for CI/CD).