Join GitHub today
GitHub is home to over 28 million developers working together to host and review code, manage projects, and build software together.Sign up
.NET Core paket and dotnet/sdk #2875
Paket depends now on .NET framework (win) and mono (unix/mac).
This is really good because the normal paket.exe console app can run xplat if mono/.net is installed.
For some scenario, like .net core development (or fable) with new dotnet/sdk (new csproj/fsproj), the mono/.net shouldnt be needed.
To remove that deps of paket in these scenario there are some points to address:
Atm ihmo boostrapping and auto-updates are the real issue
notes about console deployment options on .net core
notes about paket, dotnet/sdk, .net core
paket is a strange tool, because atm for restore process, need to be there BEFORE the restore.
But lots of challenges are shared with normal tools in .net ecosystem
There is no builtin
How now .net sdk support external tools? or custom execute code xplat.
Other package manager expect the dev sdk installed, and use that to boostrap:
My current ideas, not in preference order.
support tools at repo level natively in
Why: paket deps doesnt change a lot. paket does.
like now, using native app (SCD) but smarter update mechanism
Why: support and enhance .net cli tools. use that support for paket itself.
Add support of repo level tools to paket and .net cli tools. Use a built paket native (SCD) to boostrap paket (replace previous paket.boostrapper.exe).
Atm i prefer plan C, while is longer than B to implement, add a lot more value with less maintenance long term.
as a note, i volounteer to implement the choosen solution. if someone want to help, will be nice, because tasks can be split
yes that's another way. two options afaik:
bundled in sdk, as app/package
Technically, yes. we have done that for fsharp.net.sdk, and put inside sdk is just a packaging thing (cli/sdk build script restore a pinned package and unzip in release dir).
Issue is, if there is an error in boostrapper, you need another release of sdk to fix that (and just sdk team can schedule that).
as Sdk attribute
Another possibility, the real issue, is if
Both mean will work only with new msbuild/cli/sdks versions.. and given the churn in sdk tooling and the need for stability, ihmo is not going to be implemented soon..
ok, dotnet cli is adding tools (sdk scooped) in v2.2 (ref dotnet/cli#8067 )
we can use that later for boostrapper. meanwhile need another options for that
And paket can manage tools too, because should be easy. adding per repo tools (who can be used to self-update itself, if the boostrapper is just paket)
the tools are just .net core fdd app published in the
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>
This was referenced
Jan 23, 2018
There is nothing to do at the moment - but as soon as NuGet actually implements this stuff, we should also start so we don't hang behind.
From the empty checklists in both issues, I would expect this to land in 16.0 maybe.
The important question is how the resolving works when we don't control the host (VS or Rider, or VS Code, ...).
This was referenced
Jan 23, 2018
@aggieben yes, latest (just today, i was working on it these days), is in https://github.com/enricosada/paket-netcore-testing-as-tool/
should be somewhat done (minus known bugs). please review the PR