This repository has been archived by the owner. It is now read-only.

Support development of Windows Runtime Components #93

Closed
CodeChief opened this Issue Jan 28, 2017 · 4 comments

Comments

Projects
None yet
3 participants
@CodeChief

CodeChief commented Jan 28, 2017

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:

// "pch.h" contents:
//
//#pragma once
//#pragma comment(lib, "windowsapp")
//
//#include "winrt/base.h"
//#include "winrt/Windows.Foundation.h"

// "Hello.cpp" contents:

#include "pch.h"

using namespace winrt;
using namespace winrt::Windows::Foundation;

WINRT_EXPORT namespace WindowsRuntimeComponent1
{
	class Hello final : public implements<Hello, IStringable>
	{

	public:

		hstring ToString()
		{
			return L"Hello!";
		}
	};
}

Which produces a WINMD with the following visible in Object Browser of a C# project in the same solution:
image
And it is not usable:
image
Note that in Object Browser the namespace appears twice, the second time with a strange "[255,255,255,255]" suffix. Could that be the problem?

@CodeChief CodeChief changed the title from Windows Runtime Component sample (native type cannot be public) to Windows Runtime Component sample needed Jan 28, 2017

@CodeChief

This comment has been minimized.

Show comment
Hide comment
@CodeChief

CodeChief Jan 29, 2017

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.

For a project-to-project reference, the version would be 0.0.0.0 because the winmd is not even read (Project System only looks at the referenced vcxproj file). When you add a winmd reference directly, you should see 255.255.255.255. At least that's what I am seeing with the RTM build of VS. But either way, version of the actual assembly is not important.

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?

CodeChief commented Jan 29, 2017

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.

For a project-to-project reference, the version would be 0.0.0.0 because the winmd is not even read (Project System only looks at the referenced vcxproj file). When you add a winmd reference directly, you should see 255.255.255.255. At least that's what I am seeing with the RTM build of VS. But either way, version of the actual assembly is not important.

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?

@johanlindfors

This comment has been minimized.

Show comment
Hide comment
@johanlindfors

johanlindfors Jan 30, 2017

I would really like to see this as well. Not only for components to be leveraged by other languages but writing Background Tasks in UWP requires the component to be packaged as a Windows Runtime Component DLL.

I would really like to see this as well. Not only for components to be leveraged by other languages but writing Background Tasks in UWP requires the component to be packaged as a Windows Runtime Component DLL.

@kennykerr

This comment has been minimized.

Show comment
Hide comment
@kennykerr

kennykerr Feb 4, 2017

Contributor

You cannot create WinRT components (producing a dll + winmd) with C++/WinRT today. This will be supported in a future update later this year.

Contributor

kennykerr commented Feb 4, 2017

You cannot create WinRT components (producing a dll + winmd) with C++/WinRT today. This will be supported in a future update later this year.

@CodeChief CodeChief changed the title from Windows Runtime Component sample needed to Support development of Windows Runtime Components Feb 4, 2017

@CodeChief

This comment has been minimized.

Show comment
Hide comment
@CodeChief

CodeChief Feb 4, 2017

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.

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.

Sign up for free to subscribe to this conversation on GitHub. Already have an account? Sign in.