This guide walks you through the complete process of signing EXE and DLL files on Windows with Azure Artifact Signing.

Here’s the shape of it, so you know what you’re signing up for:

• One-time setup (Steps 1–9): Azure account, portal clicks, and identity validation. This is the slow part. Budget a day to a week for the identity check to clear.
• Every build (Step 10): one script that signs your exe and DLLs in seconds.

If you’ve already done the setup, skip straight to Step 10.

Why I Picked Azure Artifact Signing

• $9.99/mo for up to 5,000 signatures (Basic tier), with no USB hardware token to manage.
• Fully managed. Microsoft rotates the certificates daily behind the scenes. You never see or store a private key.
• Identity-based publisher reputation. Public Trust signing ties the signature to your validated identity instead of a certificate you manage yourself. SmartScreen warnings can still appear for first-time or low-volume downloads; signing does not guarantee they will disappear immediately.

A note on names: this service was called “Azure Trusted Signing” until recently. Same thing, new name. If you see “Trusted Signing” in older docs or screenshots, it’s the same service.

Prerequisites

1. A Microsoft account (you get one when you sign up with Azure).
2. A paid Azure subscription.  This is the #1 early blocker: Artifact Signing does not work on free/trial/sponsored subscriptions. Upgrade to pay-as-you-go first (Cost Management + Billing → your subscription → upgrade) – https://azure.microsoft.com/en-us/products/artifact-signing.

Step 1 — Register the resource provider

Quick orientation first: an Azure subscription is the billing container for everything you create. Azure charges your services to it, and it also defines where those resources live and who can access them. When you signed up, Azure created one for you automatically (often with a forgettable default name like “Azure subscription 1”).

A separate subscription is optional. If you want clean billing and access boundaries for signing, create or dedicate one; otherwise, use your existing paid subscription and keep the signing resources in a dedicated resource group.

Then:

1. Portal → Subscriptions → the subscription you chose.
2. Left menu → Settings → Resource providers.
3. Find Microsoft.CodeSigning → click the … → Register. Wait for Registered.

Step 2 — Create the Artifact Signing account

Keep the signing resources together in the same subscription and a dedicated resource group.

1. Portal search → Artifact Signing Accounts → Create.
2. Subscription: the paid subscription you chose. Resource group: new, e.g. rg-artifact-signing.
3. Account name: 3–24 alphanumeric, starts with a letter, globally unique (no consecutive hyphens). e.g. xojoappsigning.
4. Region: pick one you’ll remember; it determines your signing endpoint.
5. Pricing: Basic unless you’ll exceed 5,000 signs/month.
6. Create, then note the Account URI on the overview page. It follows the pattern https://<region-code>.codesigning.azure.net/.

Step 3 — Assign the Identity Verifier role

You need this before the identity-validation button becomes clickable.

1. From your Artifact Signing account, left menu → Access control (IAM) → Add role assignment.
2. Role: Artifact Signing Identity Verifier (use the search field) → assign to your own user account.

Step 4 — Identity validation (the real gate)

From your Artifact Signing account (the one you created in Step 2), go to the left menu → Objects → Identity validations → New Identity → Public.

Public is what you want for normal app signing (it’s what SmartScreen cares about).

Fill in your legal business name, website, emails, business identifier (tax ID / DUNS), and address. Two gotchas that bite everyone:

• The secondary email must be on the same domain as the primary.
• Individual developers: the form pulls from your Azure billing account, and its name/address must exactly match your ID.

What happens next: status goes In Progress → Action Required (this is the point when you may have to wait a few hours to days… In my case, it took only an hour). You’ll be routed through a third-party verifier (AU10TIX). You upload a government ID and a selfie from your phone, then add the resulting Verified ID to Microsoft Authenticator and share it back (another hour or so).

Timeline: officially 1–20 business days; in practice often hours to a few days. If it stalls, re-submit with a different identifier (tax ID instead of DUNS) and make sure your company name/address match your documents exactly.

Step 5 — Create the certificate profile

1. From your Artifact Signing account, left menu → Objects → Certificate profiles → Create.
2. Type: Public Trust.
3. Name it (5–100 chars), then pick your completed identity validation under Verified CN and O.
4. Create. You never see or hold the certificate. It’s rotated daily behind the scenes. The public cert is embedded in every file you sign.

Step 6 — Assign the Certificate Profile Signer role

