v2.3.1

v2.3.1

A small release, but it renames one public property and changes when
AppInfo.InstallDate/InstallLocation resolve. Nothing moves your users' stored data.

Deprecated: AppInfo.AppGuid is now AppInfo.AppId

The old name promised a GUID that the value never had to be. Inno Setup's own AppId defaults
to the application name, and since this identifier doubles as the storage folder name
(%LocalAppData%\{Company}\{AppId}\), a readable string is usually the better choice.

• IAppInfo.AppId / AppInfo.AppId are the real members from now on.
• AppGuid still exists, still returns the identical value, and is marked [Obsolete]. It will
  be removed in a future release.
• The Barbatos.Wpf.ApplicationModel.AppInfo.AppGuid assembly metadata key is still honoured as
  a fallback for the new ...AppInfo.AppId key.

Nothing moves. Preferences, SecureStorage and FileSystem.AppDataDirectory resolve to
exactly the same folder as before, whether you rename or not.

One real break: if you implement IAppInfo yourself (a custom implementation, a test
double), rename your property to AppId. Everyone who only calls it gets a warning, not an
error.

- <AssemblyMetadata Include="Barbatos.Wpf.ApplicationModel.AppInfo.AppGuid" Value="..." />
+ <AssemblyMetadata Include="Barbatos.Wpf.ApplicationModel.AppInfo.AppId"   Value="..." />

Changed: the uninstall registry lookup no longer guesses

AppInfo.InstallDate and AppInfo.InstallLocation read ...\Uninstall\{AppId}. That lookup
used to append a hardcoded _is1 suffix speculatively, and bailed out entirely unless the
identifier parsed as a GUID. Both are gone:

• The subkey name is used verbatim. A GUID-shaped one is still normalised to the braced
  {...} form the registry convention uses, so C6BB… and {C6BB…} both work.
• A non-GUID AppId now resolves. An app identified as Contoso.MyApp and installed under
  ...\Uninstall\Contoso.MyApp previously always returned null. It works now.

New: UninstallRegistryKey, for installers that register under another name

Installers do not all name their uninstall key after the identifier your app knows itself by.
Point the lookup at the real name instead of bending AppId to match it:

<AssemblyMetadata Include="Barbatos.Wpf.ApplicationModel.AppInfo.AppId" Value="Contoso.MyApp" />
<AssemblyMetadata Include="Barbatos.Wpf.ApplicationModel.AppInfo.UninstallRegistryKey" Value="Contoso.MyApp_is1" />

It defaults to AppId, so apps whose installer already matches need nothing.

If you ship with Inno Setup, you need this line. Inno Setup always appends _is1 to its
own AppId when naming the uninstall key (AppId=MyProgram → ...\Uninstall\MyProgram_is1),
and there is no directive to change or remove that suffix — only CreateUninstallRegKey=no,
which removes the entry altogether. Verified against the [Setup]: AppId and
[Setup]: CreateUninstallRegKey topics shipped in ISetup.chm 6.4.3.

Keep the suffix in UninstallRegistryKey, not in AppId — AppId is also your storage folder
name, and it can never be changed after shipping without stranding existing user data.

MSI/WiX needs no override: its uninstall key is the product code.

Fixed: sample apps reported the library's version

Every sample set <Version>1.0.0</Version> but inherited <AssemblyVersion> from the repo's
Directory.Build.props, and the .NET SDK derives FileVersion from AssemblyVersion rather
than from Version. So each sample built as AssemblyVersion/FileVersion 2.3.1 against
InformationalVersion 1.0.0 — File Explorer, an installer or a crash reporter would report the
library's version for a sample app, while only NuGet and AppInfo.VersionString saw 1.0.0.

This affected the samples in this repo, not the shipped packages. It is worth knowing about for
your own apps, because the same trap applies to any project that sets only <Version>:

<Version>1.0.0</Version>
<AssemblyVersion>$(Version)</AssemblyVersion>
<FileVersion>$(Version)</FileVersion>

(AssemblyVersion and FileVersion take numeric parts only — for 1.1.0-beta.1, set both to
the bare 1.1.0.)

Template: barbatos-wpf-app now generates a shippable identity

The starter template had no app identity or version configuration at all. It now generates:

• The three-property version block above, wired to one <Version>.
• Product / Company / Copyright, and an AppInfo.AppId assembly metadata line defaulting
  to your project name — deliberately a readable string rather than a GUID, to show that it can
  be one.
• A commented-out UninstallRegistryKey line, ready for when you add an installer.

Package references move to 2.3.1. Change <Company> before you ship: together with AppId it
decides where user data lives.

Docs

src/Barbatos.Wpf.Core/README.md and API-REFERENCE.md are updated throughout, and the Inno
Setup guidance now cites its source. templates/README.md gains an App identity and version
section.

---

Coming from v2.1.0?

v2.2.0 and v2.3.0 were never tagged, so this release is the first tag since v2.1.0. In
between, the following landed — see the commit history for detail:

• Barbatos.Wpf.AquariusRouter — a Vue Router port for WPF, with its own sample.
• Barbatos.Wpf.AquariusValee — vee-validate-style form validation over DataAnnotations.
• Barbatos.Wpf.Core: InputSystem — in-app key bindings and RegisterHotKey global hotkeys.
• MCP and PushNotifications modules upgraded.
• Ejectable store interceptors and StoreInterceptorBuilder.
• Barbatos.Wpf.Samples.Shared for cross-sample component reuse.
• The barbatos-wpf-app template reworked into a module picker.