Self-contained .NET apps meet ClickOnce on Windows Forms

Many Australian organisations still rely on line-of-business Windows Forms applications. From the teller stations of the big four banks in Sydney and Melbourne to the back-office tools used inside the Australian Taxation Office in Canberra, the humble WinForms desktop remains a workhorse. When a developer at one of these shops says they need to ship a fix by Friday arvo, they usually mean a ClickOnce deployment that lands before the close of business AEST. Combining ClickOnce with a self-contained .NET build is one of the most reliable ways to keep those users moving.

A self-contained .NET application bundles the runtime, the framework libraries, and the application binaries into a single folder. There is no assumption that the target machine has a particular version of .NET installed, which is a real benefit in locked-down environments like hospitals, call centres, and the many government departments that standardise on older Windows builds. ClickOnce sits on top of this output and handles the manifest, the on-demand download, the signature, and the auto-update flow that users barely notice.

ClickOnce has been around since the .NET 2.0 days and it still works. It is not the new hotness, but for an internal tool used by a few hundred staff across a wide brown land, it remains hard to beat. The trick is wiring it up to a self-contained publish so that you get modern .NET behaviour, including the new rollforward rules, while still pushing the application out through a familiar ClickOnce channel.

The rest of this piece walks through the configuration that makes the pairing work, the manifest settings that matter, the way the runtime resolves a host when the user has multiple .NET versions installed, and the operational patterns that suit Australian teams split between Perth and the east coast.

Why self-contained matters for Australian enterprises

Self-contained deployment solves a problem that has bitten plenty of Australian IT teams. A medium-sized logistics company in Brisbane might have a fleet of warehouse PCs that were imaged in 2019 and have never received a .NET upgrade. A framework-dependent publish assumes the host has the right runtime; a self-contained publish ships the runtime in the application folder and the app boots from there. Nothing is asked of the target machine beyond a working copy of Windows.

The pattern also reduces the surface area for those awkward support calls. Instead of asking a branch office in Adelaide to download a 70 MB runtime installer, the application simply carries it along. For organisations subject to the Australian Cyber Security Centre's Essential Eight, fewer external dependencies mean fewer items to add to the patch register. The trade-off is a larger initial download, which matters for regional sites on slower links.

The main thing to remember is that self-contained does not mean single-file. ClickOnce does not play nicely with single-file artefacts because the publish step needs a folder of files to wrap into the manifest. Plan on distributing a directory of DLLs alongside your EXE.

Configuring the project for self-contained publishing

Open the .csproj of the WinForms project and add the relevant properties inside the first PropertyGroup:

<PublishSingleFile>false</PublishSingleFile>
<SelfContained>true</SelfContained>
<RuntimeIdentifier>win-x64</RuntimeIdentifier>
<PublishReadyToRun>false</PublishReadyToRun>
<PublishTrimmed>false</PublishTrimmed>

RuntimeIdentifier is the key value. Most Australian corporate fleets are x64 these days, so win-x64 is the safe default. Setting PublishReadyToRun to false keeps the build simpler and avoids the Ahead-of-Time compilation step that occasionally surfaces odd startup differences between the developer machine and the user's PC.

Run dotnet publish -c Release -r win-x64 from a developer command prompt. The output lands in bin\Release\net8.0-windows\win-x64\publish\ and that folder is the one you feed into the ClickOnce tooling. There is no need to run a separate MageUI session; the new SDK-style projects can drive Mage for you through MSBuild.

Setting up ClickOnce manifests and the folder layout

The SDK-style WinForms project has ClickOnce support built in. Inside the same property group, add:

<GenerateClickOnceManifests>true</GenerateClickOnceManifests>
<Install>true</Install>
<PublishUrl>https://intranet.example.com.au/clickonce/myapp/</PublishUrl>
<ApplicationRevision>1</ApplicationRevision>
<IsIncrementalBuild>false</IsIncrementalBuild>

Set IsIncrementalBuild to false so that each publish regenerates the manifest cleanly. The PublishUrl is where the .application file lives on your internal web server or file share. Many Australian teams use a UNC share on a file server in their data centre because the WebDAV configuration on IIS is one more thing to look after, and the share is simpler to lock down with NTFS permissions.

