14.0.0: the refusal keeps its promise, because Studio can now open what it refuses

[dmitrat]

The audit in Docs/RELEASE-READINESS-2026-08-15.md found the code ready and the release not, for one reason: #206's message tells a user to convert their database by changing its password, and Studio — the tool that does that — could not open such a database at all. This closes it and prepares the release.

Studio

It recognises the refusal by its type — LegacyEncryptionException exists so nothing has to match a sentence that might be reworded — explains what happened in words that name the version and the remedy, and offers a checkbox that opens the database in the old format. Ticking it and pressing Connect gets the data; a notification then says the conversion is one password change away.

Beside it, a smaller thing with a wider reach: a failed open now carries its reason back. ConnectionManager.OpenAsync answered null and nothing else, so a database refused for one nameable reason reached the dialog as the same sentence as a file that is not a database at all.

Four parts, four separate red measurements, each naming its own place:

sabotage	red
the manager forgets the reason	the refusal is unexplained and LastOpenError is null
the dialog does not recognise the type	the offer never appears; the message is the generic one
the keyword is not written to the connection string	the database does not open with the box ticked
the checkbox is not in the markup	the markup case

Two controls: an ordinary refusal — a file that is not a database — is not offered the box, and the keyword is never written without a password, because it selects an encryption scheme and means nothing on its own.

The fixture is the 12.8.0 file 13.0.0 committed. A fixture rewritten by the new code tests nothing.

The release

seven packages	14.0.0, and the README install snippets with them
Studio	3.0.0-rc.2, with its own CHANGELOG section
CHANGELOG.md	a 14.0.0 section written for somebody whose application stopped opening its database

The README pins were not a matter of remembering. The lint added in #204 compares every PackageReference pin in the shipped READMEs against the version its own project declares, so forgetting them would have gone red rather than shipping a package that tells people to install the previous version. That is one of the two things 3.0.0 lacked.

Pre-flight pack-and-read, all seven into a throwaway folder:

package	version	internal dependencies
OutWit.Database.Core	14.0.0	—
OutWit.Database.Parser	14.0.0	—
OutWit.Database.Core.BouncyCastle	14.0.0	Core 14.0.0
OutWit.Database.Core.IndexedDb	14.0.0	Core 14.0.0
OutWit.Database	14.0.0	Core 14.0.0; Parser 14.0.0
OutWit.Database.AdoNet	14.0.0	OutWit.Database 14.0.0
OutWit.Database.EntityFramework	14.0.0	AdoNet 14.0.0

The version argument is #206 alone. Nothing else here can make a working application fail: the version strings change what an answer says, and everything else adds.

Tests

Core 2376, IndexedDb 153, Parser 815, Engine 2549, ADO.NET 1054, EF 593, Studio 903 — 8443 green. The local sweep includes the Performance category that CI excludes.

After this merges

Tag v14.0.0, push it, and publish from the tag in the documented grouping — Core + Parser, then BouncyCastle + IndexedDb, then OutWit.Database, AdoNet, EntityFramework one at a time — then verify from the downloaded nuspecs. Studio's own release is a separate act.

🤖 Generated with Claude Code