Closed Poimen closed 4 years ago
The bi-directional dependency reported by Lamar would be a circular dependency between multiple service registrations. The exception message should tell you the path between the two registrations. Dunno what to tell you, I did what I though was a lot of work to make it possible to troubleshoot these issues in that exception message.
For reference, what we did is directly registered System.Collections.Specialized.NameValueCollection
from Core. This resolved the issue. It almost seemed like it was picking up System
from two different libraries and not being able to distinguish between them. Admittedly our use-case is not very common so didn't expect much help.
The exception message on System dependencies didn't have much in terms of locating the issue. On user types the exception messaging works very well and are very helpful, so that's awesome :)
We are attempting to upgrade a legacy system (Framework 4.6.2) to be hosted in Core 3.0. We are unable to move the entire stack to Core 3.0 because it uses AppDomains. The legacy system uses StructureMap for its IoC, and in the StructureMap configuration it works correctly.
We created a new Core 3.0 hosting environment and included Lamar as a replacement for StructureMap. We then included the service references into the hosting environment. The build succeeded fine.
However, on running, Lamar is reporting:
On some occasions the type changes, but it is always a
System
type that causes abi-directional dependency
. The stack trace provided is not very enlightening.What would cause these bi-directional dependencies?
Is there any further debug we get to aid in finding how to mitigate these dependencies?