Skip to content
New issue

Have a question about this project? Sign up for a free GitHub account to open an issue and contact its maintainers and the community.

By clicking “Sign up for GitHub”, you agree to our terms of service and privacy statement. We’ll occasionally send you account related emails.

Already on GitHub? Sign in to your account

DotnetTool packages must redistribute their dependencies #8656

Closed
natemcmaster opened this issue Feb 21, 2018 · 6 comments

Comments

@natemcmaster
Copy link
Contributor

commented Feb 21, 2018

The current design of DotnetTool packages requires that they include the "dotnet publish" output of their console app. In most cases, this means tool authors must redistribute the dependencies they acquired from other NuGet packages. This has the following problems:

  • tool packages can become fairly large if they have a high number of dependencies
  • tool authors have to be careful about how they codesign their package and binaries
  • tool authors must ensure they comply with the licensing requirements of third-party dependencies

Example
When attempting to converting Microsoft.VisualStudio.Web.CodeGeneration.Tools to be a global tool, the package went from 85 kb to 3 MB. The converted package included an additional 9 assemblies that are available already in other NuGet packages. The assemblies were a mix of assemblies from third-parties and other partner projects inside Microsoft. We have to very carefully configure our signing to make sure the right certificates are used on the right binaries.

Ideas
The SDK could support a "trimmed" DotnetTool mode. This could leverage additional probing paths and NuGet restore to layout files on install without requiring they all come from the same package. How this might work:

  • When PackAsTool is set /t:Publish trims binaries that come NuGet packages that will end up in the tool nuspec
  • On install, dotnet-install-tool restores dependencies of the tool package (this is already the case today)
  • On install, dotnet-install-tool generates a runtimeconfig.dev.json file with additional probing paths set to the package install root.
@livarcocc

This comment has been minimized.

Copy link
Member

commented Feb 22, 2018

We had this as one of the goals of dotnet tools because folks actually find it extremely confusing to have their tools running against the NuGet cache. Plus, this is a model that was originally designed only for dotnet run to be used during development type, that we exploited to execute production code.

Also, this prevents folks from optimizing their tools, with things like crossgen.

cc @Petermarcu who also has some opinions on this.

@livarcocc livarcocc added this to the Discussion milestone Feb 22, 2018

@natemcmaster

This comment has been minimized.

Copy link
Contributor Author

commented Feb 22, 2018

To be clear, I'm not suggesting you eliminate the "fat package" approach. That should stay for tool authors who want things like crossgen. I'm just trying to point out that the CLI could support "trimmed" mode in addition to the current "fat package" mode.

@richlander

This comment has been minimized.

Copy link
Member

commented Feb 26, 2018

I'd like to stay the course until we find it unworkable. The system we designed and built is super simple and has broad applicability. For example, we believe that people will restore a set of apps and then xcopy them to another machine as a feed. That becomes difficult with the NuGet approach. We intended NuGet to be a transport for these apps but for them not to be NuGet any more than that. I grasp how the model you propose makes sense, but it breaks the consumption use case that I mentioned (xcopy). My feeling is that simplicity will trump size. Let's see what the feedback looks like.

@Petermarcu

This comment has been minimized.

Copy link
Member

commented Feb 26, 2018

There are also other approaches that can be considered if size due to lots of duplication in global tools becomes an issue.

@onovotny

This comment has been minimized.

Copy link
Member

commented Mar 3, 2018

I would like to see .NET Native as part of the solution to this, as the linker step should reduce unused code paths, though admittedly would mean you'd need one per platform.

@natemcmaster

This comment has been minimized.

Copy link
Contributor Author

commented Aug 17, 2018

Closing as I think the priority on this one is low, and I don't believe there are compelling reasons to change the design.

Sign up for free to join this conversation on GitHub. Already have an account? Sign in to comment
Projects
None yet
5 participants
You can’t perform that action at this time.