This is the role that lets you actually sign. Because we’re using the Azure CLI, it goes on your user. No app registration is needed (this is a separate/alternative process, but we’re not talking about that in this article).

1. From your Artifact Signing account, left menu → Access control (IAM) → Add role assignment.
2. Role: Artifact Signing Certificate Profile Signer → assign to your own user account.

Give role assignments a few minutes to propagate. If you try signing immediately and hit a 403, wait ~5 minutes and retry.

Step 7 — Install the signing tools

First, the Azure CLI: winget install Microsoft.AzureCLI

You’ll use it in Step 9 to authenticate with Azure.

SignTool comes with the Windows SDK. Install it with: winget install --id Microsoft.WindowsSDK --exact

 Run this to find the newest x64 signtool.exe:
Get-ChildItem "C:\Program Files (x86)\Windows Kits\10\bin" -Recurse -Filter signtool.exe | Where-Object { $_.FullName -match '\\x64\\signtool\.exe$' } | Sort-Object FullName -Descending | Select-Object -First 1 -ExpandProperty FullName

Note the path down.

.NET 8 runtime (x64).

Microsoft Visual C++ Redistributable.

Artifact Signing Client Tools:winget install -e --id Microsoft.Azure.ArtifactSigningClientTools
This installs Azure.CodeSigning.Dlib.dll (the plugin signtool uses to talk to Azure).

 Locate the actual dll path after install:
Get-ChildItem -Path "C:\Program Files","$env:LOCALAPPDATA" -Recurse -Filter Azure.CodeSigning.Dlib.dll -ErrorAction SilentlyContinue | Select-Object -First 1 -ExpandProperty FullName

Note the path down.

If signtool gives you “command not found”, that’s normal; it’s not on PATH. Use the full path, or add ...\10\<version>\x64 to your PATH.

Step 8 — Create the metadata file

This is a small JSON with three values. Name it anything you like, e.g. artifact-code-signing.json:

{
	"Endpoint": "https://<region-code>.codesigning.azure.net",
	"CodeSigningAccountName": "xojoappsigning",
	"CertificateProfileName": "...."
}

This JSON file will be used a lot, so save it somewhere safe.

• Endpoint = your account URI (region-specific; must match where the account + profile live, or you get a 403).
• CodeSigningAccountName = the Artifact Signing account name from Step 2.
• CertificateProfileName = the certificate profile name you created in Step 5.

Step 9 — Authenticate with the Azure CLI

az login

This opens your browser; sign in with the Microsoft account tied to your Azure subscription. When signtool runs, the dlib picks up your logged-in Azure CLI session automatically.

If you have multiple Azure subscriptions, point the CLI at the right one, then confirm it took:

az account set --subscription "<your subscription id>"
az account show --query name -o tsv

The second command should print your code-signing subscription’s name. If you also have multiple Microsoft tenants (a personal account and a work account, for example), log straight into the right one:

az login --tenant "<tenant id>"

You may occasionally need to re-run az login after long idle periods.

Step 10 — Sign your Xojo app

Just remember, you need to sign the compiled application after each new build.

What to sign (and skip)

Your Xojo Windows build folder looks roughly like this. Sign the binaries you build or distribute under your publisher identity; leave Xojo, Microsoft, and other vendor-signed dependencies alone.

Windows 64 bit/
└── YourApp/
    ├── YourApp.exe              ← sign
    ├── <your own DLLs>          ← sign
    ├── XojoGUIFramework64.dll   ← skip, Xojo provides signed DLLs
    ├── YourApp Libs/            ← skip, Xojo provides signed DLLs
    ├── msvcp140.dll, vcruntime*.dll …  ← skip (Microsoft runtime)
    └── YourApp.exe.WebView2/    ← skip (WebView2 cache)

The script

Save this as sign.ps1, next to the Xojo project, update the paths at the top, and run it from PowerShell:

$ErrorActionPreference = "Stop"

$Signtool    = "C:\...\signtool.exe"                            # path from Step 7
$Dlib        = "C:\...\Azure.CodeSigning.Dlib.dll"              # path from Step 7
$Metadata    = "C:\...\artifact-code-signing.json"              # from Step 8
$BuildFolder = "F:\...\YourApp"                                 # folder containing YourApp.exe

