Repo tools

[enricosada]

We need console app (tools from now on) for lots of reason in development.

Some are helpers for dev (dotnet-watch, serve, forge, ildasm).

Some are needed by build (nunit-console, ilrepack) or for both (fake, dotnet-fable, dotnet-xunit)

While the former (dev tools) MAY not need to be versioned with codebase, the latter (for build, for both) should be to make build reproducible.

Tools should be easy to install, nice developer UX from cli, easy runnable from shell scripts, multi os and runtimes, versioned with repo (if needed), can be invoked by any third party tooling.

paket should be able to manage per repo tool.

why? after restore

• fake (or paket run fake) with the avaiabile runtime (.net or .net core)
• fable (or paket run fable) who will work in any dir

Similar: npm run <cmd>, yarn run <cmd>, bundle exec <cmd> (and binstubs), cargo <cmd>

An example of proposed is in https://github.com/enricosada/paket-repotool-testing/ ready to clone and use. it's the result of the WIP PR #2938 and will be maintained until is merged

We need two things:

• binaries (per framework runtime)
• invocation

For example. for an hello tool (who is just a .net console app)

the binaries ( see also below), we can package in a nupkg, in tools/netcoreapp/hello.dll, and tools/net45/hello.exe.
Or just from github releases

For invocation:

• create a paket-files\paket\bin directory
• put some wrapper script hello/hello.cmd who just run dotnet /path/to/tools/netcoreapp/hello.dll or mono /path/to/tools/net45/hello.exe
• and paket run hello (who just invoke that script file)

adding in a dir the wrapper script, helps because is possibile to add it to PATH, and run commands just as hello.

More info https://github.com/enricosada/paket-repotool-testing/ README

[enricosada]

Personally, i dont like to do paket run hello, i just want to have an hello in PATH.
this make it easy to override commands, and you dont care about it after install.

cons:

• or need to add that dir in PATH every time
• or global dir added to PATH and smarted wrapper scripts.

[enricosada]

/cc @Mpdreamz

[cloudRoutine]

Since the dotnet cli is adding an extension point, I don't think we should pursue this.

[cloudRoutine]

Since the dotnet cli is adding an extension point, I don't think we should pursue this part -

why? after restore
fake (or paket run fake) with the avaiabile runtime (.net or .net core)
fable (or paket run fable) who will work in any dir
Similar: npm run , yarn run , bundle exec (and binstubs), cargo

If someone needs to do all of that they should either extend their PATH or write a build script.

But I'm all for enabling paket as a dotnet cli extension tool

[enricosada]

info who can be useful later.

dotnet cli global tools

An example, dotnet cli is adding tools (sdk scooped) in v2.2 (ref https://github.com/dotnet/cli/issues/8067 )

the tools are just .net core fdd app published in the tools/netcoreapp2.1 dir of a nupkg.

ref a nuspec

<?xml version="1.0" encoding="utf-8"?>
<package xmlns="http://schemas.microsoft.com/packaging/2010/07/nuspec.xsd">
    <metadata>
        <id>global.tool.console.demo</id>
        <version>1.0.4</version>
        <description>test app</description>
        <authors>testauthor</authors>
    </metadata>
    <files>
        <file src="bin\Release\netcoreapp2.1\publish\*.*" target="tools\netcoreapp2.1\" /> 
        <file src="DotnetToolsConfig.xml" target="tools\DotnetToolsConfig.xml" /> 
    </files>
</package>

and an xmlfile to read the entry points, so commands can be renamed and multiple

<?xml version="1.0" encoding="utf-8" ?>
<DotNetCliTool>
  <Commands>
    <Command Name="demo" EntryPoint="consoledemo.dll" Runner="dotnet" />
  </Commands>
</DotNetCliTool>

[baronfel]

I saw this today and thought it might be relevant to the discussion: https://github.com/tonerdo/dotget