[Feature Request]: Can the transitive dependencies be reduced any?

[masonwheeler]

Summary

The Microsoft.Build.Utilities.Core NuGet package is surprisingly heavyweight, dragging dozens of transitive NuGet dependencies into the project, including bizarre things like System.Drawing.Common and a whole host of security/permissions related things, none of which feel like they have anything to do with running a simple build script. Is there any way that this could be cut down a bit?

Background and Motivation

I'm trying to use ANTLR in my project. The ANTLR code generator uses Microsoft.Build.Utilities.Core, which drags 30+ other packages along for the ride, significantly slowing down the CI build machine, because there are a lot of projects that depend on this project and so all of them get entire this transitive dependency set pulled in. Why in the world should I need all of that baggage just to build a parser?

Proposed Feature

Would it be possible to examine the dependencies and see if there are any outdated references that can be trimmed? We all know how projects that have been around for a while tend to accumulate cruft, afterall...

Alternative Designs

No response

[masonwheeler]

Also asked the ANTLR code generator project if MSBuild is truly necessary for a code generator.

[KalleOlaviNiemitalo]

Compare to the Microsoft.Build.Tasks.Git package, which provides MSBuild tasks and does not depend on any NuGet packages -- it instead assumes that the process has already loaded the MSBuild DLLs.

https://nuget.info/packages/Antlr4BuildTasks/12.4.0 shows lib/netstandard2.0/Antlr4BuildTasks.dll depending on these:

• Microsoft.Build.Framework, Version=15.1.0.0, Culture=neutral, PublicKeyToken=b03f5f7f11d50a3a
• Microsoft.Build.Utilities.Core, Version=15.1.0.0, Culture=neutral, PublicKeyToken=b03f5f7f11d50a3a
• netstandard, Version=2.0.0.0, Culture=neutral, PublicKeyToken=cc7b13ffcd2ddd51
• System.Buffers, Version=4.0.2.0, Culture=neutral, PublicKeyToken=cc7b13ffcd2ddd51
• System.Memory, Version=4.0.1.2, Culture=neutral, PublicKeyToken=cc7b13ffcd2ddd51
• System.Text.Encoding.CodePages, Version=7.0.0.0, Culture=neutral, PublicKeyToken=b03f5f7f11d50a3a

The System.Text.Encoding.CodePages assembly dependency seems a bit suspect; I'm not sure that's always available in the MSBuild process, and I don't think the NuGet dependencies of Antlr4BuildTasks matter for that purpose at all.

[rainersigwald]

System.Drawing.Common has been removed for 17.8 by #9055.

a whole host of security/permissions related things, none of which feel like they have anything to do with running a simple build script.

Unfortunately, many of them do because build scripts are not reliably that simple. If you have any other specific ones to call out we can look at the nature of the dependency.

[KalleOlaviNiemitalo]

In other words, Antlr4BuildTasks should

• mark dependencies as private so that the resulting NuGet package does not depend on the packages that were used for building Antlr4BuildTasks
• bundle dependencies into the package so that System.Buffers, System.Memory, and System.Text.Encoding.CodePages can be loaded at build time even if MSBuild does not depend on the same versions

[rainersigwald]

I'm trying to use ANTLR in my project. The ANTLR code generator uses Microsoft.Build.Utilities.Core, which drags 30+ other packages along for the ride, significantly slowing down the CI build machine, because there are a lot of projects that depend on this project and so all of them get entire this transitive dependency set pulled in.

I agree with @KalleOlaviNiemitalo that the Antlr4BuildTasks package appears to be overselling its dependencies. You can work around this in your projects by minimizing the reference though, like

- <PackageReference Include="Antlr4BuildTasks" Version="12.4.0" />
+ <PackageReference Include="Antlr4BuildTasks" Version="12.4.0" PrivateAssets="all" IncludeAssets="build" />

Where PrivateAssets means "don't flow to projects that reference me" and IncludeAssets="Build" means "only use the build logic from this package, don't reference its library".

[rainersigwald]

@KalleOlaviNiemitalo

• bundle dependencies into the package so that System.Buffers, System.Memory, and System.Text.Encoding.CodePages can be loaded at build time even if MSBuild does not depend on the same versions

I think we provide all of those on all platforms (though bundling them would be basically harmless).

[rainersigwald]

@KalleOlaviNiemitalo mind copying your (excellent) analysis over into kaby76/Antlr4BuildTasks#69?

[KalleOlaviNiemitalo]

It would depend on the version of MSBuild, right? If a project referencing Antlr4BuildTasks is built in Visual Studio 2017, then the appdomain might have some version of System.Text.Encoding.CodePages loaded, but surely not version 7.0.0.0.

[rainersigwald]

It would depend on the version of MSBuild, right? If a project referencing Antlr4BuildTasks is built in Visual Studio 2017, then the appdomain might have some version of System.Text.Encoding.CodePages loaded, but surely not version 7.0.0.0.

Good point, that's very true.

[masonwheeler]

System.Drawing.Common has been removed for 17.8 by #9055.

Cool! Any idea when we can expect to see it in NuGet?

I agree with @KalleOlaviNiemitalo that the Antlr4BuildTasks package appears to be overselling its dependencies. You can work around this in your projects by minimizing the reference though, like

- <PackageReference Include="Antlr4BuildTasks" Version="12.4.0" />
+ <PackageReference Include="Antlr4BuildTasks" Version="12.4.0" PrivateAssets="all" IncludeAssets="build" />

Where PrivateAssets means "don't flow to projects that reference me" and IncludeAssets="Build" means "only use the build logic from this package, don't reference its library".

Thanks! That looks very helpful. I recall seeing something similar added to the csproj by Sam Harwell's old, outdated version of the ANTLR code generator, but I didn't know what it did. This updated version doesn't put that in automatically, though.

[rainersigwald]

Cool! Any idea when we can expect to see it in NuGet?

It will release with .NET 8.0 and Visual Studio 17.8 soon.

[masonwheeler]

All right, and adding those attributes fixes the issue of dragging all those dependencies into all the downstream projects, so I'm good for now.