Join GitHub today
GitHub is home to over 40 million developers working together to host and review code, manage projects, and build software together.Sign up
Support development of Windows Runtime Components #93
Please provide a complete sample for a Windows Runtime Component exposing new public WinRT reference and value types, using just C++/WinRT. Then a consumer in another language, for example a C# console application.
The samples here are just consumers and the producer types are only used inside of those same stand-alone applications, apparently just as COM types (would not work in another language) because you turn off the "Consume Windows Runtime Extension" compiler option, no WINMD file is produced (never a component then).
The closest I found was Kenny Kerr's blog on "C++/WinRT: Consumption and Production" which shows how to create a simple class supporting the "IStringifyable.ToString()" method, but it doesn't work as a component. The class is visible in Object Browser from a referencing C# project but not usable. Attempts to make a C++/WinRT class public generate the error C3988 "a native type cannot be public".
Here is some test code:
Which produces a WINMD with the following visible in Object Browser of a C# project in the same solution:
According to this forum response the one with the maximum version number 255.255.255.255 is the real WINMD component and the other one is Visual Studio internal project reference.
So the only valid "view" in Object Browser was the one with the funny version number, which was empty. None of the C++/WinRT types are visible externally when compiled as a WINMD component. In this current Visual Studio 2015 Update 3 version it seems somehow hardcoded that only a "public ref class" is allowed to be public/exported at the assembly level?
Can you please demonstrate/document the correct combination of a C++ project and settings which workaround these standard project limitations, allowing us to create components with C++/WinRT?
Thanks for the response. As you already planned the feature I'll close this issue.
As I like C++/WinRT so much I've found a happy compromise writing as much of the inner code as possible with this library and just using CX at the "edge". I followed the guidelines in the documentation for working with multiple/conflicting namespaces and it works nicely and is a nice visual reminder (the cx:: or winrt:: prefixes everywhere) for the transition/learning period. Should be an easier conversion later and maybe I still get some performance benefits on the bigger/private functions until then.
Anyway thanks for creating it and I look forward to the updates.