Enable SignFile on .NET Core/5+

[Zastai]

Fixes #6098

Context

The SignFile task is referenced by the SDK for both .NET Framework and Core/5+, but not actually included in the non-framework assemblies.

Changes Made

Include SignFile.cs in the non-framework compilation.

Testing

A simple test, applying SignFile to one of the DLLs in artifacts using a self-signed certificate, succeeded.

[Forgind]

Might be useful to throw in a unit test? I don't think it's critical, and the change looks good to me. Thanks!

[Zastai]

I considered it - but I'm not sure how I would set up a unit test that relies on entries in the certificate store (plus potentially a timestamp server).

If there is already a unit test for SignFile that only runs on .NET Framework, then yes, it should now be enabled on .NET Core/5+ too, but I don't think there is one.

[rainersigwald]

I was hoping for tests too but I agree that there don't appear to be any. Alas. Thanks!

[Zastai]

Incidentally, I noticed that the main branch produces MSBuild version 17 (i.e. VS2020).
What is the procedure for backports?
If this gets merged, will it automatically get included in the next .NET Core 3.1 and 5.0 SDKs?
If not, what do I need to do? Make separate PRs based on particular branches?

[Forgind]

It will not. We have vs* (like vs16.11) branches that are for supporting earlier versions, so we'd have to merge into one of those branches. There's automation for bringing changes from vs* to main but not vice versa.

We decided that we can backport this to vs16.11 (so the 5.0 SDK), but we don't think this is high-priority enough to bring it back to 16.10 or before. Is there a reason you think it is?

As far as backporting it to vs16.11, you can just retarget this to vs16.11, but that would likely bring in extra commits we don't want, so please also clean that up afterwards.

[Zastai]

I suppose the 5.0 SDK is fine, but given 3.1 is still in LTS for a good while, it seems to make sense to have it there too.

Would 16.11 mean "next 5.0 SDK gets it" or "next 5.0 feature band gets it"? If the latter, I might aim for 16.10 because that gets me the fix faster.

Given the triviality of the change, I'll look at just recreating the PR branch on my end and force-pushing, unless there's a reason not to do it that way.

Just let me know to base it on 16.10 or 16.11. Will convert to a draft for now.

[Forgind]

LTS is more about whether we will provide fixes for critical bugs rather than whether we will enable new features, and this feels more like a feature to me than a bug fix. If it's in 16.11, that will go into the next release of the 5.0 SDK. Our team agreed that's best, so please rebase this on 16.11 after you've done the force push. Thank you!

[Zastai]

I think that should do it.

[rainersigwald]

Would 16.11 mean "next 5.0 SDK gets it" or "next 5.0 feature band gets it"?

MSBuild 16.11 will ship in .NET SDK 5.0.400.

[Forgind]

@rainersigwald, something's up with those last two legs. They've been running for over 2 hours and haven't cancelled themselves, which also means I don't see error messages or logs. Do you have any suggestions on how to debug that?

[rainersigwald]

I don't know what's up with the checks. I suspect it's because those PR jobs exist in main but not vs16.11. I'll bypass the policy to land this.

[rainersigwald]

Thanks @Zastai!