A self-contained publish produces a much larger folder, which is the main thing to communicate to operations. The .NET 8 self-contained output for a typical WinForms app weighs in around 70 MB for the runtime, plus your own DLLs. Once zipped and split into ClickOnce blocks, the user download is manageable on most Australian corporate networks.

Handling .NET runtime rollforward in ClickOnce

Self-contained publishes normally fix the runtime version, but inside the publish folder the apphost still respects the runtimeconfig.json file. You can add a rollForward policy there to control what happens if the folder ever ends up next to a newer runtime. For most enterprise scenarios the sensible choice is LatestMinor:

{
  "runtimeOptions": {
    "rollForward": "LatestMinor",
    "tfm": "net8.0",
    "framework": {
      "name": "Microsoft.NETCore.App",
      "version": "8.0.0"
    }
  }
}

The reason this matters in a ClickOnce world is that the application folder is stable. A user can pin the shortcut to the taskbar and expect it to keep working when the next version of the app is published. Rollforward buys forward compatibility without requiring a re-sign of the manifest. Leave the host files alone during a ClickOnce update and only replace your own assemblies; the MSBuild-driven publish workflow does this correctly by default as long as you do not delete the publish folder between runs.

Signing, trust and the end-user prompt

ClickOnce applications need to be signed, otherwise users see a publisher unknown warning and some corporate Group Policies will block the install outright. The .NET SDK can produce a test certificate for development, but for production you want a real one. Many Australian organisations request a code-signing certificate from their existing PKI team, or buy one from an Australian reseller of Sectigo or DigiCert.

Add these to the project file:

<ManifestCertificateThumbprint>YOUR_THUMBPRINT</ManifestCertificateThumbprint>
<ManifestKeyFile>MyKey.pfx</ManifestKeyFile>
<ManifestTimestampUrl>http://timestamp.digicert.com</ManifestTimestampUrl>

The timestamp URL matters because ClickOnce validates that the certificate was valid at the moment of signing. Without a timestamp, the manifest will start to fail validation when the certificate approaches its expiry, even if the signature itself is fine. Pick a timestamping service that you can rely on, and mirror its URL in your release notes so that operations staff know what it is when they see it in a failed deployment log.

Automating the build and working across time zones

Once the configuration is in place, the build should be automated. Azure DevOps Server is still the default in many Australian enterprises, especially the federal agencies in Canberra, while smaller shops have largely moved to GitHub Actions or Azure Pipelines in the cloud. A typical pipeline step looks like this:

- script: dotnet publish src/MyWinFormsApp/MyWinFormsApp.csproj -c Release -r win-x64
  displayName: 'Publish self-contained build'

- task: CopyFiles@2
  inputs:
    SourceFolder: 'src/MyWinFormsApp/bin/Release/net8.0-windows/win-x64/publish'
    Contents: '**'
    TargetFolder: '$(Build.ArtifactStagingDirectory)/clickonce'
    CleanTargetFolder: true

The publish step is followed by a copy to a staging folder and then a push to the file share that hosts the ClickOnce manifests. Keep the manifest version in a single file that both the build and the release notes consume, so a developer on the Gold Coast and a tester in Hobart are looking at the same version string.

Deployments tend to be scheduled for early in the AEST morning, before the Sydney and Melbourne trading floors log on, or for late in the day once the Perth office has clocked off. Keeping the build automated means the release engineer can trigger a publish from anywhere in the country and have it land on schedule.

Operational tips for distributed teams

A few practical habits make life easier. Keep a smoke-test script that launches the app on a clean Windows VM and exercises the most common user journey; run it in the pipeline before the publish step signs the manifest. Document the rollback path. ClickOnce supports rolling back to a previous version, but only if the previous .application file is still on the server, so a small retention policy of the last three versions covers most mishaps.

Watch the size of the publish output. If the runtime folder starts to balloon, audit whether the application is accidentally pulling in a heavy NuGet package. Log the manifest version inside the application itself so that support staff can read it from the About box. Do not forget the user's offline experience. ClickOnce has an "online only" mode that will refuse to start the app without a network connection, which is the wrong default for a desktop tool used in regional Queensland.

Self-contained .NET applications delivered through ClickOnce are a dependable middle ground for Australian Windows Forms shops. The user gets a familiar shortcut, the IT team gets a controlled update channel, and the application is no longer at the mercy of whatever runtime happens to be on the target machine. With a small amount of project file tuning and a steady build pipeline, the pairing will quietly keep doing its job for years.