MDMERGE : error MDM2009: Duplicate type for transitive indirect winmd or project references

[mediabuff]

MDMERGE : error MDM2009: Duplicate type WinDx.WinrtUI.BindableBase found processing metadata file ...\WinDx.WinrtUI\WinDx.WinrtUI.winmd, type already exists in file ..\AnyStream\WinDx.WinrtUI.winmd.

I compile say 'Test.exe' that refers to project WinDx.WinrtUI and AnyStream, I get the above. We have AnyStream also reference WinDx.WinrtUI

[Scottj1s]

Unfortunately, this is a known limitation of the metadata processing. Each non-reference (input) winmd in the transitive graph must be uniquely referenced. Reference winmds (e.g., from the SDK) can be safely pulled in multiple times. Non-reference winmds cannot, and are often pulled in from static library project references. These are merged with the project's metadata, and can then cause duplicate definitions when referenced up stream. Try restructuring your solution to remove the duplicate reference.

[mediabuff]

Tbanks for responding. I don't have static libraries in my solution - all cppwinrt apps or cppwinrt runtime dlls. Some dlls reference Win2D. I have duplicate errors even for libraries like win2d (non-reference winmds). Not sure how to structure the solution, as I remove win2d upstream, it complains as well. I may have two leaf nodes in my tree of projects refer to win2d and also an intermediate node.

[mediabuff]

what deteremines reference vs non-reference winmds ? in my solution should I link the projects or the winmds generated by projects.

[Scottj1s]

Adding a project reference to a winmd causes it to be referenced by metadata tools like midlrt, mdmerge and cppwinrt, to supply definitions of referenced types. The same is true for dll project references.
Adding a static library project reference causes the metadata to be merged, along with the presumed implementation. This can lead to your error. You can troubleshoot by building with the cppwinrtverbosity property set to 'high', as well as by using the structured build log viewer at msbuildlog.com.

[Scottj1s]

If you can narrow down to a simple repro and publish, I'd be happy to take a look

[mediabuff]

Still looking into this. Could please provide some guidance on how to structure cppwinrt idl files (midlrt 3.0) when you have a necessity for forward declaration. I get duplicate types. I tried to collect all idl include one mega file. But cppwinrt demands idl to be in separate files for boilerplate source to be generated.

// IDialogEventArgsClass.idl
namespace myNamespace
{
	[exclusiveto(DialogEventArgs)]
	interface IDialogEventArgsClass
	{
	}
}

// DialogEventArgs.idl
namespace myNamespace
{
	runtimeclass DialogEventArgs : IDialogEventArgsClass
	{
	}
}

[kennykerr]

The cppwinrt compiler doesn't care how you structure your IDL. All it cares about is that you provide it with a .winmd file to parse.

[Scottj1s]

Try using Import with a shared IDL, like so:

**shared.idl**
namespace App
{
	[contractversion(1)] apicontract SharedContract{};

	[uuid("00000000-0000-0000-0000-000000000000")] 
	[contract(SharedContract, 1)]
	interface IShared
	{
	}
}
	
**class1.idl**
import "shared.idl";

namespace App
{
	[default_interface]
	runtimeclass Class1 : IShared
	{
		Class1();
	}
}

**class2.idl**
import "shared.idl";

namespace App
{
	[default_interface]
	runtimeclass Class2 : IShared
	{
		Class2();
	}
}

[mediabuff]

Thanks for the sample. The provided sample works. I am not sure if this will work when we have forward references in the 'attribute' like [static_name("xxxx")]. In some circumstances, you can't avoid a mega idl file with "include" for each idl.