Changed behavior of DependencyContext.Default.RuntimeLibraries?

[dominikjeske]

After recent updated of SDK/Runtime our ASP.NET Core 6 app (runtime 6.0.14 and SDK 7.0.201) break because DependencyContext.Default.RuntimeLibraries started to return duplicated entries. After investigation we find out that duplicated entry has different type of 'Reference assembly'. Fix was simple but I'm wonder is this intended behavior or maybe bug?

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.

Tagging subscribers to this area: @dotnet/area-dependencymodel
See info in area-owners.md if you want to be subscribed.

Issue Details

---

After recent updated of SDK/Runtime our ASP.NET Core 6 app (runtime 6.0.14 and SDK 7.0.201) break because DependencyContext.Default.RuntimeLibraries started to return duplicated entries. After investigation we find out that duplicated entry has different type of 'Reference assembly'. Fix was simple but I'm wonder is this intended behavior or maybe bug?

Author:	dominikjeske
Assignees:	-
Labels:	area-DependencyModel, untriaged
Milestone:	-

[ViktorHofer]

@dominikjeske do you have a repro or can share the deps.json content before and after? Thanks

[mkeeton]

After recent updated of SDK/Runtime our ASP.NET Core 6 app (runtime 6.0.14 and SDK 7.0.201) break because DependencyContext.Default.RuntimeLibraries started to return duplicated entries. After investigation we find out that duplicated entry has different type of 'Reference assembly'. Fix was simple but I'm wonder is this intended behavior or maybe bug?

What was the "simple fix" you applied. We've suddenly got the same problem popping up on 2 out of 10 dev machines.

[joseoliveira-silva]

After recent updated of SDK/Runtime our ASP.NET Core 6 app (runtime 6.0.14 and SDK 7.0.201) break because DependencyContext.Default.RuntimeLibraries started to return duplicated entries. After investigation we find out that duplicated entry has different type of 'Reference assembly'. Fix was simple but I'm wonder is this intended behavior or maybe bug?

What was the "simple fix" you applied. We've suddenly got the same problem popping up on 2 out of 10 dev machines.

A quick mitigation is to downgrade the .NET SDK version to 6.

[dominikjeske]

After recent updated of SDK/Runtime our ASP.NET Core 6 app (runtime 6.0.14 and SDK 7.0.201) break because DependencyContext.Default.RuntimeLibraries started to return duplicated entries. After investigation we find out that duplicated entry has different type of 'Reference assembly'. Fix was simple but I'm wonder is this intended behavior or maybe bug?

What was the "simple fix" you applied. We've suddenly got the same problem popping up on 2 out of 10 dev machines.

We just added simple Where in our code - it works in our scenario

DependencyContext.Default.RuntimeLibraries .Where(l => l.Type != "reference")

This issue has been marked needs-author-action and may be missing some important information.

This issue has been automatically marked no-recent-activity because it has not had any activity for 14 days. It will be closed if no further activity occurs within 14 more days. Any new comment (by anyone, not necessarily the author) will remove no-recent-activity.

[jane-u]

Will be nice to understand, is this a bug/side effect or feature.

[ericstj]

We need a repro of this. I don't see a deps.json attached to this bug and the description above is not sufficient to repro.
I tried as suggested and the problem did not reproduce.
Here's a sample project I tried: https://github.com/ericstj/sample-code/tree/depcontext-test

Output on net7.0 was:

Runtime libraries: 8
Duplicates: 0
Type project: 2
Type package: 6

Similar on 6.0 (count was 11) and 8.0 (same count).

Can someone with a repro project share their project or modify the repro I shared above to reproduce the issue? Otherwise we might need to resolve as no-repro.

This issue has been marked needs-author-action and may be missing some important information.

[dominikjeske]

@ericstj I have tested your solution and was very confused because everything was ok. I have done some investigation and finally found how it can be reproduced. In our solutions we are using AssemblyName attribute in projects. You can set this in your lib.csproj

<AssemblyName>Test</AssemblyName>

and in main program execute this

var count = DependencyContext.Default.RuntimeLibraries.Where(l => l.Type == "reference").Count();

it should return one element on actual SDK. When you introduce global.json and set SDK used to build you will see that on SDK below 7.0.2* (for example 7.0.109) you will get zero elements and every SDK after will give you additional reference assembly.