Is it possible to make winui3 app into a dll?

[HO-COOH]

So we have a full ui framework lifted from windows built-in UWP, is it possible to build a winui3 app as a dll so that I can easily bring it as a plugin for any other program? I need a working example that requires no change to an existing hosting program (so that it does not require a manifest nonsense that xaml island needs).

[DarranRowe]

This depends on what do you mean by manifest nonsense. Setting the application so that it is compatible with Windows 10 is required. DPI awareness is also required because it uses pointer input.

If the application is manifested to be Windows 10 compatible and high DPI aware, then it certainly is possible. It would have to be framework dependent, since the registrations for self contained would have to go into the application manifest. The big issue here is that doing this will cause global changes to the process.

[HO-COOH]

The app.manifest is what I am talking about. What I really want is something like win32 api, it crashes when the api is not supported on the running OS, but beside that, it can just work. You see, using anything else except for xaml does not require a manifest, like Windows.Web.Http and many more. I can definitely write a full gui framework out of Windows.UI.Composition api, but I shouldn't have to.

[DarranRowe]

I know that you are talking about the side by side/fusion manifest. That was why I mentioned OS compatibility and DPI awareness. I was enquiring as to the specific settings in the manifest in particular.

One of the big entries in the application manifest is due to pointer input. This is documented even on the Windows API messages, such as WM_POINTERDOWN. DPI awareness could be enabled using a function, but SetProcessDpiAwarenessContext is process wide and may have unintended consequences, and SetThreadDpiAwarenessContext may not get everything. If you look at the native debugger output in Visual Studio, you can see output similar to the following:

The thread 'DManip Delegate Thread' (31552) has exited with code 0 (0x0).
The thread 'Lifted DMIT' (30276) has exited with code 0 (0x0).
The thread 'DWM Master Input Thread' (16796) has exited with code 0 (0x0).
The thread 'DWM Manipulation Thread' (4876) has exited with code 0 (0x0).
The thread 'Composition Token Thread' (36404) has exited with code 0 (0x0).
The thread 'DWM Compositor Thread' (30712) has exited with code 0 (0x0).

This shows that the input and drawing are not on the same thread as the Application or Window classes and these can be affected by the DPI awareness.

I did a quick test, and using a project layout similar to the WinUI 3 projects, it was quite straight forward to get a working DLL. The only major change that I made was to disable the Xaml generated main and used my own. I also made sure to run this on a separate thread from the main UI thread. UI frameworks generally don't work well together.

I had to use my own in order to direct the WinUI framework to the correct resources file.

#include "App.xaml.h"
#include <winrt/Microsoft.Windows.ApplicationModel.Resources.h>

extern"C"
__declspec(dllexport)
void load_xaml_main()
{
	winrt::Microsoft::UI::Xaml::Application my_app{ nullptr };
	winrt::event_token rmr_event_token{};
	winrt::init_apartment();
	winrt::Microsoft::UI::Xaml::Application::Start([&my_app, &rmr_event_token](auto &&)
		{
			my_app = winrt::make<winrt::WinUIDllTest::implementation::App>();
			rmr_event_token = my_app.ResourceManagerRequested([](const winrt::Windows::Foundation::IInspectable &, const winrt::Microsoft::UI::Xaml::ResourceManagerRequestedEventArgs &args)
				{
					winrt::Microsoft::Windows::ApplicationModel::Resources::ResourceManager rm{ L"WinUIDllTest.pri" };
					args.CustomResourceManager(rm);
				});
		});

	my_app.ResourceManagerRequested(rmr_event_token);
	my_app = nullptr;
}

[HO-COOH]

The thing is, the main exe calling my winui3 dll does not necessarily have a manifest, and I still want to be able to use winui3 because it is a full gui framework that is suitable for more complex gui logic. (Do not suggest me to make it into a separate exe, that is not my use case).

[DarranRowe]

All I can suggest then is to test. This is going to be in the relms of unsupported anyway. But the big thing to remember is that the WinUI 3 runtime will start up and work even if the manifest file is missing or missing these settings. The manifest entries are there to make sure that features will work as expected.

The comments from the manifest file hints that the OS compatibility is related to Microsoft.UI.Windowing.AppWindow and the titlebar customisation. If you avoid using titlebar customisation, then it could be possible to not require that setting. I went into detail with DPI awareness, and since you have control over the entrypoint into WinUI 3 then you could either try SetProcessDpiAwarenessContext to see if it breaks the application. If it does, then you could try finding all of the WinUI 3 threads and use SetThreadDpiAwarenessContext. Make sure to test this on monitors with DPI scaling above 100% to be sure that input, especially touch input, is where you expect it to be, and there you go.

You have to be aware of the fact that you would be responsible for keeping up with the implementation details and fixing things in this case, but there is a pretty good chance of this working. Just be aware of interop between non DPI aware threads and DPI aware threads.