Windows APP sdk unpackaged

[Azhang74]

Describe the bug

I have a project ,when I build with package settings,it run well,but i modify .vcxprj file as followsing 👍

<MinimumVisualStudioVersion>16.0</MinimumVisualStudioVersion>
	<AppContainerApplication>false</AppContainerApplication>
    <AppxPackage>false</AppxPackage>
    <ApplicationType>Windows Store</ApplicationType>
    <ApplicationTypeRevision>10.0</ApplicationTypeRevision>
    <WindowsTargetPlatformVersion>10.0</WindowsTargetPlatformVersion>
    <WindowsTargetPlatformMinVersion>10.0.17763.0</WindowsTargetPlatformMinVersion>
    <UseWinUI>true</UseWinUI>
 <EnableMsixTooling>true</EnableMsixTooling>
	<WindowsPackageType>None</WindowsPackageType>

When I debug App , then
Unhandled exception at 0x00007FFA4D28474C in HydraulicRobotHMI.exe: Microsoft C++ exception: winrt::hresult_class_not_registered at memory location 0x00000010797BF1A8.

In call stack ,error in the function:

	Microsoft::UI::Xaml::DependencyProperty AixsParameterControl::m_AxisDescProperty =
		Microsoft::UI::Xaml::DependencyProperty::Register(L"AxisDesc",
			winrt::xaml_typename<winrt::hstring>(),
			winrt::xaml_typename<HydraulicRobotHMI::AixsParameterControl>(),
			Microsoft::UI::Xaml::PropertyMetadata{ winrt::box_value(L""), nullptr });
m_AxisDescProperty is declared:
		static Microsoft::UI::Xaml::DependencyProperty m_AxisDescProperty;

Steps to reproduce the bug

1. when build packaged app ,it is OK.
2. when modify .vcxprj file as ：

<AppxPackage>false</AppxPackage>
<WindowsPackageType>None</WindowsPackageType>

rebuild App ，it does'nt run!

Expected behavior

No response

Screenshots

No response

NuGet package version

1.1.4

Packaging type

Unpackaged

Windows version

Windows 11 version 21H2 (22000)

IDE

Visual Studio 2022

Additional context

No response

[DarranRowe]

This error kind of reminds me of what happens when you attempt to use a WinRT component without properly referencing it.
So just to be sure, is this true? If this is something that you are setting as a dependency in your appxmanifest file then you cannot just directly try to load it.
If HydraulicRobotHMI is a package that can be found using the Get-AppxPackage then try using the Dynamic Dependency API to load it. If you have the .dll and .winmd file along side your executable then you are going to have to try using Registration Free WinRT.

[Azhang74]

HydraulicRobotHMI is my project name.

[Azhang74]

I think that The C++/winRT or Windows App SDK has a bug when Set project to <WindowsPackageType>None</WindowsPackageType> unpackaged

[DarranRowe]

The issue here is that the application being unpackaged doesn't naturally cause this kind of problem.
As you can see with this youtube video, a custom control by itself even with a dependency object works. If you want the source code to see for yourself then I have no issues making it available.
So your problem is linked to what your project is doing, but you are not showing this.

[DrusTheAxe]

Is HydraulicRobotHMI a WinRT component? Is it in you project or an MSIX package?

What you'd need to make it available to your app at runtime differs between them

Your project used to make a packaged app and now it's making an unpackaged app? When you were packaged did you have any <Dependencies> in your appxmanifest.xml? Did you declare any WinRT objects e.g. <Extension Category="windows.activatableClass.inProcessServer"> or OOP servers?

[Azhang74]

@DarranRowe @DrusTheAxe thanks!

1. I create a userControl(name :AxisParameterControl) in my project(name:HydraulicRobotHMI).
2. The userControl have five DependencyProperty:

 #pragma once

#include "winrt/Microsoft.UI.Xaml.h"
#include "winrt/Microsoft.UI.Xaml.Markup.h"
#include "winrt/Microsoft.UI.Xaml.Controls.Primitives.h"
#include "AixsParameterControl.g.h"

namespace winrt::HydraulicRobotHMI::implementation
{
    struct AixsParameterControl : AixsParameterControlT<AixsParameterControl>
    {
		AixsParameterControl();

		hstring AxisDesc();
		void AxisDesc(hstring const& value);
		hstring MeasureValue();
		void MeasureValue(hstring const& value);
		hstring TargetValue();
		void TargetValue(hstring const& value);
		int32_t OperateMode();
		void OperateMode(int32_t value);
		bool ToleranceOne();
		void ToleranceOne(bool value);
		bool ToleranceTwo();
		void ToleranceTwo(bool value);

