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: native Win32 .exe -> links to a C++/CLI dll with a known native C++ interface C++/CLI dll -> references and makes calls into a C# .NET8 Class Library 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)

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.

Can native Win32 exe show a WinUI3 Page?

Accepted answer

Michael Taylor 55,216 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.
Please sign in to rate this answer.

1 person found this answer helpful.
Eric Brandt 25 Reputation points

2024-11-18T18:01:28.0666667+00:00

Thanks for the reply. You have correctly identified that this is a 'plug in' architecture scenario.

You have confirmed my concerns - it seems showing WinUI3 content from a native Win32 exe is not possible in a robust manner.

Out of curiosity, why do you say the article that we both linked to is irrelevant? And what do you mean by "if it loads late in the process it might be too late?" What is the point at which it becomes 'too late'? Only if the process first loads a different framework before our plugin's initialization?

In parallel with this questioning online, I am preparing for the workaround that you suggest (IPC to another standalone process). I too am worried about how to coordinate a seamless UX without formal window parent/child relationships. Fortunately, our UI is mostly separate, and we do not integrate our plugin's controls as child controls in the main exe's window.

Our typical go-to for IPC like this would be gRPC (and may be what we use). Question: I haven't kept up with .NET's preferred or built-in method for this type of IPC. The last that I was familiar with inside .NET was the early days (2.0?) that featured ".NET Remoting", but I know is now long gone. What is MS's current technology recommendation to support this sort of IPC?

Thanks!

-Eric.

Michael Taylor 55,216 Reputation points

2024-11-18T19:07:12.34+00:00

why do you say the article that we both linked to is irrelevant?

I didn't mean the article was irrelevant. What I meant was, irrelevant of the previous statement I made, here is an article that provides the steps to follow.

What is the point at which it becomes 'too late'? Completely depends on the app. The article says to init COM before trying to load the boatstrap for WinUI3. That makes sense. But if COM has already been initialized on the thread your plugin runs on then that call is not going to work because COM can be initialized on a thread only once. That would be one scenario that may cause problems.

But another scenario might be plugins all run in the same process and some other plugin already loaded a conflicting framework (maybe WinUI3 already or perhaps WinUI2).

What is MS's current technology recommendation to support this sort of IPC?

.NET remoting was a binary serialization library so yes it is gone. In its place are a couple of options. REST APIs are probably the easiest to work with but require running an API server. A step back might be using WCF if you need binary serialization or custom bindings but, again, you require running the server. In both cases they could be run standalone but REST APIs tend to be hosted by web servers so you'd need something like Kestrel or whatnot. WCF can be hosted in any process. Finally you can always fall back to COM as well but that would be a last resort for me.

If you need the simplest possible IPC then a named pipe might work but you're responsible for the communication so it is probably the fastest at the cost of more work. gRPC would also work I think. There are some others that I've never worked with. If you google for NET Core IPC then you'll get some additional options.

Deleted

This comment has been deleted due to a violation of our Code of Conduct. The comment was manually reported or identified through automated detection before action was taken. Please refer to our Code of Conduct for more information.

Eric Brandt 25 Reputation points

2024-11-19T22:00:41.6533333+00:00

Thanks for the helpful replies.
The question has now morphed into this (taking the IPC approach you suggested):
https://learn.microsoft.com/en-us/answers/questions/2120880/example-of-a-c-standalone-exe-that-hosts-a-grpc-se
It seems this intended design is not as straightforward in C# as it is to create a C++ gRPC Server in any exe or library.
Sign in to comment

Use comments to ask for clarification, additional information, or improvements to the question.

Share via

Can native Win32 exe show a WinUI3 Page?

0 additional answers

Your answer