I couldn't figure out the best area label to add to this issue. If you have write-permissions please help me learn by adding exactly one area label.

@ellahathaway

FYI this is currently blocked on a MicroBuild issue: https://dev.azure.com/devdiv/DevDiv/_workitems/edit/2270151

Awesome! Let me know if there's anything I can do to help

T-Shirt Size: XS

@wtgodbe - Is there a way to make progress on this issue without enabling arcade signing in aspnetcore's Mac & Linux legs, which is currently blocked on https://dev.azure.com/devdiv/DevDiv/_workitems/edit/2270151? The lack of ItemsToSign (removed here) is causing my changes in dotnet/sdk#44855 to be blocked.

@ellahathaway any idea why ItemsToSign is empty? It should get filled here:

@ellahathaway I think the link at "removed here" is wrong, it just links to this issue

any idea why ItemsToSign is empty? It should get filled here:

I'm investigating. It's weird because the binlog does not show the ItemsToSign ever being re-added, and it does not list CommonFilesToSign as defined either. Oddly it does show other items being evaluated, such as the FileExtensionSignInfos

I think the link at "removed here" is wrong, it just links to this issue

Whoops sorry. Should be this link:

Oooh maybe it's the PostBuildSign property. I don't see it being set in the binlog, so it's possible that that's resulting in both when conditions not being evaluated.

Yes, the VMR build shouldn't do post-build signing. The property shouldn't be set.

I looked into this a bit further, and it appears that there's no artifacts that match the patterns for ItemsToSign.

I would expect to see .nupkgs in D:\a\_work\1\vmr\src\aspnetcore\artifacts\packages\Release\, but I don't see any listed in the binlogs or in the .log file. For example, I don't see something like Successfully created package '/__w/1/s/artifacts/sb/src/artifacts/packages/Release/Shipping/Microsoft.AspNetCore.App.Runtime.<os>-<arch>.10.0.0-ci.nupkg., but I don't.

This is taken from the source-build binlog from the failing UB PR, and these are the only matches for nupkg in the binlog:

I looked into this a little bit and noticed that aspnetcore has two inner builds (native and managed) which write to the same binlog output path. Filed dotnet/source-build#4740

• Build.native.binlog: The native (desktop msbuild) outer repo binlog
• source-inner-build.binlog: Initially the native (desktop msbuild) inner repo binlog but gets overwritten if the managed inner build gets invoked. If the native part already fails then it doesn't get overwritten.
• Build.binlog: The managed (dotnet build)

Yes, the item group is empty but for the native build. The managed build didn't even run yet because the native one failed because it doesn't find any artifacts to sign (which I think is expected). Submitted dotnet/dotnet#111 to see how this works today with the -publish build action.

OK so the issue here is that aspnetcore's build is basically a two-phase build but both phases receive the -sign and -publish arguments and I'm not exactly sure that's what we want. Additionally, it looks like not just the binlog from the native phase is overwritten but also the asset manifest. So if the native part would actually publish anything, it wouldn't be respected.

I considered multiple options (i.e. just allowing an empty sign list) but really this needs to be fixed at the invocation layer so that aspnetcore doesn't attempt to sign and publish twice. Honestly, aspnetcore's two phase build feels quite hacky to me. Other repos solve this differently.

I considered multiple options (i.e. just allowing an empty sign list) but really this needs to be fixed at the invocation layer so that aspnetcore doesn't attempt to sign and publish twice. Honestly, aspnetcore's two phase build feels quite hacky to me. Other repos solve this differently.

The use of vcxproj makes it tough. I think that still requires desktop at this point.

I would go with passing -sign to only certain phases for now.

Blocked on dotnet/source-build#4794

The blocking issue has now been resolved. Moving this back to In Progress