Packaging and Publishing

Packaging & publishing

WidBar finds widgets through a Windows AppExtension. The template sets all of this up, so most of the time you won't touch it — but it's worth understanding the three pieces so you know what you're changing when you do.

plugin.json — generated, don't edit by hand

Your widget advertises itself with a small plugin.json. You never write it: the SDK build target generates obj\widbar\plugin.json from MSBuild properties in the ExtensionApp .csproj. Edit the properties and the JSON follows.

<PropertyGroup>
  <WidBarPluginId>com.contoso.weather</WidBarPluginId>
  <WidBarPluginName>Weather</WidBarPluginName>
  <WidBarPluginDescription>Compact weather widget.</WidBarPluginDescription>
  <WidBarPluginCategory>Information</WidBarPluginCategory>
  <WidBarPluginVersion>1.0.0</WidBarPluginVersion>
  <WidBarPluginPreviewWidth>188</WidBarPluginPreviewWidth>
  <WidBarPluginConfigurable>true</WidBarPluginConfigurable>
</PropertyGroup>

Keep WidBarPluginId identical to the Id your plugin class returns — if they drift, WidBar won't match the catalog entry to the running plugin.

The package manifest

Package.appxmanifest in the packaging project declares the AppExtension that makes you discoverable:

<uap3:Extension Category="windows.appExtension">
  <uap3:AppExtension Name="com.widbar.widget" Id="weather"
                     PublicFolder="Public" DisplayName="Weather">
    <uap3:Properties>
      <WidBarPluginId>com.contoso.weather</WidBarPluginId>
      <WidBarSdkVersion>2</WidBarSdkVersion>
    </uap3:Properties>
  </uap3:AppExtension>
</uap3:Extension>

Name="com.widbar.widget" is the contract WidBar scans for — leave it exactly that. WidBarSdkVersion is the host contract version (currently 2). And you'll need runFullTrust in your capabilities.

The only thing that goes in the Public folder is the generated manifest, linked in from the wapproj:

<Content Include="..\Contoso.Weather.ExtensionApp\obj\widbar\plugin.json">
  <Link>Public\plugin.json</Link>
</Content>

Your actual code — every DLL, managed or native — ships as normal app payload of the executable. Nothing special, no shared probing, no version fights with other widgets, because you're in your own process.

Architectures

Build for the architectures Windows 11 runs on: x64 and arm64. A Store bundle built in StoreUpload mode gives you a single .msixupload that carries both.

Getting onto the Store

Reserve your app name in Partner Center and point the packaging project's Identity/Publisher at it (Associate App with the Store in Visual Studio does this). Build Release, which produces the .msixupload, and upload it under your app's Packages in Partner Center. The Store re-signs the package, so you don't ship signing certificates yourself.

Showing up in WidBar's showcase

WidBar has an in-app showcase backed by a public catalog. Listing is optional and free: open a PR against andelby/winbar-showcase with an entry for your widget.

{
  "id": "contoso-weather",
  "pluginId": "com.contoso.weather",
  "name": "Weather",
  "summary": "Compact weather, right on the taskbar.",
  "publisher": "Contoso",
  "category": "system",
  "storeProductId": "9NXXXXXXXXXX",
  "iconUrl": "https://.../weather.png",
  "localizations": { "it-IT": { "name": "Meteo", "summary": "…" } }
}

pluginId has to match your widget's Id — that's what WidBar uses to show an "Installed" badge — and storeProductId is your Store product ID.