sdk: "Dotnet build" command should generate an error directing you to use "dotnet msbuild" if you try to specify a target to run (/t:TargetName)

Once you get used to using dotnet build to build your MSBuild projects, and you learn that you can pass MSBuild command-line parameters, it’s natural to try something like this:

dotnet build MyProj.csproj /t:MyCustomTarget

That’s what I did and then I spent like an hour banging my head against the wall trying to figure out why it was trying to build the “Build” target when “MyCustomTarget” didn’t have any dependencies on it. The CLI was passing both /t:Build and /t:MyCustomTarget to MSBuild.

Now I know that I should use dotnet msbuild instead of dotnet build for this. But why the difference? I think it will be pretty common for people who want to run custom targets to not know there is a separate msbuild command, and to run into this same issue.

I would propose that the dotnet build command should do what the dotnet msbuild command does today, which is to specify no specific targets. Then the default target will be built, which will be “Build” on normal projects. Then there won’t be any need for a separate dotnet msbuild command.

About this issue

Original URL
State: closed
Created 8 years ago
Reactions: 2
Comments: 15 (13 by maintainers)

Most upvoted comments

Related: CoreRT asks you to run dotnet build /t:LinkNative so that their additional target runs after build. Seems legit now but since a decision on how build should work will require target authors to follow, it should be decided soon to avoid breaking changes that require documentation or target changes.

dasMulli on Jan 26, 2017

Personally, I find it pretty odd that running dotnet build on my project doesn’t run the default targets that I’ve specified. Additionally, the difference between dotnet build and dotnet msbuild seems artificial to me, and not very helpful. I feel like having dotnet build be an alias for dotnet msbuild /t:build is only going to help people make mistakes, not avoid them. If a project specifies non-standard default targets, then why would I want dotnet build to run a potentially nonexistant “Build” target? Just trying to understand, maybe there’s something I’m missing.

mellinoe on Jan 26, 2017

@dsplaisted @piotrpMSFT as discussed, the solution to this is to keep the commands separate because of added value that CLI commands bring on top of MSBuild. However, to avoid this situation we should have an error that will be shown to users if they pass in a /t:<target> or /target:<target> to point them to use dotnet msbuild, which is the right path for these scenarios.

blackdwarf on Jan 18, 2017

@piotrpMSFT Yes, basically. I think dotnet build should do what dotnet msbuild does today, and then there’s probably not a need for a separate dotnet msbuild command.

dsplaisted on Nov 24, 2016