C++/WinRT support for implementing out-of-proc WinRT servers

[vidager]

Currently, you cannot implement an OOP server without utilizing a hybrid approach with WRL or COM APIs.

It would be helpful if C++/WinRT provided a mechanism similar to WRL::Module that all implemented WinRT objects in the module would integrate with.

Like WRL, covers:

1. Simple object registration
2. Automatic outstanding object ref counting
3. Synchronized COM shutdown and event when all objects have disconnected.

Not supported by WRL (I don't think), but nice to have:

4. A delayed shutdown based on requested "de-bounce" time delay. i.e. trigger shutdown 5min after no objects are connected. Without this, a server can't easily create a shutdown delay. They must take a self-reference and have a way to monitor the module ref count to start the timer when ref hits 1 and reset timer when ref hits 2 or more.

[davidmatson]

We'd love to have this support as well.

Any thoughts on how hard this would be to implement? I'm less familiar with the plumbing for out-of-proc - any pointers to the underlying APIs involved?

[DrusTheAxe]

Any update on this front?

[miniksa]

Oddly enough, this just bit me in the butt today too. It's hard to be hearing "Use CppWinrt and leave WRL behind" when we're missing things like this.

[kennykerr]

It would be great to have a bit more info on what exactly folks are looking for here. Here's a simple client/server that works well enough. This could easily be hosted inside an NT service or some other host but the precise details are unique to each host scenario.

Regarding Ben's points above:

For 1: C++/WinRT has never provided this and instead generates the list from metadata. I doubt we'd start providing this today just for COM. Generally, the list of COM classes should be small. For WinRT classes this isn't an issue.

For 2: This already exists and is extensible for different hosting/lifetime models.

For 3 and 4: This could be built on top of 2.

So, I'm not apposed but it would help if folks can provide more information in terms of requirements. Also, PRs are welcome. This isn't something we've got committed time to work on so if its something that matters to your team feel free to consider a PR. We are of course more than happy to review and provide expert feedback.

[miniksa]

I'm looking for this. But in cppwinrt-speak.

wil::unique_event _comExitEvent;

void _releaseNotifier() {
	_comExitEvent.SetEvent();
}

int CALLBACK wWinMain(HINSTANCE, HINSTANCE, PWSTR, int) {
	_comExitEvent.create();

	auto& module = Microsoft::WRL::Module<OutOfProc>::Create(&_releaseNotifier);

	auto comScope { wil::CoInitializeEx(COINIT_MULTITHREADED)};

	RETURN_IF_FAILED(module.RegisterObjects());
	
	_comExitEvent.wait();

	RETURN_IF_FAILED(module.UnregisterObjects());

	return S_OK;
}

[DrusTheAxe]

I'll go 1 step further: I need Packaged COM OOP Server. Here's the closest docs I could find about it. Or better, follow this for a closer answer.

Not just a .exe provided an OOP server. Yes, a Classic COM OOP Server aka exe. Not a COM Service.
Also requires a Proxy/Stub dll, which means MIDL compiling idl?
And clear docs re what to add to appxmanifest.xml
And ideally, a real world VS solution with 3 projects - (1) OOP exe, (2) Proxy/Stub dll and (3) Make .msix given 1+2+appxmanifest.xml

[ChrisGuzak]

FYI for OS.2020 devs, see this addition to wil that simplifies C++ WinRT WRL integration.

[sylveon]

I'm also personally interested in this - I would like to provide an out of proc WinRT API that allows other programs to send commands to my program. Being in WinRT rather than COM allows easier consumption by managed languages, but being restricted to WRL only for the server implementation makes it harder for me to implement.

Kenny's snippet is interesting, but how would consumers from C# or Rust do to create an instance of the remote object?

[kennykerr]

Feel free to reopen if there's interest in exploring this further.