# Installer (Inno Setup) — optional. Set $EnableInno to $false to skip this part.
$EnableInno  = $true
$InnoSetup   = "C:\Program Files (x86)\Inno Setup 6\ISCC.exe"
$IssScript   = "F:\...\YourAppSetup.iss"                        # your Inno Setup script
$Installer   = "F:\...\YourAppSetup.exe"                        # output from the .iss

# Sign binaries you build or distribute under your publisher identity.
# Leave Xojo, Microsoft, and other vendor-signed dependencies alone.
$FilesToSign = @(
    "$BuildFolder\YourApp.exe"
    "$BuildFolder\MyPlugin.dll"
    # add any other files you own here, one per line
)

function Invoke-SigningCommand {
    param([string[]]$Arguments)

    & $Signtool @Arguments
    if ($LASTEXITCODE -ne 0) {
        throw "SignTool failed with exit code $LASTEXITCODE."
    }
}

foreach ($f in $FilesToSign) {
    Invoke-SigningCommand @(
        "sign", "/v", "/fd", "SHA256",
        "/tr", "http://timestamp.acs.microsoft.com", "/td", "SHA256",
        "/dlib", $Dlib, "/dmdf", $Metadata,
        $f
    )
}

if ($EnableInno) {
    # Build a fresh installer, then sign it.
    & $InnoSetup $IssScript
    if ($LASTEXITCODE -ne 0) {
        throw "Inno Setup failed with exit code $LASTEXITCODE."
    }

    Invoke-SigningCommand @(
        "sign", "/v", "/fd", "SHA256",
        "/tr", "http://timestamp.acs.microsoft.com", "/td", "SHA256",
        "/dlib", $Dlib, "/dmdf", $Metadata,
        $Installer
    )
}

What the flags mean:

• /tr http://timestamp.acs.microsoft.com: the timestamp server. The http:// (not https) is intentional.
• /fd SHA256 and /td SHA256: SHA-256 for the file and the timestamp.
• /dlib: the Azure plugin from Step 7. /dmdf: your metadata JSON from Step 8.

Confirm it worked

Two checks:

1. Signtool:$Signtool verify /v /pa "$BuildFolder\YourApp.exe" You want to see Successfully verified.
2. Or: right-click YourApp.exe → Properties → Digital Signatures → your org name should be listed.

Rules of thumb

• Sign after every build. Each new .exe is a fresh unsigned binary.
• Sign before you zip. Sign the files, then package them. Signing inside a zip does nothing.

Troubleshooting

Recap

One time (Steps 1–9): register the Microsoft.CodeSigning provider → create the account → assign the Identity Verifier role → complete identity validation (slow’ish) → create the certificate profile → assign the Signer role → install tools → write the metadata JSON → az login.

Every build (Step 10): run sign.ps1.

The bottom line

Azure Artifact Signing is a low-cost managed option for signing Windows apps, and Azure CLI authentication means local builds do not need a stored signing private key. The setup has some Azure bureaucracy, and identity validation is the slow part. After that, it is one script per build.

Related discussion

For an alternative approach that automates Xojo application signing and Inno Setup installer creation, see Jürg Otter’s Xojo Forum topic, Windows Code Signing & Installer Creation with Inno Setup. The topic includes Jürg’s open-source code, which supports both Azure Artifact Signing and traditional .pfx certificates.

Gabriel is a digital marketing enthusiast who loves coding with Xojo to create cool software tools for any platform. He is always eager to learn and share new ideas!

• Facebook
• X
• LinkedIn
• GitHub
• YouTube

Download Xojo

Enhanced Emoji Rendering

While Xojo’s Graphics class supported rendering emojis on Windows and Linux, their appearance was less appealing.

Now in Xojo 2024r2, we’ve enhanced emojis with vivid colors!

You’ll notice that other parts of the Xojo framework that utilize the Graphics class, such as the ListBox, have also benefited from this update.

Understanding Emojis at a Deeper Level

Understanding how emojis are encoded is crucial for grasping how Xojo’s String type works and how we interpret them. Any text or emoji displayed on the screen can be considered a Unicode sequence or a series of Unicode sequences. At a deeper level, a single Unicode sequence can be constructed from multiple Unicode code points (i.e., bytes of data). For clarity, we’ll describe one character (whether simple text or an emoji) as being composed of Unicode sequence(s).

To demonstrate, let’s try to understand the woman

