Can native Win32 exe show a WinUI3 Page?

Eric Brandt 45 Reputation points
2024-11-18T15:30:26.94+00:00

I need to show a WinUI3 page from a native Win32 exe. I cannot make modifications to the Win32 exe. The architecture is like this:

  1. native Win32 .exe -> links to a C++/CLI dll with a known native C++ interface
  2. C++/CLI dll -> references and makes calls into a C# .NET8 Class Library
  3. C# .NET8 Class Library -> contains WinUI3 pages & controls.

(We also use the C# .NET8 class library's pages from a different WinUI3 exe as well)

(Also, we cannot change the native win32 exe. It is not under our control)

We've had this architecture for generations of MS technologies and always found a way to make it work with WinForms and then with WPF. But now we have WinUI3...

I'm not finding any examples other than https://www.codeproject.com/Articles/5359576/WinUI3-in-Existing-Win32-Applications and when I clone the example repo, it does not work (perhaps out of date due to the various betas that WinUI went through?)

Can this be achieved? If so, any advice on examples or documentation of the relevant calls that need to be made to set this up?

Thanks!

(Question cross posted on StackOverflow as well)

.NET
.NET
Microsoft Technologies based on the .NET software framework.
3,981 questions
Windows API - Win32
Windows API - Win32
A core set of Windows application programming interfaces (APIs) for desktop and server applications. Previously known as Win32 API.
2,685 questions
.NET CLI
.NET CLI
A cross-platform toolchain for developing, building, running, and publishing .NET applications.
339 questions
C#
C#
An object-oriented and type-safe programming language that has its roots in the C family of languages and includes support for component-oriented programming.
11,111 questions
C++
C++
A high-level, general-purpose programming language, created as an extension of the C programming language, that has object-oriented, generic, and functional features in addition to facilities for low-level memory manipulation.
3,786 questions
{count} votes

Accepted answer
  1. Michael Taylor 55,471 Reputation points
    2024-11-18T16:23:05.8433333+00:00

    If you don't have control over the EXE, I assume you're building a plugin. Then it may or may not work correctly irrelevant of whether you can get it running locally. The problem is a lot like trying to get a NET-implemented component running in the Shell before NET 4.x came out. The issue is that you might be able to bootstrap the necessary infrastructure to host the WinUI3 runtime but somebody else might have already done that (either the EXE or another plugin) so you'll end up colliding in the middle.

    Irrelevant here is an article that supposedly gets it to work in an existing Win32 program by manually bootstrapping the runtime. Note that depending on the architecture of the app this might or might not work since the plugin would need to do this and if it loads late in the process it might be too late.

    Perhaps a safer, albeit harder, workaround is to host the actual WinUI3 stuff in a separate process and interop with the plugin hosted in the Win32 process. This has its own set of challenges such as providing the illusion of an integrated UX when in fact they are separate, since you can't set Win32 parent-child relationships across processes. If you need to integrate directly into another UX then this wouldn't work but if your plugin merely needs to show a standalone UX then it would work.

    1 person found this answer helpful.

0 additional answers

Sort by: Most helpful

Your answer

Answers can be marked as Accepted Answers by the question author, which helps users to know the answer solved the author's problem.