What is a Windows Runtime component?

When creating a new assembly in a visual studio we have two choices:

Or a classical class library

Either a Windows Runtime component.

Original illustration unavailable: Type of dll

A Windows Runtime component is typically used to share code written in a language other than the one used.

For example, a Windows Runtime component can be written to:

when one wants native performance using C++ for video encoding, and sharing this component with other languages like C#, Vb.NET or WinJS...

When creating Background task it is mandatory to write a Windows Runtime component.

Opinions on the limitations of Windows Runtime components

However, these components to be interoperable with all languages have a number of important limitations, the most binding for a C# developer being:

All classes declared in this component must be sealed*

All members public class must be compatible with other languages, so you can't expose a function returning a task for example.

* Class cannot be inherited.

So that means I can never use asyncs/await in my component?

False If your methods are private you can use the full power of C#/VB.NET without any limitations.


    public sealed class ToastTask : IBackgroundTask
    {

        public void Run(IBackgroundTaskInstance taskInstance)
        {
            BackgroundTaskDeferral deferral = taskInstance.GetDeferral();
            ToastThemAll(deferral);
        }

        private async void ToastThemAll(BackgroundTaskDeferral deferral)
        {
               var api = new MyApi();
               var rep await = api.GetData();
               ...
        }

Can I use PCL dll in a Windows runtime component?

Yes, you can perfectly share your code between a PCL DLL that declares your calls to an API

Performance and Windows runtime component

Be aware that using a Windows runtime component in your code can have a significant impact on performance.

The MSDN documentation explains that whenever a component is used, it is converted.

Every time you access a property or call a method on a Windows Runtime component, you incur an interoperability cost. Creating a Windows Runtime object is more resource-intensive than creating a .NET object because calls must cross the boundary between the application and the component. Data passed to the component must also be converted between managed and unmanaged types.

I decided to do a simple collection creation test to prove what the MSDN said.

If I create a collection in a Windows Runtime component and I use it in an app, the creation is between 10% and 30% slower, yet it's the same function...


 public IEnumerable<Data> GetData()
 {
     int count = 100000;
     List<Data> data = new List<Data>();
     for (int i = 0; i < count; i++)
     {
            data.Add(new Data() { Index = i, Name = "Name" + i.ToString() });
     }
     return data;
 }

Using a decompiler we can get a little idea.


public extern IIterable<Data> GetData();

An interface is generated for each public class.


	internal interface IDataClass
	{
		int Index
		{
			[CompilerGenerated]
			get;
			[CompilerGenerated]
			set;
		}
		string Name
		{
			[CompilerGenerated]
			get;
			[CompilerGenerated]
			set;
		}
	}

So when you write an app entirely in C# You'd rather share your code with your Windows runtime components than vice versa.

Rather than using code in your Windows runtime component.

In C# applications, use .NET APIs as often as possible.

Mixing the two APIs with those of Windows Runtime greatly degrades performance.

APIs starting with: Windows.Data are Windows Runtime components

Whereas systems are .NET APIs.

For example, it is best to use:

System.Xml.XmlReader that Windows.Data.Xml.Dom.XmlDocument to avoid the overhead of conversion to .NET.

Copy window runtime objects into .NET types

The MSDN strongly recommends copying items returned by components into .NET types before using them, including all collections before iterating them.

Try to make as few calls as possible to Windows Runtime objects

The MSDN recommends making as few calls as possible to Windows Runtime objects.

Because every call is addictive because there's automatic type conversion for your language.

The example I gave above confirms that even if the Windows Runtime component is written in the same language there is a conversion...

Sources

  1. Creating Windows Runtime components
  2. Best practice when using a Windows runtime component

Thankfulness

Thank you. Toss net For the reading.