Configure 10.0.2xx branch#2632
Conversation
mthalman
commented
Sep 26, 2025
- Deletes all the shared runtime-related repos as the source for these will be from the 10.0.1xx branch.
- Updates branding
- Adds the dependency on the 1xx sources from the latest RC2 build
- Misc bug fixes in infrastructure
|
/azp run |
|
/azp list |
|
While it's not showing up in the PR build (because it's an online build), I do have a local build that is failing on these changes with this error: This is because the portable package @jkoritzinsky - Is this related to #1912? Also, from the binlog, I see that the runtime's build is outputting this package to the Related binlogs: |
|
Another issue from the build: |
|
Another issue from the build that only happens in the vertical legs. For some reason, it's not consuming the correct version of System.CommandLine. |
It looks like the SDK that you're building the 10.0.2xx band with is a Microsoft SDK, not the source-built SDK from the 10.0.1xx build? With the changes we've made for the RID handling for source-build, the expectation here is that using a portable SDK here would require pulling down the portable |
That's correct.
We essentially want to replicate the behavior that is occurring in the 1xx build. In 1xx, the build of the I don't quite understand what issue was being fixed by removing the portable package from the artifacts. But can it be solved in an alternative way that would condition the referencing of the crossgen package on whether the SDK being used is portable or not? |
|
The "portable" package that exists in the source-build vertical and isn't published isn't identical to the portable build. It's a mix between portable and source-built LKG assets. Its existence is only to provide a package with the name that the LKG SDK can find when looking for the crossgen2/ilc tool packs. Additionally, @tmds requested that we remove this package from the SG assets tarball as they don't want portable assets in the tarball (and they didn't exist pre-VMR due to how how the old half-working crossgen setup in aspnetcore and sdk worked). We can't make the SDK guess the RID for source-build as it has no way to know if the machine is compatible with that RID (ie the cross-build source-build scenario, which our community uses for community-supported OS and architecture builds), so the tooling relies on the SDK's reported RID. You could disable crossgen by updating the condition for IsCrossgenSupported at https://github.com/dotnet/sdk/blob/8b95e275b0d8d51c76892676576f80ac9e421181/src/Layout/redist/targets/Crossgen.targets#L5 to exclude source-build feature bands. Alternatively, if the build can consume portable bits, why can't we have the build download the 1xx portable tarball in addition to the 1xx source-build tarball? |
|
Another question: Do we want the feature bands building against the runtimes from the shared components tarball, or do we want them building against the bits in the LKG SDK? If we were to want to build them against the LKG SDK, then we could consume the crossgen2 that matches the SDK (which I assume is accessible at this point based on the failure message). I expect that this isn't what we want though, so that solution wouldn't work. |
Rids should enable us to express compatibility without building "pretend" portable assets. Having non-portable SDK build produce portable assets has been a source of bugs, like dotnet/source-build#5225, so I prefer to avoid it. |
|
Ok, confirmed that using the non-portable source-built SDK resolves the issue. This should be fine. It's not too disruptive to adjust to that. |
Should be resolved by aed52d3. |
MichaelSimons
left a comment
There was a problem hiding this comment.
It would be good to capture some information while it is fresh in your mind on what the process will look like when we branch for 11.0.2xx. It looks like it is mainly, remove "runtime" source, update branding, trigger the flow from 11.0.1xx?
|
|
@mmitche - PTAL |
|
@mthalman what do you want to happen? |
|
@mthalman but are there any nuances? Some packages that need to be pinned? Or do we want to update every single |
|
@mthalman using the latest darc you should be able to do this using the Please let us know if you have any feedback on the subscription creation experience |
It should mirror the subscriptions that already exist for each repo. So, outside the context of the VMR, if the Ideally, there'd be a system in place to keep these subscriptions in sync.
Yes. As stated in #1108:
How do you configure all these subscriptions to flow in one PR? |
|
@mthalman if you configure these as per #1108 (comment) You can target So it will be a single subscription which will update all |
