WebAuthenticationSession "The UIWindowScene for the returned window was not in the foreground active state."

In my case, I got this error (from a certain point of time if remember well), when implementing an OAuth protected API access upon a screen opens.

My platform is Xamarin.Forms.

Originally, I was doing so in the OnAppearing event handler. Opening WebAuthenticator browser etc. that sort of things. But at one point, on iOS, it stopped working, giving the following exception:

Error Domain=org.openid.appauth.general Code=-3 "(null)" UserInfo={NSUnderlyingError=0x60000299a7f0 {Error Domain=com.apple.AuthenticationServices.WebAuthenticationSession Code=3 "The UIWindowScene for the returned window was not in the foreground active state." UserInfo={NSDebugDescription=The UIWindowScene for the returned window was not in the foreground active state.}}}

It appears that the WebAuthentication browser can only be shown and return thereafter, to a foreground active window.

OK. Let us move it to another event handler which is called when the windows appeared, rather than appearing.

There seems, however, no such an event available in Xamarin.Forms, in the PCL project.

On the other hand, the iOS native UIViewController has the event ViewDidAppear, and we can code the handler through the PageRenderer.

I am still a newbie in Xamarin development, was not sure if such is possible. But wow! It works like a magic! I moved the API calling code from the page code behind class OnAppearing method to the PageRenderer. Only for iOS. For Android, it remains in the code behind class.

So the "life cycle" is, on iOS, the ViewDidAppear method is called first since there is a custom renderer is implemented, while on Android, simply only the OnAppearing method is called.

Build pipeline for a Desktop Bridged Xamarin project

By the way, I am writing this with Open Live Writer, which finally back again supports Blogger. Not officially though…

Let us start the story of the title.

An explanation for the cryptic title first.

What is Desktop Bridge? As explained here, its goal is to create a bridge between the new development approach introduced in Windows 10 (the Universal Windows Platform) and the traditional desktop application. 

In my case however, I came across this idea when I was seeking if feasible to use the systray from my Xamarin/UWP application. I want to make my app like MS Teams, which runs when you starts your PC, stays up in the systray, showing the status (your availability as it is seen by others). I found this blog post. Its sample code is found as a part of the Microsoft GitHub repo for Desktop Bridge samples. It explains how to enable a UWP package to have executables that run as full trust instead of in an app container. 

How to have an UWP app start at sign-in is found here.

I brought these ideas into my Xamarin project, have had it acts like Teams as described above. Very happy.

The next step is to establish its build process as a Azure Pipeline, so my business colleagues come directly there to find the app and test for each feature request, bug fix etc.

I am using a Cloud agent. At the beginning, it fails in building the systray component project. The project has a reference to c:\Program Files (x86)\Windows Kits\10\UnionMetadata\10.0.19041.0\Windows.winmd, which is not found on the cloud agent machine.

##[warning]C:\Program Files\Microsoft Visual Studio\2022\Enterprise\MSBuild\Current\Bin\Microsoft.Common.CurrentVersion.targets(2302,5): Warning MSB3245: Could not resolve this reference. Could not locate the assembly "Windows". Check to make sure the assembly exists on disk. If this reference is required by your code, you may get compilation errors.

Interestingly though, it appears to me that it is not that the file (part of Windows SDK if I am not wrong) does not exist on the machine, but the reference is somewhat modified…

For SearchPath "{HintPathFromItem}".
Considered "D:\Program Files (x86)\Windows Kits\10\UnionMetadata\10.0.19041.0\Windows.winmd", but it didn't exist.

It is C not D, the original reference.

I struggled, and finally seems to have found a bit odd but nevertheless working solution, which is to copy the file (it does exist!) to the project’s bin folder so it is found.

Other may-be-oneday-useful info:

• As of today, on the Azure Cloud pipeline agent, four Windows SDKs are available, including the 2004 aka 10.0.19041.0 that I needed. https://docs.microsoft.com/en-us/answers/questions/863168/uwp-app-will-not-build-using-windows-latest-window.html
• How to install if it is not there. https://community.chocolatey.org/packages/windows-sdk-10-version-2004-all/10.0.19041.0
• Sign UWP app with a code signing cert stored in an Azure vault. https://github.com/microsoftdocs/msix-docs/blob/main/msix-src/desktop/sign-with-akv-cert.md
• Sign in a Pipeline https://docs.microsoft.com/en-us/windows/msix/desktop/msix-packaging-extension?tabs=yaml

Tha’s it!

Running Linux container-based apps on Windows server

It took me quite some time to finally have this running. But I am writing this to tell you that I probably made a bad choice after all...

Why I wanted to run a Linux-based app on a Windows server?? Never mind. That happens to life from time to time, doesn't it?

The idea originally came to me already back end of year 2020. I grabbed the script that we were running on a Linux server, and saw how easy it is to run it as is inside a container on my Windows laptop. That was super easy I recall. Encouraged, started the effort of deploying it onto one of our Windows servers.

Onto your workstation, you install the package called Docker Desktop. Super easy. Again.

However to a Windows server, you need to install what used to be called Docker Engine Enterprise. The installation was not a challenge. I found a lot of blog posts explaining it.

However (again) when I was in the middle of it, I found that the maintenance had been passed from Microsoft to a company called Mirantis. The most important change is that this package is no longer free. It is free, still at the time I am writing this, which is January 2022, but not after the year 2024. The devil is that when you have yourself busy with the installation following all those blogs, majority of which talk about the free Microsoft version, you would never imagine that it is becoming a paying package. By the time you found it out, you spent quite some time on it already. Going for an alternative, throwing all the time and effort into garbage is quite discouraging... 

This is the first reason that I qualify it as a wrong choice.

The second was that the capability of running Linux containers on it had been said "experimental" and the development has now stopped. Here reads as development has now stopped in favor of running docker natively on Linux in WSL2. The WSL feature is available only on the desktop edition Windows such as Windows 10 as of today, not with the server OSs. It may never be...

In addition, I recently received an email to announce that the above mentioned Docker Desktop package for your development will soon become a paying software too.

Of course, there is nothing wrong with charging users with a fee. But I do not really like this practice of allowing to start with no fee, and starting charging once users have developed a lot and become unable to operate without it.