Feature proposal
Please add a plain C++/WinRT Runtime Class item template for WinUI / Windows App SDK C++ projects.
The existing C++/WinRT WinUI item templates are primarily XAML UI concepts, such as:
- Page
- User Control
- Templated Control
but there is no convenient Add New Item template for creating an ordinary WinRT runtimeclass inside an existing WinUI C++ project.
Why Templated Control is not a replacement
A Templated Control represents a specific XAML control pattern:
runtimeclass MyControl : Microsoft.UI.Xaml.Controls.Control
{
MyControl();
}It is expected to have:
and a default Style / ControlTemplate, usually placed in Themes/Generic.xaml. That behavior is correct for a real custom Control.
However, many WinRT types used by a WinUI application are not templated Controls.
Examples include:
- attached-property providers;
- markup-extension-like runtime classes;
- DependencyObject-derived helper types;
- XAML-facing model or collection types;
- Composition/XAML effect types;
- ordinary WinRT runtime classes;
- helper runtime classes that need metadata visibility but no visual template.
For example:
namespace MyApp.UI.Xaml.Markup
{
runtimeclass UInt32Extension
{
UInt32Extension();
}
}or:
namespace MyApp.UI.Xaml.Control.Effect
{
runtimeclass AnimatedValue
{
AnimatedValue();
String Value;
}
}These types need the normal C++/WinRT component implementation pattern, but they do not need a ControlTemplate, DefaultStyleKey, or modifications to Themes/Generic.xaml.
Using the Templated Control item as a starting point therefore creates XAML-control-specific artifacts which have to be manually removed.
Proposed item
For example:
or:
Windows Runtime Class (C++/WinRT)
The item would generate:
MyType.idl
MyType.h
MyType.cpp
with a standard C++/WinRT producing-component skeleton.
Conceptually:
namespace MyProject.Some.Namespace
{
runtimeclass MyType
{
MyType();
}
}#pragma once
#include "<correct-generated-component-path>.g.h"
namespace winrt::MyProject::Some::Namespace::implementation
{
struct MyType : MyTypeT<MyType>
{
MyType();
};
}and:
#include "pch.h"
#include "MyType.h"
#if __has_include("<correct-generated-component-path>.g.cpp")
#include "<correct-generated-component-path>.g.cpp"
#endif
Project subfolders should be supported
The template should also correctly support Add New Item from a nested project folder.
For example:
MyProject
└─ UI
└─ Xaml
└─ Markup
└─ Add > New Item > C++/WinRT Runtime Class
with the user entering only:
should produce the runtime type:
MyProject.UI.Xaml.Markup.UInt32Extension
while keeping the physical filenames as:
UInt32Extension.idl
UInt32Extension.h
UInt32Extension.cpp
This is related to: #6688 , which tracks the existing C++/WinRT item templates incorrectly handling namespace/generated-file paths for items created in project subfolders.
XAML integration
A plain runtimeclass item should not automatically create a XAML file or a default style.
If the runtimeclass is later consumed by XAML, the existing XAML metadata pipeline should discover it through its normal WinRT/XAML type metadata mechanisms.
XAML-specific resources should only be generated by item types that actually require them.
C++/WinRT 3.x compatibility
If possible, the new item should also be compatible with both:
- traditional C++/WinRT projection headers;
- C++/WinRT 3.x C++20 module-enabled projects.
This does not necessarily mean the item template itself has to implement the entire XAML/module integration story, but it should not assume that all projects use only textual #include <winrt/...> projections.
Feature proposal
Please add a plain C++/WinRT Runtime Class item template for WinUI / Windows App SDK C++ projects.
The existing C++/WinRT WinUI item templates are primarily XAML UI concepts, such as:
but there is no convenient Add New Item template for creating an ordinary WinRT runtimeclass inside an existing WinUI C++ project.
Why Templated Control is not a replacement
A Templated Control represents a specific XAML control pattern:
It is expected to have:
DefaultStyleKey(...)and a default
Style/ControlTemplate, usually placed inThemes/Generic.xaml. That behavior is correct for a real custom Control.However, many WinRT types used by a WinUI application are not templated Controls.
Examples include:
For example:
namespace MyApp.UI.Xaml.Markup { runtimeclass UInt32Extension { UInt32Extension(); } }or:
namespace MyApp.UI.Xaml.Control.Effect { runtimeclass AnimatedValue { AnimatedValue(); String Value; } }These types need the normal C++/WinRT component implementation pattern, but they do not need a
ControlTemplate,DefaultStyleKey, or modifications toThemes/Generic.xaml.Using the Templated Control item as a starting point therefore creates XAML-control-specific artifacts which have to be manually removed.
Proposed item
For example:
or:
The item would generate:
with a standard C++/WinRT producing-component skeleton.
Conceptually:
namespace MyProject.Some.Namespace { runtimeclass MyType { MyType(); } }and:
Project subfolders should be supported
The template should also correctly support Add New Item from a nested project folder.
For example:
with the user entering only:
should produce the runtime type:
while keeping the physical filenames as:
This is related to: #6688 , which tracks the existing C++/WinRT item templates incorrectly handling namespace/generated-file paths for items created in project subfolders.
XAML integration
A plain runtimeclass item should not automatically create a XAML file or a default style.
If the runtimeclass is later consumed by XAML, the existing XAML metadata pipeline should discover it through its normal WinRT/XAML type metadata mechanisms.
XAML-specific resources should only be generated by item types that actually require them.
C++/WinRT 3.x compatibility
If possible, the new item should also be compatible with both:
This does not necessarily mean the item template itself has to implement the entire XAML/module integration story, but it should not assume that all projects use only textual
#include <winrt/...>projections.