		static Microsoft::UI::Xaml::DependencyProperty AxisDescProperty();
		static void AxisDescProperty(Microsoft::UI::Xaml::DependencyProperty const& value);
		static Microsoft::UI::Xaml::DependencyProperty MeasureValueProperty();
		static void MeasureValueProperty(Microsoft::UI::Xaml::DependencyProperty const& value);
		static Microsoft::UI::Xaml::DependencyProperty TargetValueProperty();
		static void TargetValueProperty(Microsoft::UI::Xaml::DependencyProperty const& value);
		static Microsoft::UI::Xaml::DependencyProperty OperateModeProperty();
		static void OperateModeProperty(Microsoft::UI::Xaml::DependencyProperty const& value);
		static Microsoft::UI::Xaml::DependencyProperty ToleranceOneProperty();
		static void ToleranceOneProperty(Microsoft::UI::Xaml::DependencyProperty const& value);
		static Microsoft::UI::Xaml::DependencyProperty ToleranceTwoProperty();
		static void ToleranceTwoProperty(Microsoft::UI::Xaml::DependencyProperty const& value);

		//

	private:
		static Microsoft::UI::Xaml::DependencyProperty m_AxisDescProperty;
		static Microsoft::UI::Xaml::DependencyProperty m_MeasureValueProperty;
		static Microsoft::UI::Xaml::DependencyProperty m_TargetValueProperty;
		static Microsoft::UI::Xaml::DependencyProperty m_OperateModeProperty;
		static Microsoft::UI::Xaml::DependencyProperty m_ToleranceOneProperty;
		static Microsoft::UI::Xaml::DependencyProperty m_ToleranceTwoProperty;
	};
}

namespace winrt::HydraulicRobotHMI::factory_implementation
{
    struct AixsParameterControl : AixsParameterControlT<AixsParameterControl, implementation::AixsParameterControl>
    {
    };
}

//AxisParameterControl.xaml.cpp
namespace winrt::HydraulicRobotHMI::implementation
{
	Microsoft::UI::Xaml::DependencyProperty AixsParameterControl::m_AxisDescProperty =
		Microsoft::UI::Xaml::DependencyProperty::Register(L"AxisDesc",
			winrt::xaml_typename<winrt::hstring>(),
			winrt::xaml_typename<HydraulicRobotHMI::AixsParameterControl>(),
			Microsoft::UI::Xaml::PropertyMetadata{ winrt::box_value(L""), nullptr }
	);
	Microsoft::UI::Xaml::DependencyProperty AixsParameterControl::m_MeasureValueProperty =
		Microsoft::UI::Xaml::DependencyProperty::Register(L"MeasureValue",
			winrt::xaml_typename<winrt::hstring>(),
			winrt::xaml_typename<HydraulicRobotHMI::AixsParameterControl>(),
			Microsoft::UI::Xaml::PropertyMetadata{ winrt::box_value(L""), nullptr }
	);

	Microsoft::UI::Xaml::DependencyProperty AixsParameterControl::m_TargetValueProperty =
		Microsoft::UI::Xaml::DependencyProperty::Register(L"TargetValue",
			winrt::xaml_typename<winrt::hstring>(),
			winrt::xaml_typename<HydraulicRobotHMI::AixsParameterControl>(),
			Microsoft::UI::Xaml::PropertyMetadata{ winrt::box_value(L""), nullptr }
	);

	Microsoft::UI::Xaml::DependencyProperty AixsParameterControl::m_OperateModeProperty =
		Microsoft::UI::Xaml::DependencyProperty::Register(L"OperateMode",
			winrt::xaml_typename<int32_t>(),
			winrt::xaml_typename<HydraulicRobotHMI::AixsParameterControl>(),
			Microsoft::UI::Xaml::PropertyMetadata{ winrt::box_value(0), nullptr }
	);

	Microsoft::UI::Xaml::DependencyProperty AixsParameterControl::m_ToleranceOneProperty =
		Microsoft::UI::Xaml::DependencyProperty::Register(L"ToleranceOne",
			winrt::xaml_typename<bool>(),
			winrt::xaml_typename<HydraulicRobotHMI::AixsParameterControl>(),
			Microsoft::UI::Xaml::PropertyMetadata{ winrt::box_value(false), nullptr }
	);

