Add test which reproduces but in complex framework resolution #71959
Conversation
The problem is if there is a high-level framework which lists its dependencies as for example NETCore.App first and then ASPNET.App. When we reorder the frameworks during resolution we try to put the lowest level last, but the reorder doesn't work if there's a high-level framework which depends on middle one last - as the last resolved framework in that scenario will be the middle one (ASPNET.App) and it will end up last in the list. The code assumes the last framework is the root (NETCore.App) and thus we look for hostpolicy there.
|
Tagging subscribers to this area: @vitek-karas, @agocke, @VSadov Issue DetailsThe problem is if there is a high-level framework which lists its dependencies as for example NETCore.App first and then ASPNET.App. When we reorder the frameworks during resolution we try to put the lowest level last, but the reorder doesn't work if there's a high-level framework which depends on middle one last - as the last resolved framework in that scenario will be the middle one (ASPNET.App) and it will end up last in the list. The code assumes the last framework is the root (NETCore.App) and thus we look for hostpolicy there. This test is a repro of #71027
|
| } | ||
|
|
||
| [Fact] | ||
| public void TwoAppFrameworksOnTopOfMiddleWare() |
There was a problem hiding this comment.
It would still be an issue with just one framework on top of MiddleWare, as long as it lists MiddleWare last instead of NETCore.App, right? Or does is need the two both doing that?
There was a problem hiding this comment.
Yes - it probably would fail with just one... I added two as it's closer to the original customer reported repro.
|
The CI failure is #70969 |
|
@vitek-karas can this be backported to release/6.0 as well? |
|
As noted in #72080 I personally don't think the gain/risk tradeoff is there for this to be ported to .NET 6 (the test doesn't matter, the future product change). |
ghost
locked as resolved and limited conversation to collaborators
The problem is if there is a high-level framework which lists its dependencies as for example NETCore.App first and then ASPNET.App. When we reorder the frameworks during resolution we try to put the lowest level last, but the reorder doesn't work if there's a high-level framework which depends on middle one last - as the last resolved framework in that scenario will be the middle one (ASPNET.App) and it will end up last in the list.
The code assumes the last framework is the root (NETCore.App) and thus we look for hostpolicy there.
This test is a repro of #71027
I'm adding this as "failing" (the failing part is commented out) so that we have a in-house, simpler repro of the problem.