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

Microsoft.TemplateEngine.Edge transitively references System.Runtime.Loader/4.3.0 on netstandard2.0 #8061

Closed
ViktorHofer opened this issue Jun 9, 2024 · 2 comments · Fixed by #8065

Comments

@ViktorHofer
Copy link
Member

ViktorHofer commented Jun 9, 2024

<PackageReference Include="System.Runtime.Loader" Condition="'$(TargetFramework)' != '$(NETFullTargetFramework)'" />

This reference is problematic. That API is only availble on .NETCoreApp. The System.Runtime.Loader package hasn't shipped for years and was never intended to be used on .NET Standard (support for it was later removed). See dotnet/runtime#38503 for more details

BTW this is the only remaining dependency that brings 4.x.x / .NET Standard 1.x packages in, in this repository (after my other templating PRs got merged).

cc @ericstj @MichalStrehovsky in case you have opinions on what to do here

ViktorHofer added a commit that referenced this issue Jun 9, 2024
Fixes #8061

Avoid .NET Standard 1.x dependencies in the repo
completely. This results in this repo not being
affected by CVEs / vulnerable packages like
System.Private.Uri that are part of the .NET
Standard 1.x dependency graph.

Upgrade projects that use "System.Runtime.Loader"
from netstandard2.0 to .NETCoreApp as that API is
only availble on .NETCoreApp but keep the
netstandard2.0 TFM. The Loader package that was
used hasn't shipped for years anymore and was
never intended to be used on .NET Standard
(support for it was later removed)
 Because of that, new nullable reference type
 errors were raised by the compiler which I
 suppressed temporarily by downgrading the
 Nullable property to "annotations".
@MichalStrehovsky
Copy link
Member

cc @ericstj @MichalStrehovsky in case you have opinions on what to do here

Build a time machine and stop people from building this package, along with the NetStandard 2.0 package for System.Reflection.Emit that has the same kind of problems.

@ViktorHofer
Copy link
Member Author

Hah, if I had a time machine I would use it for other things in life ;)

More tactically speaking, we should deprecate at least the System.Runtime.Loader package (discussed in dotnet/runtime#38503) and make our own product not use it. I'm removing the dependency on it in this repository with #8065.

ViktorHofer added a commit that referenced this issue Jun 10, 2024
* Remove System.Runtime.Loader dependency on netstandard

Fixes #8061

Avoid .NET Standard 1.x dependencies in the repo
completely. This results in this repo not being
affected by CVEs / vulnerable packages like
System.Private.Uri that are part of the .NET
Standard 1.x dependency graph.

Upgrade projects that use "System.Runtime.Loader"
from netstandard2.0 to .NETCoreApp as that API is
only availble on .NETCoreApp but keep the
netstandard2.0 TFM. The Loader package that was
used hasn't shipped for years anymore and was
never intended to be used on .NET Standard
(support for it was later removed)
 Because of that, new nullable reference type
 errors were raised by the compiler which I
 suppressed temporarily by downgrading the
 Nullable property to "annotations".
Sign up for free to join this conversation on GitHub. Already have an account? Sign in to comment
Labels
None yet
Projects
None yet
Development

Successfully merging a pull request may close this issue.

2 participants