C#/WinRT currently provides support for consuming WinRT APIs through the use of Target Framework Monikers (TFMs) in .NET. Setting the TFM with a specific Windows SDK version adds references to the Windows SDK projection and runtime assemblies generated by C#/WinRT.
Windows Runtime Via C
Starting with C#/WinRT version 1.4.1, support is included for embedding Windows SDK projection and runtime sources for both .NET and .NET Standard 2.0 into your library or app's output. This is useful in cases where usage of Windows SDK types is self-contained. Embedded support removes dependencies on WinRT.Runtime.dll and Microsoft.Windows.SDK.NET.dll which reduces the library or app output size. It also allows library developers to provide downlevel support and removes the need for multi-targeting.
To fix these errors, update your .NET SDK to the latest version. Doing so will ensure that the runtime and Windows SDK assembly versions used by your application are compatible with all dependencies. These errors may occur with early servicing/feature updates to the .NET SDK, because runtime fixes may require updates to our assembly versions.
WinRT support class composition as a runtime inheritance mechanism. However, in this release WinRT does not support definition of a root composable class. Only the root composable classes included in the system in the Windows.* namespace are supported.
A parameterized type instance can appear in any context that a non-parameterized type can appear. A parameterized interface instance may be used anywhere an interface may be used, such as in the list of interfaces implemented by a runtime class. A parameterized delegate instance may be used anywhere a delegate may be used, such as in the definition of an event.
Default_interface must be the interface, p-interface instance, delegate, or p-delegate instance that was specified as default in the runtime class or interface group body, using the IDL '[default]' attribute.
The Version attribute may optionally be applied to interface members (methods, properties, and events). This is intended for high-level class authoring in C#/VB and C++/CX. Version attributes on interface members, even Windows system interface members, must be ignored at runtime by language projections.
Windows system enums and runtime classes are additively versionable. Enums may add new enum values in subsequent Windows releases. Classes may add new implemented interfaces (including static, activation factory, composition factory, overridable, and protected interfaces) in subsequent Windows releases. Further details on additive versioning are included in the sections for enums and runtime classes.
A namespace is a naming scope used to organize code, and to avoid naming collisions. All named types in the WinRT type system (enums, structs, delegates, interfaces, and runtime classes) live in a namespace. A namespace can contain other namespaces.
But neither the WinRT type system nor the ABI has a concept of interface inheritance. So the idea of adding new functionality by implementing new interfaces that inherit from existing interfaces (for example, IFoo2 inherits from IFoo) has no meaning. It is true that a WinRT language projection can use an inheritance relationship for ease of consumption in that particular language, and a runtime class can use inheritance, but interface inheritance doesn't exist in the context of MIDL 3.0 authoring (see MIDL 3.0 interfaces).
WinRT supports array parameters of most WinRT types including fundamental types (including string and guid), structs, enums, delegates, interfaces, and runtime classes. Arrays of other arrays are not allowed.
Runtime classes cannot be parameterized. A runtime class may implement a parameterized interface instance (that is, a parameterized interface with all its type parameters specified) anywhere it would typically accept a non-parameterized interface.
A runtime class may implement zero or more member interfaces. Member interfaces enable classes to expose functionality that is associated with instances of the class. A runtime class specifies a list of the member interfaces it implements. Entries in the list of member interfaces implemented by a runtime class may optionally carry version information. Details on runtime class versioning to follow.
Static interfaces are specified via a StaticAttribute associated with the runtime class. StaticAttribute carries a reference the static interface reference as well as version information. Details on runtime class versioning to follow.
While static interfaces are declared as part of the runtime class, they are actually not implemented on class instances themselves. Rather, they are implemented on the class's activation factory. Details on activation factories to follow.
Classes that support direct activation are activated by calling the IActivationFactory.ActivateInstance method on the class's activation factory. This method takes no parameters, and returns a newly activated instance of the runtime class. Details on activation factories to follow.
At runtime, any composable class code that leverages the overridable interface must QueryInterface for the interface via the controlling IInspectable* pointer that is used for identity and lifetime delegation. This pointer returns the implementation of the overridable interface earliest in the composition chain (that is, closest to the controlling class instance). A class that wishes to access the overridable interfaces of the class it composes may do so via the non-delegating reference that a composable class holds to its composed class.
A runtime class optionally has an activation factory. A runtime class must have an activation factory if the class is activatable, composable, or has static interfaces. The activation factory for a class can be retrieved from the system at runtime via the RoGetActivationFactory Win32 function.
While WinRT is primarily an interface-based programming model under the hood, runtime classes provide a class-based programming model that is better aligned to modern, mainstream, object-oriented (OO) programming languages. Language projections are expected to project a runtime class as a single entity, rather than as a bag of interfaces that the developer has to deal with separately.
To assist in this class-based projection, metadata for runtime classes specify a class member for all the methods, properties, and events from every interface they implement. Every class member is explicitly tied back to the interface member where it was originally defined. This allows language projections to expose the class as a single entity, handling all the interface querying and reference counting under the covers on behalf of the developer.
By default, every implemented interface member is projected as a class member. However, because runtime classes can implement multiple independent interfaces and version over time (versioning details to follow), it is possible for there to be name collisions for members defined on different interfaces implemented by a single runtime class.
In order to resolve method name collisions, runtime classes may specify alternative names for methods on the member and static interfaces they implement. This alternative name is used by the language projection to provide disambiguated access to colliding method names from a class instance. While the runtime class may provide an alternative method name, the method signature, parameters, and any attributes attached to the method or its attributes must still match the original interface definition exactly.
Since direct activation, factory methods, and composition factory methods are projected as class constructors, they are all projected on the runtime class as if they have the same name. All methods across all factory interfaces must have unique signatures, should favor arity-based overloading over type-based overloading, and must use the DefaultOverloadAttribute to disambiguate factory methods of the same arity.
Runtime classes are additively versionable. Subsequent versions of a given runtime class may specify additional interfaces of all types, with further details on individual interface types below. Pre-existing interfaces specified by a class may never be removed or changed without breaking backwards compatibility.
Member interfaces on runtime classes are additively versionable. Subsequent versions of a given runtime class may implement additional member interfaces, even if the class had never implemented member interfaces previously. Subsequent versions of a given composable runtime class may implement additional protected and overridable interfaces.
Interfaces implemented by a runtime class optionally carry the VersionAttribute to distinguish when specific interfaces were added to the runtime class type. Interface implementation values without a VersionAttribute are considered to have the same version value as the enclosing runtime class type.
Static interfaces on runtime classes are additively versionable. Subsequent versions of a given runtime class may implement additional static interfaces, even if the class had never implemented static interfaces previously.
Activation support for runtime classes is additively versionable. Subsequent versions of a given runtime class may implement additional activation mechanisms, even if the class had never implemented an activation mechanism. Note, composable classes are not activatable, and thus may not add activation support.
Composition support for runtime classes is additively versionable. Subsequent versions of a given composable runtime class may implement additional composition mechanisms, provided the class was defined as composable when it was created. Composable classes may not add activation support.
WinRT is not a runtime in a traditional sense but rather a language-independent application binary interface based on COM to allow APIs to be consumed from multiple languages, with services usually provided by a full-blown runtime, such as type activation.[1] Apps using the Windows Runtime may run inside a sandboxed environment to allow greater security and stability and can natively support both x86 and ARM.[2][3] WinRT components are designed with interoperability among multiple languages and APIs in mind, including native, managed and scripting languages. Built-in APIs provided by Windows which use the WinRT ABI are commonly known as WinRT APIs; however, anyone can use the WinRT ABI for their own APIs.
 38c6e68cf9