Open masonwheeler opened 11 months ago
Copying my comments from https://github.com/dotnet/msbuild/issues/9389 as requested by @rainersigwald:
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:
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.
In other words, Antlr4BuildTasks should
@kaby76, we've discovered some problems related to System.Text.Encoding.CodePages
as well. When we're updating to the lastest Antlr4BuildTasks
dependency, we got a conflict because we had only referenced version 4.5.0
ourselves, but 7.0.0
was required. So we went ahead and updated our dependency as well.
This has worked fine on .NET 8, but we quickly got reports from users that it failed at runtime in .NET 6 environments due to not finding the System.Text.Encoding.CodePages
dependency.
I didn't really find a workaround with the newer versions, so I switched back to 12.2.0
, since all versions after seemed to produce the bug.
If I understood it correctly, it basically caused runtime errors for packages that referenced Antlr4BuildTasks
and also internally relied on ´System.Text.Encoding.CodePages`. Setting all assets to private and only including build assets did also not resolve the issue.
System.Text.Encoding.CodePages
This is caused by Antlr4BuildTasks requiring Microsoft.Build.Utilities.Core which requires System.Text.Encoding.CodePages. Assuming that changes in the API are backward compatible, try adding <NoWarn>NU1605</NoWarn>
to the first/top <PropertyGroup>
in the .csproj and test.
Thanks! I did try it with <NoWarn>NU1605</NoWarn>
, that seemed to work. But I'm not sure if it's correct to suppress a warning😀
I'm not really sure how to solve that, either. I don't have a lot of experience with building build tools for .NET. My first idea would probably be to try to somehow inline the dependencies, so the required dlls for Antlr4BuildTasks
are copied to the NuGet package and resolved during the build execution via some custom assembly load logic, but that doesn't sound very clean.
Citing @masonwheeler's very helpful change from the other referenced thread in case anyone lands here - this fixed the issue of unneeded dependencies being copied to the output folder. I didn't notice any unwanted side effects.
- <PackageReference Include="Antlr4BuildTasks" Version="12.4.0" />
+ <PackageReference Include="Antlr4BuildTasks" Version="12.4.0" PrivateAssets="all" IncludeAssets="build" />
The MSBuild dependencies make this code generator very heavyweight, transitively dragging over 30 other 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 code generator. (Or even a not-so-simple one that has to hand the code generation work off to a Java process.)Would it be possible to produce a lightweight code generator package for those of us whose only use case is running the code generation and not any of the build-system stuff? Or is MSBuild somehow integral to that?