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

@jkoritzinsky @jtschuster This seems odd. The number of interfaces that require other implementations shouldn't matter. Actually is this one of the issues we talked about where the base interface is in another assembly?

@AaronRobinsonMSFT
If the base interface is in another assembly and only one interface inherits from it, it works.
If the base interface is in another assembly and more than one interface inherits from it, it fails with ArgumentException

This is a real bug in the "different aseembly" limited support we added.

Basically, that loop is the only place we import the base interfaces into our view. We should change that to do a try-add instead of a throwing Add.

@jkoritzinsky I have a local fix. I'd like to move on locally with this fix.
I can build the generator project but have 2 problems: the assembly version numbers are messed up and I'm wondering what's the best way to override one of the runtime dll (in this case the generator dll) in my projects.
Where can I learn more about these ?

There's no good mechanism to override a generator dll shipped with the sdk with a local one. You would have to add some custom MSBuild targets to remove the one provided by the SDK and add your own.

@jkoritzinsky @jtschuster there's another issue. Consider my example above.
when IRoot is in the same assembly as ItfA, the vtable length in CreateManagedVirtualFunctionTable() for ITfA has size 3+1+1=5.
when IRoot is in a different assembly than ItfA, the vtable length in CreateManagedVirtualFunctionTable() for ITfA has size 3+1=4.
It looks like the vtable is missing room for the base interface IRoot's methods.
(in the line void** vtable = (void**)global::System.Runtime.CompilerServices.RuntimeHelpers.AllocateTypeAssociatedMemory).
The vtable indices are correct though.
This causes a buffer overrun as the code tries to write to a smaller array.

Please let me know if you want me to file another more detailed bug.

I should have said that the previous buffer overflow issue happens when/if the original issue is fixed.

If inheriting source generated COM interfaces from interfaces in another assembly is supported (I know there's a warning but as long as you know what you are doing this is a proper use case), then it should just work.

void** vtable = (void**)global::System.Runtime.CompilerServices.RuntimeHelpers.AllocateTypeAssociatedMemory(typeof(<itf>), sizeof(void*) * <number_of_methods_on_this_interface_and_its_base>);
{
    global::System.Runtime.InteropServices.NativeMemory.Copy(
        global::System.Runtime.InteropServices.Marshalling.StrategyBasedComWrappers.DefaultIUnknownInterfaceDetailsStrategy.GetIUnknownDerivedDetails(typeof(global::test_build_lib.IRoot).TypeHandle).ManagedVirtualMethodTable, vtable, 
        (nuint)(sizeof(void*) * <number_of_methods_on_the_base_only>));
}

If this is not possible, then another simple way could be to allow passing a vtable offset.
[GeneratedComInterface(VTableOffset=<number_of_methods_on_the_base_only>)]