SDK product construction is broken when aspnetcore moves ahead of runtime

[ViktorHofer]

Right now the main SDK has a newer aspnetcore which itself references a newer runtime than what's inserted into sdk.

IOW:
sdk -> aspnetcore -> runtime (newer)
sdk -> runtime (older)

Customer Impact: Using Microsoft.AspNetCore.App (aspnetcore) is broken. The host fails to load apps that depend on it.

I thought we had tests for that...

[JamesNK]

What's the status here? Is progress being made towards a fix?

[ViktorHofer]

We fixed this for a single point in time so that we could promote a newer SDK to Arcade but this issue tracks investigating why tests didn't fail when there's the coherency mismatch between aspnetcore and runtime. While the overall problem will go away with the VMR, we still should have tests that asset the expected state.

[marcpopMSFT]

We had a test in installer that caught this there but when run in sdk, it's apparently not catching it. is it a problem with our stage 2 setup maybe?

[Forgind]

This is perhaps a bit out there, so bear with me.

As I understand it, our dependency model currently looks like spaghetti. aspnetcore depends on the runtime? Have runtime insert into aspnetcore. sdk depends on runtime? Have runtime insert into sdk. SDK packages aspnetcore? Have SDK depend on aspnetcore. Oops.

Dependency management is hard but only because we do it as a distributed system in which every repo has needs (receives insertions) and fills needs (creates insertions). Needs are filled directly by whichever repo can fulfil that need.

A much simpler model is a leader-client type model. The SDK can receive insertion PRs from each repo and send out insertions (of relevant pieces) to each other repo. No one talks to anyone except the SDK. That would mean that no other repo could be ahead of the SDK, and since the SDK is the primary shipping vehicle (other than VS, which shouldn't have this issue), we'll never have inconsistencies like this affecting customers.

I like this solution because it's more of a "correct by design" principle rather than a "hope it's right then test it" model that relies on the tests being reliable. It would take a bit longer for runtime bits to reach aspnetcore, but it's more reliable and reduces the total number of insertions needed across .NET.

Thoughts?

[ViktorHofer]

This problem will get solved with the VMR which we have been working on for the last 24-36 months (depending on whom you ask). What you describe is essentially the VMR model.

[Forgind]

Perhaps I don't understand the VMR properly, but it sounds a bit different? My understanding is that even with the VMR, we'd still have individual repos shipping their bits to each other; it's just that when it's time to ship bits to customers, everything gets built together in the VMR. Is that incorrect?

[ViktorHofer]

With the VMR dotnet/sdk will get its runtime, aspnetcore and other dependencies defined in Version.Details.xml from dotnet/dotnet via a combined dependency update.

[Forgind]

I'm a bit confused. Since you filed this issue, it sounds like you think there's some action we should take here. But it also sounds like you're saying we don't need to worry about SDK's various dependencies being out-of-sync with each other, in which case there's no action for us to take. Can you clarify what you're hoping for?

[ViktorHofer]

The VMR will fix this for .NET 10 Preview 4 and onwards. I originally filed this issue as it affected both .NET 9 and main and the VMR was still months away. We can close the issue if we don't want to take any action (not even for .NET 9) but it would still be good to make sure that the test that @marcpopMSFT mentioned, runs against the live bits:

We had a test in installer that caught this there but when run in sdk, it's apparently not catching it. is it a problem with our stage 2 setup maybe?

[marcpopMSFT]

My best guess is that when we moved the tests from installer to here, they ended up running against the SDK stage 2 build rather than the installer stage 2 build (this is prior to the redist merges that Viktor did). The SDK stage 2 wasn't an exact match to our actual released product so wouldn't catch runtime incoherency. Now with those build outputs merged, this should be solved in main but the issue exists in 9. I just don't know if we need to fix it in 9 because we generally have a CQB watching the runtime flows in 9, the public builds don't include runtime flow, and we don't stage something unless it's coherent.

So I think this is both fixed and will be resolved again with the VMR. So I'm going to go ahead and close it. Let me know if there are concerns with that.