This particular woman is not very complex, it is made up of one single Unicode sequence (with corresponding code points). Our String type can easily handle this one Unicode sequence and reports correctly that the Length of the String is 1 (even though the entire emoji is made up of 4 bytes of code points).

Now let’s take a look at a more complicated woman

The only difference visually is that this woman has fiery red hair. This subtle change in appearance means that to construct this emoji requires not 1, not 2, but 3 distinct Unicode sequences (with a grand total of 11 bytes of code points).

Note that the reported length of the String is 3 Unicode sequences, even though we visually see only one character. This distinction is very important in understanding how String functions work. Xojo’s String functions inherently deal with Unicode sequences, not individual characters. When you do need to work with complex emojis like these, you will want to utilize our String.Characters API which effectively manages this complexity.

An Optimized String.Characters

Given the prevalence of emojis in everyday text and messages, properly handling them within Xojo’s String type is crucial. While we initially introduced this feature as String.Characters, it functioned as an iterator until Xojo 2024r2. Now, String.Characters returns a String array, which can still be iterated, ensuring existing code continues to work as before. Additionally, this update offers the added advantage of significantly improved speed, especially on Windows and Linux. Along with this update, we introduced String.CharacterCount, which is useful when you need to know the number of characters in a string without storing them all in an array.

To further understand emojis and their corresponding Unicode sequences, check out this Full Emoji List.

William Yu grew up in Canada learning to program BASIC on a Vic-20. He is Xojo’s resident Windows and Linux engineer, among his many other skills. Some may say he has joined the dark side here in the USA, but he will always be a Canadian at heart.

• Facebook
• X
• LinkedIn
• GitHub
• YouTube

Download Xojo

Supporting dark mode with Win32 controls is never an easy exercise, but if you’ve been following along with our work to modernize our Windows framework with XAML, then you may have already updated your apps with the XAML TabView control that natively supports dark mode.

Simply plug this bit of XAML into our DesktopXAMLContainer Content property and you’ve got yourself a modern looking TabPanel that already supported dark mode even before we did.

<winui:TabView>
	<winui:TabView.TabItems>
		<winui:TabViewItem Header="Tab 1">
			<StackPanel>
				<TextBlock Text="This is Tab 1" Margin="5"/>
				<Button Content="Button 1" Margin="5"/>
				<CheckBox Content="Checkbox 1" IsChecked="True" Margin="5"/>
			</StackPanel>
		</winui:TabViewItem>
		<winui:TabViewItem Header="Tab 2">
			<StackPanel>
				<TextBlock Text="This is Tab 2" Margin="5"/>
				<TextBox Text="Enter text here" Margin="5"/>
				<ComboBox Margin="5">
					<ComboBoxItem Content="Item 1"/>
					<ComboBoxItem Content="Item 2"/>
					<ComboBoxItem Content="Item 3"/>
				</ComboBox>
			</StackPanel>
		</winui:TabViewItem>
	</winui:TabView.TabItems>
</winui:TabView>

While people debate on which mode (light or dark) they prefer to work in, you can ultimately control whether you want to support dark mode or not in your app by toggling the “Supports Dark Mode” build setting. For an example on how to dynamically switch between dark and light mode in your app using XAML, see the XAML ButtonStyling example project and the RequestedTheme property.

William Yu grew up in Canada learning to program BASIC on a Vic-20. He is Xojo’s resident Windows and Linux engineer, among his many other skills. Some may say he has joined the dark side here in the USA, but he will always be a Canadian at heart.

• Facebook
• X
• LinkedIn
• GitHub
• YouTube

Download Xojo

Doing More With Layouts

While you can certainly add a single WinUI control in a DesktopXAMLContainer, you can also aggregate controls on the container to improve things. XAML makes it possible to customize the layout of your controls using mark-up instead of laying out your controls (one by one) on your window and adjusting the position by hand. Take for example a set of buttons that you want to layout vertically on your window. While you can certainly position three individual buttons on your layout, you could also accomplish this using one DesktopXAMLContainer with the StackPanel layout.

<StackPanel Orientation="Vertical">
  <Button Content="Button 1"/>
  <Button Content="Button 2"
           Margin="0,10,0,0"/>
  <Button Content="Button 3"
           Margin="0,10,0,0"/>
</StackPanel>

Without any dragging or dropping, you can re-configure this layout to be horizontal instead.

