React to deps.json change wrt PrivateAssets

[AndriySvyryd]

dotnet/sdk#45259 removes PackageReferences with PrivateAssets="all" from the .deps.json. This means that by default EFCore.Design references will no longer be discovered by our tools.

[AndriySvyryd]

@bricelam If that change does go through, I'm not sure that there's much that we can do other than documenting that EFCore.Design should be referenced directly from every project that would be targeted by tools.

[bricelam]

Using AssemblyLoadContext (mentioned in #18840) would be an alternative to calling dotnet exec with the project's .deps.json file. This would allow us (Edit: lol, I can't help myself; it just comes out. I mean you guys) to define where it gets loaded from.

[baronfel]

We're reverting that PR based on feedback from several partner teams, so 200 shouldn't blow up your expectations. Apologies for the close call, but please in the future yell at us if something we do has inordinate impact on your use cases.

[AndriySvyryd]

@baronfel Thanks, will do. We thought that we could react to it in a patch to avoid breaking the users, but I only got to it last week and found out that to be able to use AssemblyLoadContext we'd have to update our TFM.

We are still going to make this change for 10 anyway as it should make assembly loading more robust in general. And we already had a user report that presented the same symptoms.

[guardrex]

Unfortunately, the EF change to account for this doesn't meet the servicing bar for EF 9.0.x, so it will be fixed in EF 10.

We have a few ASP.NET Core tutorials that rely upon EF Core tooling that are going to require the workaround, and our versioning tools are rather poor. They never fixed versioning by file (article), so we must use markdown syntax and maintain coverage for many years to cover breaking changes like this. You can see how much extra content we need to carry in my comment at dotnet/AspNetCore.Docs#34812 (comment) to resolve this in articles.

If there is any chance that the updates to resolve this could be placed into .NET 9, it would clean up our doc coverage quite a bit.

[AndriySvyryd]

@guardrex As @baronfel mentioned above this change has been reverted and the workaround won't be needed for the newer 9.0.* SDKs

[guardrex]

I see! Thanks for the clarification.