microsoft / CsWinRT

C# language projection for the Windows Runtime
MIT License
554 stars 107 forks source link

Generated classes in embedded projection library are not public #1143

Open partmachine opened 2 years ago

partmachine commented 2 years ago

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?

angelazhangmsft commented 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.

dotMorten commented 2 years ago

@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.

smaillet-ms commented 2 years ago

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.