Suggestion: Add custom MSBuild targets to the command resolver, i.e. `dotnet mytarget`

TLDR: dotnet mytarget could trigger dotnet msbuild /t:mytarget

Let’s say I have a custom target in my project file: <Target Name="mytarget" ...

To execute this I can run dotnet msbuild /t:mytarget which is rather verbose.

Now that MSBuild is an integral part of the dotnet CLI, why not have a command resolver that checks for custom targets? We could add this to the end of the current list of resolvers so as not to break existing resolution strategies.

This would make it possible to type dotnet mytarget instead of dotnet msbuild /t:mytarget and any arguments I pass could be forwarded to msbuild just like dotnet build does.

This would simplify tool development to just needing a NuGet package with MSBuild targets and getting dotnet mytarget for free. We’d no longer need a console app that wraps the call to dotnet msbuild. This is a pattern discussed in the extensibility docs:

However, if you want to provide a better user experience, you can combine per-project tools and custom targets. In this scenario, the per-project tool would essentially just accept whatever needed parameters and would translate that into the required dotnet msbuild invocation that would execute the target. You can see a sample of this kind of synergy on the MVP Summit 2016 Hackathon samples repo in the dotnet-packer project. – https://github.com/dotnet/docs/commit/049bc39d50f149b5ffb173f157ff6ff47182477b#diff-f3b0783a35a3fc75fe4e57558a221194R154

This could be opt-in/out perhaps by setting an attribute on the custom target(s). Especially if at some point there will be a command to list custom tools. i.e.: <Target Name="MyTool" ExtendDotNetCli="true" />

Perhaps also alias the sub command while we’re at it: <Target Name=MyTool" ExtendDotNetCliAlias="mytoolalias" /> which would map the target to dotnet mytoolalias instead of dotnet mytool.

[dasMulli]

I really like the idea, writing a cli tool that only invokes an msbuild target seems a lot of unnecessary work (and fining the right dotnet/msbuild version in the tool isn’t straightforward either). (Related: this SO question) I don’t think MSBuild allows for arbitrary attributes on <Target> elements, but maybe a simple convention could help here:

<Target Name="FancyDotNetCliVerbTarget">...</Target>

=> dotnet fancy

Additional arguments could be made available through a property like $(DotNetCliVerbArguments), maybe some “well-known” arguments (--configuration, --framework) could be parsed as well.

[dasMulli]

a target is nice, but without task is not that useful

I beg to differ on that.

Granted, getting msbuild tasks to work correctly with dependencies on core and desktop msbuild is quite complicated. If you need to distribute complex logic, you are probably better off creating a standard cli tool.

But for everything I can do purely in msbuild, creating an additional cli tool that just calls it feels like a lot of overhead.

For example, I have a PublishAll target that invokes publish for all target frameworks and runtime identifiers specified in the project. If there was a simple way to access it via dotnet publish-all vs. dotnet msbuild /t:PublishAll that would be cool. Similarly, a ci build script that publishes multiple configurations to a directory hierarchy by creating publish profiles on the fly. (though this one was built for classic web csprojs, I see no problem in doing something similar for asp.net core projects).

The added benefit is that the target is also directly available in msbuild so I can invoke it from ci scripts. Otherwise, this would have to be done via <Exec Command="dotnet foo" /> and praying that the version of dotnet this resolves to works. (there current host / resolved sdk isn’t yet available as msbuild property).