	Microsoft::UI::Xaml::DependencyProperty AixsParameterControl::m_ToleranceTwoProperty =
		Microsoft::UI::Xaml::DependencyProperty::Register(L"ToleranceTwo",
			winrt::xaml_typename<bool>(),
			winrt::xaml_typename<HydraulicRobotHMI::AixsParameterControl>(),
			Microsoft::UI::Xaml::PropertyMetadata{ winrt::box_value(false), nullptr }
	);

I build the project package ,the program run successfully.
When I Set theses settings in HydraulicRobotHMI.vcxproj file

<AppxPackage>false</AppxPackage>
<WindowsPackageType>None</WindowsPackageType>

build is OK,but when run the program ,these error arise：
Unhandled exception at 0x00007FFA4D28474C in HydraulicRobotHMI.exe: Microsoft C++ exception: winrt::hresult_class_not_registered at memory location 0x00000010797BF1A8.

In call stack ,error in the function:

```

Microsoft::UI::Xaml::DependencyProperty AixsParameterControl::m_AxisDescProperty =
Microsoft::UI::Xaml::DependencyProperty::Register(L"AxisDesc",
winrt::xaml_typenamewinrt::hstring(),
winrt::xaml_typenameHydraulicRobotHMI::AixsParameterControl(),
Microsoft::UI::Xaml::PropertyMetadata{ winrt::box_value(L""), nullptr });

[DrusTheAxe]

Sounds like your WinRT components were declared in your appxmanifest.xml when you were a packaged app, but unpackaged apps don't have an appxmanifest so that's not used and thus Windows isn't told your WinRT objects exist.

There's only 2 ways for Windows to find your WinRT components

1. Declare in appxmanifest.xml (i.e. your MSIX manifest)
2. Declare in app.manifest (i.e. your Fusion manifest)

#1 only works for packaged apps (unpackaged apps have no appxmanifest)

#2 works for all apps (packaged and not), thanks to RegFreeWinRT. The syntax are different but similar.

FYI here's an XSLT that converts WinRT registrations from an MSIX manifest to a Fusion manifest:

<?xml version="1.0"?>

<xsl:stylesheet version="1.0" xmlns:xsl="http://www.w3.org/1999/XSL/Transform" xmlns:ms="http://schemas.microsoft.com/appx/manifest/foundation/windows10">

<xsl:output method="xml" version="1.0" encoding="UTF-8" indent="yes"/>

<xsl:param name="ApplicationName" />

<xsl:template match="/">
  <assembly xmlns="urn:schemas-microsoft-com:asm.v1" manifestVersion="1.0">
    <xsl:for-each select="ms:Package/ms:Extensions/ms:Extension">
      <file>
        <xsl:attribute name="name">
          <xsl:value-of select="ms:InProcessServer/ms:Path" />
        </xsl:attribute>
        <xsl:for-each select="ms:InProcessServer/ms:ActivatableClass">
          <activatableClass xmlns="urn:schemas-microsoft-com:winrt.v1">
            <xsl:attribute name="name">
              <xsl:value-of select="@ActivatableClassId" />
            </xsl:attribute>
            <xsl:attribute name="threadingModel">
              <xsl:value-of select="@ThreadingModel" />
            </xsl:attribute>
          </activatableClass>
        </xsl:for-each>
      </file>
    </xsl:for-each>
  </assembly>
</xsl:template>

</xsl:stylesheet>

and a powershell snippet to use (pretty basic)

# $msix = MSIX manifest to read (appxmanifest.xml)
# $fusion = Fusion manifest to write (e.g. app.manifest)
New-Item -ItemType Directory -Force -Path $msix;
$xslt = New-Object System.Xml.Xsl.XslCompiledTransform;
$xslt.Load('TransformAppxManifest.xslt');
$xslt.Transform($msix, $fusion);

You can do that and copy/paste the resulting bits into your unpackaged app project's app.manifest.

Do you only run on 19H1+ (10.0.18362.0) or also need to run on RS5 (10.0.17763.0)? If the latter you'll need to do 1 more thing for this to work.

[DarranRowe]

Well, after sitting down and following the steps that you stated exactly, I now know what the issue is.
It isn't a Windows App SDK/WinUI 3 bug. This is a good old static initialisation order issue.
The reason why you only see this with the unpackaged version is either you get unlucky with the unpackaged version, or the package automatically initialises the main thread's apartment. In short, you are trying to load a WinRT component before COM has been initialised in the unpackaged version.
I have uploaded a short youtube video showing this in action. but the dependency object initialisation only succeeds when it is moved after the COM apartment initialisation.
There is also very little that can be done about this since this is a C++ issue. You can do a search for the static initialisation order fiasco to find more about it yourself. This also explains why it took following your steps to uncover what your problem was. When I was testing things out, I put the user control in a separate component. This ended up placing the dependency object registration after the initialisation of the COM apartment.

[DrusTheAxe]

Super! Well not that you had a problem <g> but that you identified the issue.

Static initialization ordering? I see the classics never go out of style... ;-)

Happy Coding