C++/WinRT in the Windows SDK

The first step toward full C++/WinRT support within Visual Studio and the eventual retirement of C++/CX happened today with the availability of build 17025 of the Windows SDK Insider Preview. With this update it means that you no longer need to download or clone the C++/WinRT repo on GitHub and can simply #include the appropriate headers from within any C++ project. What this also means is that you no longer need to wait for us to update GitHub following the release of a new Windows SDK. Indeed, we will no longer be publishing the updated headers on GitHub at all since you can get them directly from the Windows SDK.

If you look inside the Windows SDK include folder for build 17025 you’ll notice a new cppwinrt folder.

As full Visual Studio integration is still on the way, there are a few things you need to be mindful of. First, you need to make sure that the Windows SDK Version in the project is set to 17025 or later. New projects will default to this, but existing projects may need to be updated.

Second, C++/WinRT relies on C++17 language features and as such you need to tell Visual C++ that your project requires the C++17 language standard. This may soon be the default as well.

At this point, you can simply #include any of the C++/WinRT headers and start writing code! 🙂

If you prefer, you can also link to the windowsapp lib via the project settings rather than the pragma above.

Building from the command prompt won’t work yet as Visual Studio itself needs an update to pick up the cppwinrt folder.

Unfortunately, the cppwinrt.exe tool itself did not make it into this build of the Windows SDK. You should expect that in the next update, hopefully later this month. At that point you will also have the ability to generate your own headers and try the experimental support for component authoring. Until then, I hope you enjoy the new Windows SDK experience.

13 thoughts on “C++/WinRT in the Windows SDK

  1. matt

    Oh, I’m a little sad that this means the GitHub repo will be deprecated. I was under the impression that cppwinrt will be an opensource project. I understand that 90% of it is just projection of the current SDK, but there’s still value in building excitement for it through the opensource community.

    Reply
    1. Kenny Kerr Post author

      We’re not giving up on GitHub or open source. Today we only publish the headers produced by the cppwinrt.exe compiler as well as some samples on GitHub. The samples will remain, but the headers will be available through the Windows SDK. In future, we’d like to open source the cppwinrt.exe compiler itself. That would naturally find its way on to GitHub as well.

      Reply
  2. jerrywiltse

    Great stuff! Question, is there a fundamental reason why the windows sdk, driver sdk, and others have to be released as proprietary executable/installers? Are there reasons it can never be packaged and delivered via package managers like other libraries?

    Reply
      1. jerrywiltse

        Thanks for forwarding it along. Since I posted, I spent a day trying to package it, but I realized that as long as it’s an MSI, it’s unadvisable. I might have been able to to get things reasonably automated, and get the package to capture all the apparent source and header files. However, even if I did, there’s no way to tell what unforeseen pitfalls await users due to missing “magic” that the installer does that I might not (I.E. in registry/environment variables/user profile/etc). With something this big, if it’s not canonical from the vendor, it represents a risk. If you don’t mind, it would be great if you could copy Robert Schumacher from the VCPKG team on that communication. I believe that within Microsoft, he probably has the best handle on the C/C++ packaging landscape right now, and what the community would need to make the SDK open to different packagers.

  3. Steven

    Any chance this will become available for us developers using Win10 IoTE Enterprise (1607) or Windows 10 Server 2016?

    Reply
    1. Kenny Kerr Post author

      You should be able to use the newer SDK to target older versions of Windows 10. Although the Insider SDKs will only install on Insider builds of Windows, you can copy the project and headers (from GitHub for example) onto any Windows 10 machine running Visual Studio 2017 and it should work just fine.

      Reply
  4. Michael

    Great stuff, Kenny! Can you please extend the AppServiceBridgeSample on Git (https://github.com/Microsoft/DesktopBridgeToUWP-Samples/tree/master/Samples/AppServiceBridgeSample). I think C++/WinRT will be an essential part of this bridge as existing C++-Win32-Applications can bridge into the new world (e. g. without giving up static linking the VC-Runtime as before with managed C++/CX).

    I tried my best to get the sample running. So far I got the connection from the UWP-Process but my successfully registered event handlers are not called. The UWP process then crashes because the response contains no string.

    Another problem: the following co_await line doesn’t compile …
    void RequestReceived(AppServiceConnection connection, AppServiceRequestReceivedEventArgs args)
    {
    AppServiceRequest request = args.Request();

    AppServiceResponseStatus status = co_await request.SendResponseAsync(response);

    }

    The compiler throws this error:
    error C2039: ‘promise_type’: is not a member of ‘std::experimental::coroutine_traits<…

    Reply
    1. Kenny Kerr Post author

      The compiler error has to do with the fact that you have a co_await expression inside a function that’s not a coroutine. You need to use a coroutine type, such as Windows::Foundation::IAsyncAction, for that to work.

      Regarding Desktop Bridge, I have been meaning to put a sample together. This is a popular request and I’ll hopefully get to it soon.

      Reply
      1. Michael

        I see, so IAsyncAction is somehow comparable to the async keyword in C#? After return IAsyncAction it compiled fine.

        And thanks to your help I actually got it working! The problem was that I was handling the result of the event handler registration in a wrong way (I only stored the event_token). So what I do now is:

        AppServiceConnection connection;

        myStuff.requestReceivedToken = connection.RequestReceived(winrt::auto_revoke, RequestReceived);

        One problem that I encountered: as the event_revoker has an operator bool() I should be able to do this:
        if(myStuff.requestReceivedToken)
        wcout << “Successfully registered requestReceivedToken.” << endl;

        but I got this compile error:
        binary ‘!=’: no operator found which takes a left-hand operand of type ‘const winrt::weak_ref

        Again, thank you very much for the help!

        BTW, is it better to ask such question as an issue of the cppwinrt GitHub-Repo?

Leave a Reply

Fill in your details below or click an icon to log in:

WordPress.com Logo

You are commenting using your WordPress.com account. Log Out / Change )

Twitter picture

You are commenting using your Twitter account. Log Out / Change )

Facebook photo

You are commenting using your Facebook account. Log Out / Change )

Google+ photo

You are commenting using your Google+ account. Log Out / Change )

Connecting to %s