Skip to content

Conversation

@ViktorHofer
Copy link
Member

@ViktorHofer ViktorHofer commented Dec 15, 2025

By using NET="Runtime" on UsingTask declarations, msbuild runs the task always on .NETCoreApp, even on desktop msbuild.

Delete two unused projects:

  • IssueManager (not used in dnceng anymore)
  • Microsoft.DotNet.Tar (was only necessary for desktop SignTool)

Benefits:

  • Less code to maintain
  • Less Audit/CG alerts due to the removal of .NET Framework toolset version dependencies

@ViktorHofer
Copy link
Member Author

ViktorHofer commented Dec 15, 2025

Two blockers so far:

Slightly related: There a few remaining tools(!) / libraries that still target .NET Framework that I'm not sure about: Helix.Client, Helix.JobSender, StrongName, SignCheck and SignCheckLibrary. I wonder if all those need to stay on .NET Framework?

@ViktorHofer ViktorHofer force-pushed the UseNETCoreAppTasks branch 3 times, most recently from c0c2104 to 35ef0d6 Compare December 15, 2025 12:58
@mmitche
Copy link
Member

mmitche commented Dec 15, 2025

Love this.

@mmitche
Copy link
Member

mmitche commented Dec 16, 2025

SignTool running on framework might have to do with packing/unpacking VSIX's. At least that was the case at some point. For signcheck...IIRC some functionality used to not be supported on core. Maybe some authenticode or VSIX checking? Either way, I think that was resolved.

ViktorHofer added a commit to dotnet/sdk that referenced this pull request Jan 22, 2026
Needed to unblock dotnet/arcade#16413 to workaround dotnet/msbuild#12895 but in general offers a way to import BundledVersions.props information from projects that don't import the Microsoft.NET.Sdk.
if (VerifyRecursive)
{
#if NETFRAMEWORK
if (PEHeader.ImageSectionHeaders.Select(s => s.SectionName).Contains(".wixburn"))
Copy link
Member

Choose a reason for hiding this comment

The reason will be displayed to describe this comment to others. Learn more.

I'm a little confused as to why this was excluded on core before if it worked..any ideas?

Copy link
Member Author

@ViktorHofer ViktorHofer Jan 22, 2026

Choose a reason for hiding this comment

The reason will be displayed to describe this comment to others. Learn more.

b1439d7 - @ellahathaway I know that was a long time ago but do you maybe remember?

Copy link
Member

Choose a reason for hiding this comment

The reason will be displayed to describe this comment to others. Learn more.

Hm.... I unfortunately don't remember, and I'm not even sure I could guess because, as Matt said, it worked before.

I did just e2e test it this change with arcade-validation and didn't encounter any errors 🤷

Copy link
Member Author

Choose a reason for hiding this comment

The reason will be displayed to describe this comment to others. Learn more.

I think you misunderstood. We were curious why this was excluded before in your change given that the code compiles just fine on NETCOREAPP.

Copy link
Member

Choose a reason for hiding this comment

The reason will be displayed to describe this comment to others. Learn more.

I understood what you meant, but I'm sorry I wasn't clear in my response. I don't remember why I excluded it.

Copy link
Member

Choose a reason for hiding this comment

The reason will be displayed to describe this comment to others. Learn more.

Maybe it was protecting some downstream codepath? Either way, this is safer than removing the code altogether.

@ViktorHofer
Copy link
Member Author

ViktorHofer commented Jan 30, 2026

VMR validation build: dotnet/dotnet#4554

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 this pull request may close these issues.

4 participants