AsmResolver Version
6.0.0-beta.5
.NET Version
.NET 10
Operating System
Windows
Describe the Bug
I have a target application targeting .NET Framework 4.8 which i am trying to read from .NET 10.
Target app references System.ComponentModel.DataAnnotations.DisplayAttribute, System.ComponentModel.Annotations, Version=4.2.1.0, Culture=neutral, PublicKeyToken=b03f5f7f11d50a3a from nuget package.
This System.ComponentModel.Annotations, Version=4.2.1.0 assembly is a forwarder to System.ComponentModel.DataAnnotations, Version=4.0.0.0, Culture=neutral, PublicKeyToken=31bf3856ad364e35 where the actual type definitions are, but only on .NET Framework.
On .NET 10 runtime pack, this System.ComponentModel.DataAnnotations assembly is a forwarder to System.ComponentModel.Annotations, Version=0.0.0.0, Culture=neutral, PublicKeyToken=b03f5f7f11d50a3a.
Problem starts when AsmResolver gets to .NET 10 version of System.ComponentModel.DataAnnotations, Version=4.0.0.0 which makes try to resolve forwarded type in System.ComponentModel.Annotations, Version=0.0.0.0, but instead of expected System.ComponentModel.Annotations, Version=10.0.0.0 from runtime directory, it would get System.ComponentModel.Annotations, Version=4.2.1.0 from search path since it has priority over runtime directories making it a circular dependency and failing to resolve
Expected Behavior
I would expect AssemblyResolverBase to restrict assembly lookup only to runtime paths when requesting assembly was also loaded from runtime path, as it's not possible for runtime assemblies to hold references onto application assemblies
Actual Behavior
the implementation stack of type resolver looks like this when the resolution fails
(from search path) System.ComponentModel.Annotations, Version=4.2.1.0, Culture=neutral, PublicKeyToken=b03f5f7f11d50a3a
(from runtime path) System.ComponentModel.DataAnnotations, Version=4.0.0.0, Culture=neutral, PublicKeyToken=31bf3856ad364e35
next entry added would be
(from search path) System.ComponentModel.Annotations, Version=4.2.1.0, Culture=neutral, PublicKeyToken=b03f5f7f11d50a3a
resolved for specification of System.ComponentModel.Annotations, Version=0.0.0.0, but it fails circular reference protection and returns null
Additional Context
No response
AsmResolver Version
6.0.0-beta.5
.NET Version
.NET 10
Operating System
Windows
Describe the Bug
I have a target application targeting .NET Framework 4.8 which i am trying to read from .NET 10.
Target app references
System.ComponentModel.DataAnnotations.DisplayAttribute, System.ComponentModel.Annotations, Version=4.2.1.0, Culture=neutral, PublicKeyToken=b03f5f7f11d50a3afrom nuget package.This
System.ComponentModel.Annotations, Version=4.2.1.0assembly is a forwarder toSystem.ComponentModel.DataAnnotations, Version=4.0.0.0, Culture=neutral, PublicKeyToken=31bf3856ad364e35where the actual type definitions are, but only on .NET Framework.On .NET 10 runtime pack, this
System.ComponentModel.DataAnnotationsassembly is a forwarder toSystem.ComponentModel.Annotations, Version=0.0.0.0, Culture=neutral, PublicKeyToken=b03f5f7f11d50a3a.Problem starts when AsmResolver gets to .NET 10 version of
System.ComponentModel.DataAnnotations, Version=4.0.0.0which makes try to resolve forwarded type inSystem.ComponentModel.Annotations, Version=0.0.0.0, but instead of expectedSystem.ComponentModel.Annotations, Version=10.0.0.0from runtime directory, it would getSystem.ComponentModel.Annotations, Version=4.2.1.0from search path since it has priority over runtime directories making it a circular dependency and failing to resolveExpected Behavior
I would expect AssemblyResolverBase to restrict assembly lookup only to runtime paths when requesting assembly was also loaded from runtime path, as it's not possible for runtime assemblies to hold references onto application assemblies
Actual Behavior
the implementation stack of type resolver looks like this when the resolution fails
next entry added would be
resolved for specification of
System.ComponentModel.Annotations, Version=0.0.0.0, but it fails circular reference protection and returns nullAdditional Context
No response