Shmuelie.WinRTServer 1.1.1

The ID prefix of this package has been reserved for one of the owners of this package by NuGet.org. Prefix Reserved
This package has a SemVer 2.0.0 package version: 1.1.1+4cc819944aba05275c43dac39e259309bc7bda77.
There is a newer version of this package available.
See the version list below for details.
dotnet add package Shmuelie.WinRTServer --version 1.1.1
NuGet\Install-Package Shmuelie.WinRTServer -Version 1.1.1
This command is intended to be used within the Package Manager Console in Visual Studio, as it uses the NuGet module's version of Install-Package.
<PackageReference Include="Shmuelie.WinRTServer" Version="1.1.1" />
For projects that support PackageReference, copy this XML node into the project file to reference the package.
paket add Shmuelie.WinRTServer --version 1.1.1
#r "nuget: Shmuelie.WinRTServer, 1.1.1"
#r directive can be used in F# Interactive and Polyglot Notebooks. Copy this into the interactive tool or source code of the script to reference the package.
// Install Shmuelie.WinRTServer as a Cake Addin
#addin nuget:?package=Shmuelie.WinRTServer&version=1.1.1

// Install Shmuelie.WinRTServer as a Cake Tool
#tool nuget:?package=Shmuelie.WinRTServer&version=1.1.1

Out-of-Process WinRT/COM Server

.NET NuGet NuGet

What is it?

The Component Object Model (COM) API that underlines .NET and the Windows Runtime supports the concept of Out Of Process (OOP) Servers. This allows for using objects that are in a different process (or even a different machine) as though they were in the local process. This library adds APIs to make the process of creating the "server" in .NET much easier.

Note: COM and Windows Runtime are Windows only.

Why?

Cross Language

Because this uses COM/WinRT for the communication any language that can use COM can use this library. As an example of this, the sample includes a simple C++ console application that talks to the .NET/C# server.

Complex Types

Most RPC/ICP systems are just sending messages between the two processes. At most they can serialize an object graph. COM allows for more complicated objects, where the returned types can have methods, events, and properties. If you could do it with a local object, you can do it with a remote object. The samples include using most of these abilities, including having the remote process load a file as a stream and having the local process use the stream without having to send the whole file across.

Built in Support for Types

Many of the types you are used to using are supported out of the box like collection types, map types, streams, etc. This allows you to not have to worry about how the IPC works.

Usage

Currently to create an Out-of-Process server requires the C++/WinRT tooling (though no actual C++ code) and a "contract" project. These two limitations will be removed in a future version of the library.

Contract Project

The contract project is a C# project that contains the interfaces of the remote objects. Output is a WinMD that is referenced by the other projects. The interfaces have some rules:

  1. The interface must have a GUID assigned using the Windows.Foundation.Metadata.GuidAttribute attribute, not the System.Runtime.InteropServices.GuidAttribute attribute.

  2. Asynchronous methods must use the WinRT types (IAsyncAction, IAsyncActionWithProgress<TProgress>, IAsyncOperation<TResult>, IAsyncOperationWithProgress<TResult, TProgress>) instead of Task and Task<T>.

  3. Event delegates must be either TypedEventHandler<TSender, TResult> or EventHandler<TResult> instead of EventHandler and EventHandler<T>.

  4. Types in method parameters, type parameters, and return types must be:

    • A blittable type.
    • An interface that has a .NET/WinRT Mapping.
    • A WinRT type.
    • Another interface in the project.
  5. Methods, properties, and events are all supported.

Metadata Project

The metadata project is a C++/WinRT project that uses MIDL 3.0 to create proxy types in a WinMD that can be referenced by the client of the OOP Server. No actual C++ code is needed, only the IDL.

The IDL is very simple, only needing runtimeclasses that implement the interface from the contract project. Unlike in C#, in MIDL 3.0 the type automatically has the members from the interface so they do not need to be listed again. Importantly the runtimeclass must have an empty constructor, otherwise the proxy type cannot be created.

Important: Because of the mix of SDK Style and C++/WinRT, nuget restore is needed to restore for C++/WinRT. In addition <RestoreProjectStyle>Packages.config</RestoreProjectStyle> is needed in the C++ project file.

Server Project

The server project is the only project that references Shmuelie.WinRTServer. It will contain implementations of the interfaces from the contract and when run should register them with an instance of COMServer for COM activation and WinRtServer for WinRT activation. The implementations must have a GUID using the System.Runtime.InteropServices.GuidAttribute attribute.

Because the interfaces must use the WinRT asynchronous types instead of the .NET ones, the implementation will likely need to use AsyncInfo to help adapt between the two systems.

Client Project

A client can be both full trust applications (Win32, WPF, WinForms, etc) or a UWP app.

A UWP client cannot use WinRT activation and must use COM style activation. The UWP sample app shows how to do this. To understand the details behind it, see this blog post.

A full trust client can use WinRT activation, which allows you to create the remote instances simply by new SomeType(), like you would for any other type. The sample WPF application shows this in action (using with WinForms would be similar).

Sample

To help understand usage, a sample using a UWP client app, and WPF app, and a C++ console app is included under the test directory. Simply run the Shmuelie.WinRTServer.Sample.Package project to see it in action.

Note: If Visual Studio fails to build the Metadata project restarting Visual Studio should fix the problem.

Product Compatible and additional computed target framework versions.
.NET net5.0 was computed.  net5.0-windows was computed.  net6.0 is compatible.  net6.0-android was computed.  net6.0-ios was computed.  net6.0-maccatalyst was computed.  net6.0-macos was computed.  net6.0-tvos was computed.  net6.0-windows was computed.  net7.0 was computed.  net7.0-android was computed.  net7.0-ios was computed.  net7.0-maccatalyst was computed.  net7.0-macos was computed.  net7.0-tvos was computed.  net7.0-windows was computed.  net8.0 was computed.  net8.0-android was computed.  net8.0-browser was computed.  net8.0-ios was computed.  net8.0-maccatalyst was computed.  net8.0-macos was computed.  net8.0-tvos was computed.  net8.0-windows was computed. 
.NET Core netcoreapp2.0 was computed.  netcoreapp2.1 was computed.  netcoreapp2.2 was computed.  netcoreapp3.0 was computed.  netcoreapp3.1 was computed. 
.NET Standard netstandard2.0 is compatible.  netstandard2.1 was computed. 
.NET Framework net461 was computed.  net462 was computed.  net463 was computed.  net47 was computed.  net471 was computed.  net472 was computed.  net48 was computed.  net481 was computed. 
MonoAndroid monoandroid was computed. 
MonoMac monomac was computed. 
MonoTouch monotouch was computed. 
Tizen tizen40 was computed.  tizen60 was computed. 
Xamarin.iOS xamarinios was computed. 
Xamarin.Mac xamarinmac was computed. 
Xamarin.TVOS xamarintvos was computed. 
Xamarin.WatchOS xamarinwatchos was computed. 
Compatible target framework(s)
Included target framework(s) (in package)
Learn more about Target Frameworks and .NET Standard.

NuGet packages

This package is not used by any NuGet packages.

GitHub repositories

This package is not used by any popular GitHub repositories.

Version Downloads Last updated
1.2.0 76 1/10/2024
1.1.1 98 3/10/2023
1.1.0 85 2/23/2023
1.0.0 85 1/29/2023

Fixed lifetime management bug.