Fred Ahrens

I just wanted to provide a real-world example why developers decide against implementing WinUI 3. We found easier and (for us) more robust paths for implementing technology that we (=our customers) need in our applications. At the end we have a business to run - WinUI 3 won't put more money in our pockets. - I'm still talking about our little world here and not Delphi in general. But I should also add that I see desktop apps in general as a dying species and expect more transition to web based apps. Your demand for new technology seems to be completely different compared to ours. And that's of course absolutely fine.

A while ago we used this blog post https://blogs.embarcadero.com/delphi-winui-3-demo/ for our own tests with WinUI 3. After some days we decided it might be easier and better to switch to MS dev tools as they could/should have better dev support - all with the background that MS promised WinUI 3 support also for Win32 applications. But whatever we have tried, every related document and support article was pushing to .Net frameworks for WinUI 3 implementation. Let's just ignore here the unbelievable complexity of creating WinUI3 UIs. Doing some assessment about what we want and could achieve with WinUI 3, it came down to UI design - we couldn't find any other technical advantages that would benefit our projects. After seeing a Delphi demo showcasing an almost perfect UI mockup of the Windows Settings app that used standard components, it became clear to us, the interesting part of WinUI 3 apps is just the UI design - and this can be achieved in Delphi as well. This Settings app even started on Windows XP. This mockup of course wasn't 100% perfect (e.g. transparency effects didn't look like in WinUI3 apps) - but even here some clever programmers deliver some "render magic" for FMX apps that even replicate those transparency effects perfectly. All this without inheriting the platform and framework dependency that you get with WinUI 3. BTW: This discussion feels similar like the discussion some years ago about Embarcadero should support Windows Phone as target. At the end it was the right decision to wait for Windows Phone getting some more traction before bigger investments will be done.

"coding is dead" he shouted while trying to find out how to create a syntactically correct and well structured prompt for his preferred AI model. Hey, what you are doing there is still coding!

The e-mail that you received from MS is related to your Azure account, not to code signing. The e-mail should also contain links to the place where you can enable MFA.

On our systems it takes between 2 to 4 seconds per file. Hard to say what might have an influence on this duration. It may depend on the region where your signing account is located. We use West Europe. Internet speed could also be an important variable in this game.

Easy. Isn't it?

Looks good. Have you set the environment variables AZURE_TENANT_ID, AZURE_CLIENT_ID and AZURE_CLIENT_SECRET? In Azure, if you go to the home page of your Trusted Signing Account: Under "Access control (IAM)" > "Role assignments": Is your app listed with having the right "Trusted Signing Certificate Profile Signer"?

Are the values shown for "CodeSigningAccountName" and "CertificateProfileName" correct? If yes, those values should be redacted in your post. If not, you need to update your metadata file.

The "client secrect" is related to the app used for doing the signing. You should check at https://melatonin.dev/blog/code-signing-on-windows-with-azure-trusted-signing/#step-4-create-an-app-registration if you have created the app needed for doing the signing. This "app" part was initially hard to understand for me. This app is just a placeholder without a real executable or service endpoint. The only purpose is to give it the access right for signing your files. The client secret of this app will be used on top of your other credentials for identifying the app to be used. The client secret of the app is the "Value" entry in section "Certificates & secrets" - not "Secret ID" (it's visible only for a short time; if it's no longer visible and you don't know the value, you'll need to create a new client secret). BTW: That's also the first place to check if the signing suddenly stops working. Usually it's caused by an expired client secret.

It looks like you did exclude all available authentication methods via "ExcludeCredentials". If you leave this parameter empty and provide authentication details via environment variables, you should be able to use your certificate. As long as the authentication doesn't work, you may get a lot of misleading error messages - like "Azure CLI not installed". Actually, Azure CLI is not needed at all. Without authentication SignTool will also not be able to find a valid certificate. I should mention: I assume you try to set up a simple batch file that does the code signing for you. If not, let me know your planned code signing process.

There are two places where you need to provide credential information: You need to set Windows environment variables: set AZURE_TENANT_ID=(enter your azure tenant ID here) set AZURE_CLIENT_ID=(this is the client ID of the app you have set up for authentication) set AZURE_CLIENT_SECRET =(thats the client secret value of the prepared app) Best place would be in a batch file that also contains calls to SignTool etc.. Make sure you strictly limit access to this batch file. Then you need to create the metadata.json file to be used with SignTool and the Azure Trusted Signing DLL: { "Endpoint": "correct URL for your area", "CertificateProfileName": "name of the certificate in your trusted signing account", "CodeSigningAccountName": "name of your Trusted Signing account, NOT your e-mail address or other user ID" } If the details are set correct, you should be able to authorize against the Azure Trusted Signing service and sign your files with SignTool. Setting more variables than the ones mentioned above may confuse the authorization process and may cause the internal selection of another authorization method (there are many) that might not work for your case.

Our Trusted Signing validation took about 30 minutes from creating the validation request until successful validation. But we are also Microsoft Partner for many years and this might have produced already enough interaction between Microsoft and us for giving them enough material for speedy validation. If the related documentation is correct, Trusted Signing is still in preview and is currently open only to companies that are registered more than 3 years with an Azure account.

Got it working with the help of the documentation available at Code signing on Windows with Azure Trusted Signing · Melatonin Most related documents currently online (including Microsofts documentation) still have a major error in the description of the metadata.json format. Instead of using the "TrustedCodeSigningAccount" entry you will need the entry "CodeSignigAcccountName" and set it to the name of the Trusted Signing Account in Azure -, not your e-mail address you use for logging into Azure or other Microsoft services.

I tried it and it still feels very "previewish". After being able to create the signing account, getting my identity validated and creating a first certificate, I'm currently stuck at properly submitting my credentials while trying to sign an exe with SignTool.exe. The available documentation still lacks a lot of important details and it's still too new to find suitable help at stackoverflow or similar. It might work better if you use it via Azure DevOps or GitHub. But so far it still needs some finetuning - especially the documentation - before it can be used with SignTool.exe. With the tool available at https://docs.rs/crate/trusted-signing-cli/0.2.0 I came the closest so far with simple signing an exe file - but still get errors I can't get any further explanation for.

You can control the client via command line (see https://www.virtualhere.com/client_api). This allows you to create build scripts that temporarily activate the dongle on the client system only when it's needed for signing your files and deactivating it after when the script finishes.