Open partmachine opened 2 years ago
@partmachine is there a reason for not using the global projection support (not using CsWinRTEmbedded=true)? Embedded projections require the types to be internal today. We'd like to understand your scenario better, and your reasons for choosing the embedded projection option.
@partmachine I think you'd want them to be internal in a class library or you'll likely hit collision issues with consumers of your library also generating winrt types or referencing the nuget packages that gives access to all the Windows APIs.
is there a reason for not using the global projection support (not using CsWinRTEmbedded=true)? Embedded projections require the types to be internal today. We'd like to understand your scenario better, and your reasons for choosing the embedded projection option.
@angelazhangmsft A primary reason for me would be to support generating the interop as a distinct DLL that is then used by an application. This is especially important for components where the winmd isn't publicly distributed, so we need to include the code in an app, and potentially some unit tests of the interop itself. (Current "workaround" is to use "Internals Visible To" support to make them accessible for some consumers, but that's a major pain.
When I generate a projection library with CsWinRTEmbedded=true all the projected types from my c++/winrt component are defined as internal and so not visible to any consumers. Is there any way to generate these types as public so I don' have to provide an additional wrapper class?