Develop Reference

How can I handle OnSuspending with WinUI 3

This time I must migrate an UWP App to WinUI 3, so far everything has worked well except for a few small things but the event OnSuspending is simply not triggered. In the namespace Windows.UI.Xaml you could easily use
this.Suspending += OnSuspending
in app.xaml.cs and it wasn't a problem, in Microsoft.UI.Xaml I can't do this. I have now declared a SuspendingEventhandler in app.xaml.cs
public event SuspendingEventHandler Suspending;
but this just doesn't work. How can I solve this problem?

WinUI 3 can be used to build desktop/WIn32 Windows apps (see the docs) and this kind of apps are not suspended so there is no Suspending event ever being raised.

How to resume where left off after sleep

I would like to make my Xamarin.Forms cross-platform app have the ability to resume after it sleeps.
I have been googling for a while but haven't found any solutions.
I tried reading this Xamarin tutorial but it doesn't seem to have anything for what I am trying to accomplish.
I tried looking for something like base.OnResume() but there is no base variable or any methods.

Xamarin Forms has an OnSleep and an OnResume method in the Application class
These can be used to save and restore variables when the app is backgrounded and resumed.
It is up to you to save the details you need such as page to load and state to restore. Look at the persist data section.
Here is a blog post about doing this.

You can find this methods in your app.xml file. Handle your code inside that file whatever you want to do onresume

How to run code right when a C# application starts?

I have put some code inside of the public MainWindow() {} but I kept getting some obscure XAML parsing errors as soon as I did that (not on my computer but on 3 others I've tried it on - yep!)
Is there the preferred way to run code AS SOON as t he application starts?
The theory is I want it to call home and ask it it's ok to start. If it's not, I want the app to close out. Call it a makeshift copy-protection :)

Under normal circumstances, WPF creates the Main method (the entrypoint of the application) for you. Your options
Create a handler for the Application.Startup event and put your code there. Alternatively, you can override the OnStartup() method.
If that's too late for you, put your code in the App's parameterless constructor (it probably doesn't exist, but you can create it).
If even that's too late, you can create your own Main() method. There are several ways how to do that. Probably the easiest is to put it in another class and tell Visual Studio you want to use this method in the project's properties.
On the other hand, you said you're getting some obscure XAML parsing errors. Maybe you should figure out what exactly do they mean?

You have Window.Loaded event in WPF.
But if if you want to check for run permission before application loads ( due some resource consuption or some business strategy) use a bootstrapper a separate small executable that first launched by mainexe and after if everything ok a bootstrapper runs main exe

Find out if running in WPF or console mode (c#)

Well
this is a really simple question, the search tearms are just not that great.
How do I check in some library if I am currently running as a console application, vs. a WPF window application?
Thanks for any tips,
Chris

You can check whether the current thread is a WPF UI thread by checking Dispatcher.Current.

There's more, what if your library method is called from a worker thread? You didn't tell why you need to know, preventing a good answer. One approach is that the app that uses your library never has any trouble knowing whether its console or WPF. Expose a property to allow it to tell you. Another is using events so the app can simply implement the event handler to its liking. Dependency Injection is another.

You can check if the executed statements are running in a WPF host with the following statement:
if (System.Windows.Application.Current != null)
{
//statements for WPF mode
}
else
{
//statements for non WPF mode...
}
For this you must reference PresentationFramework.dll

ILDasm will have an entry in the manifest as follows :
.subsystem 0x0003 // WINDOWS_CUI
.subsystem 0x0002 // WINDOWS_GUI
based on the subsystemtype you can tell if its GUI or CUI.
This information is also available from the following command :
dumpbin ConsoleApplication1.exe /headers
From your library query for entry assembly and get its full path(Assembly.GetEntryAssembly().CodeBase) and then you can issue any of these command to know the subsystem.

Unmanaged DLL (exporting Dialog) + Class Library (DLL) + no Windows Style/Themes

I have a managed application TestApplication.exe in C# and Application.EnableVisualStyles() is allready called.
I have a Class Library MySharedCode.dll also in C# which uses [DLLImport()] to import some External dialogs out of an unmanaged dll.
Well, now I am using (add reference) MySharedCode.dll in my TestApplication.exe and call a function MyTestConfigDlg() out of it. TestClass.MyTestConfigDlg();
OK, everything works fine and I get my dialog, but the dialog has NO XP style/themes?
I just wanted to see if it's general problem with managed/unmanged modules, so I used the [DLLImport()] to call the same MyTestConfigDlg() dialog but this time directly in my TestApplication.exe! WOW! Worked as I expected. The Dialog was in XP Style/Themes!
so, anybody here who can help me out?
FYI: I also tried (just for test) to call MessageBoxA() API call in my Class Library Dll which later called by my TestApplication.exe and the MessageBoxA() had also no Style/Themes!
Thanks in advance!

Usage of the Application.EnableVisualStyles() applies to certain windows controls such as ListBox, ListView, Menu, Buttons, to make it in line with the XP themes control from the start, if it was running on Vista and later, it would conform the controls to that style also. In short I do not know how do you mean the dialog has no XP/Themes support when invoked directly via the References, yet when you used DllImport keyword to import the function it worked, that is unusual. Usually the usage of DllImport is for unmanaged code API, but somehow it picked it up...I do recall that there was a bug with the .NET 1.1 framework in that if you called Application.EnableVisualStyles(), it failed to work, unless a call to Application.DoEvents() was invoked between enabling the Visual styles and instantiating a winforms, maybe in your case, when instantiating a dialog, perhaps that could solve it by calling Application.DoEvents(), other than that, I am out of ideas...
Hope this helps,
Best regards,
Tom.