This issue has been moved from a ticket on Developer Community.
[severity:It's more difficult to complete my work]
Setup:
Consider following scenario:
- There is an interop Interop.I referenced by two C# projects Project.Base and Project.Derived
- Embed Interop Types is set to true for both projects referencing the interop
- Project.Base declares a base class Project.Base.BaseClass which derives from some other class C and explicitly implements an interface Interop.I.SomeInterface from the interop Interop.I because the interface's members clash with the members of C
- Project.Derived now declares a class Project.Derived.DerivedClass which derives from Project.Base.BaseClass
- In addition to that Project.Derived declares an interface View, which has no members, and just derives from Interop.I.SomeInterface
- The class Project.Derived.DerivedClass also derives from the interface View
Expected behaviour:
As Project.Base.BaseClass fully explicitly implements the interface Interop.I.SomeInterface the compiler should use that implementation for implicitly implementing the View interface, which also derives from Interop.I.SomeInterface, on the derived class Project.Derived.DerivedClass.
Observed behaviour:
The observed behaviour is however, that the compiler complains, that it cannot implicitly implement some members of the interface Interop.I.SomeInterface using corresponding members of C, which is the base class of Project.Base.BaseClass because, their return/parameter types don't match the return/parameter types of the members in the interface.
Additional observed behaviour:
- Declaring the same setup as above but within one project ( all described declared classes and interfaces are in one single project, the interop is still embedded ) works.
- Setting the Embed Interop Types option for the interop reference in both projects to false resolves the issue
Explanation:
Embedding the interops, actually embeds the interface Interop.I.SomeInterface into the assemblies Project.Base and Project.Derived and the embedded interface is flagged using the TypeIdentifierAttribute such that type equivalence can be used for that interface.
Basically Project.Base.BaseClass and the interface Project.Derived.View derive from a local copy of the type Interop.I.SomeInterface and thus this local copies would be considered to be different types, without type equivalence.
And it seems that the compiler does ignore the type equivalence when implicitly implementing that local copy of the embedded interface Interop.I.SomeInterface in Project.Derived.DerivedClass, although the interface is actually the same interface, as implemented by Project.Base.BaseClass.
If the compiler does not complain about passing over instances of Interop.I.SomeInterface from Project.Derived as parameter types/return value types to Project.Base when Embed Interop Types is set to true, which means that in this case type equivalence is respected, the same should be true, for implicit interface implementation.
Desired fix:
The compiler should also consider type equivalence for embedded interface types, when implicitly implementing those interfaces as described in the scenario above, such that it behaves as expected, i.e. like in the case where all of the mentioned classes and additional interfaces would have been declared in the same project, or in two projects, but with interop type embedding disabled.
Original Comments
Feedback Bot on 7/11/2022, 05:45 PM:
(private comment, text removed)
Feedback Bot on 7/20/2022, 07:45 AM:
(private comment, text removed)
Original Solutions
(no solutions)
This issue has been moved from a ticket on Developer Community.
[severity:It's more difficult to complete my work]
Setup:
Consider following scenario:
Expected behaviour:
As Project.Base.BaseClass fully explicitly implements the interface Interop.I.SomeInterface the compiler should use that implementation for implicitly implementing the View interface, which also derives from Interop.I.SomeInterface, on the derived class Project.Derived.DerivedClass.
Observed behaviour:
The observed behaviour is however, that the compiler complains, that it cannot implicitly implement some members of the interface Interop.I.SomeInterface using corresponding members of C, which is the base class of Project.Base.BaseClass because, their return/parameter types don't match the return/parameter types of the members in the interface.
Additional observed behaviour:
Explanation:
Embedding the interops, actually embeds the interface Interop.I.SomeInterface into the assemblies Project.Base and Project.Derived and the embedded interface is flagged using the TypeIdentifierAttribute such that type equivalence can be used for that interface.
Basically Project.Base.BaseClass and the interface Project.Derived.View derive from a local copy of the type Interop.I.SomeInterface and thus this local copies would be considered to be different types, without type equivalence.
And it seems that the compiler does ignore the type equivalence when implicitly implementing that local copy of the embedded interface Interop.I.SomeInterface in Project.Derived.DerivedClass, although the interface is actually the same interface, as implemented by Project.Base.BaseClass.
If the compiler does not complain about passing over instances of Interop.I.SomeInterface from Project.Derived as parameter types/return value types to Project.Base when Embed Interop Types is set to true, which means that in this case type equivalence is respected, the same should be true, for implicit interface implementation.
Desired fix:
The compiler should also consider type equivalence for embedded interface types, when implicitly implementing those interfaces as described in the scenario above, such that it behaves as expected, i.e. like in the case where all of the mentioned classes and additional interfaces would have been declared in the same project, or in two projects, but with interop type embedding disabled.
Original Comments
Feedback Bot on 7/11/2022, 05:45 PM:
(private comment, text removed)
Feedback Bot on 7/20/2022, 07:45 AM:
(private comment, text removed)
Original Solutions
(no solutions)