<StackPanel Orientation="Horizontal">
  <Button Content="Button 1"/>
  <Button Content="Button 2"
           Margin="10,0,0,0"/>
  <Button Content="Button 3"
           Margin="10,0,0,0"/>
</StackPanel>

Handling Events

In the case of a single WinUI button in a DesktopXAMLContainer, handling events is a simple check in EventTriggered for the “Click” eventName. With multiple buttons in a DesktopXAMLContainer, you will want to properly Name them to determine which button was clicked.

<StackPanel Orientation="Vertical">
  <Button Name="Button1" Content="Button 1"/>
  <Button Name="Button2" Content="Button 2"
           Margin="0,10,0,0"/>
  <Button Name="Button3" Content="Button 3"
           Margin="0,10,0,0"/>
</StackPanel>

You can inspect the parameters Dictionary to see what other Keys are available for a particular control and event. All controls will have at least the three basic keys: the fully qualified XAML Class name, the Name of the control, and the additional Tag property. Some controls will have additional Keys populated in the Dictionary, for example the XAML CheckBox control will fire a ValueChanged event with an IsChecked Key available in the parameters Dictionary. The specific names for these Keys can be found in the XAML Control Chooser Window.

Doing More With Code Behind

There will be instances where you may want to setup your control dynamically in code. The available properties/methods that a particular XAML control supports in the XAML Control Chooser window are documented. These properties and methods can be accessed using the DesktopXAMLContainer’s Value and Invoke methods. Let’s take the simple example of a Button. While you could set this all up using just XAML code, there may be times that you want to only change the caption of the Button in code. To do this you can use the Value method:

XAMLContainer1.Value("Content") = "My new caption"

Equivalently, you could also set this up using only XAML code:

XAMLContainer1.Content = "<Button Content='My new caption'/>"

If you have multiple Buttons in your DesktopXAMLContainer (like in our StackPanel example above), you can reference the control using a fully qualified name space:

XAMLContainer1.Value("Button2.Content") = "My new caption"

Conversely, if you wanted to know what the caption of Button3 is, you can use the Value to get it too:

myCaption = XAMLContainer1.Value("Button3.Content")

Some Properties/Methods Support Embedded XAML Code

If you take a look at the Button Content property, we’ve documented it with a note about it supporting XAML code. This means you can insert XAML code instead of just a basic string. So if you wanted to embed a ProgressRing inside a Button you could add that using the Content property.

XAMLContainer1.Value("Content") = "<ProgressRing />"

This would be the equivalent XAML code:

<Button>
  <ProgressRing />
</Button>

What is this winui namespace?

You may notice that some controls, added via the XAML Control Chooser window, use the winui namespace when you inspect the Content. Those particular controls are using the more modern UI look and feel. See https://learn.microsoft.com/en-us/uwp/api/microsoft.ui.xaml.controls
some controls offer the older style equivalent, see https://learn.microsoft.com/en-us/uwp/api/windows.ui.xaml.controls
One such control is the ProgressRing. If you prefix this with winui, you’ll get the updated look, while the previous iteration can be seen without the winui prefix.

<winui:ProgressRing />

<ProgressRing />

Custom Binding

Xojo supports a new mark-up syntax called {XojoBinding} specifically to help with re-usability of XAML controls. This currently only binds at the layout/IDE layer, but can be useful for re-usability purposes. As in this example you can customize the look of a Button by changing some properties in the inspector.

To set this up you will need to subclass a DesktopXAMLContainer and add the properties you want exposed in the inspector.

You will then need to add the necessary {XojoBinding} calls in the Content of your XAML:

The syntax for binding to a XAML property is written as:

{XojoBinding [name of class property]}

And in this case it’s binding the Caption property that we just added and exposed via the Inspector Behavior, to the Content of the XAML Button.

This means a change to the Caption property in the Inspector will now update the XAML code to reflect this change and update the layout accordingly. For doing more with the DesktopXAMLContainer, make sure to check out the Example Projects included in the Examples folder of the Xojo Download, the Xojo Documentation.

William Yu grew up in Canada learning to program BASIC on a Vic-20. He is Xojo’s resident Windows and Linux engineer, among his many other skills. Some may say he has joined the dark side here in the USA, but he will always be a Canadian at heart.

• Facebook
• X
• LinkedIn
• GitHub
• YouTube

Download Xojo