v2.6.2: The template installs from nuget.org: dotnet new install SawKing.DotNetSolutionKit.

The template installs from nuget.org: dotnet new install SawKing.DotNetSolutionKit.

• The package has a page of its own on nuget.org: an icon, the install and generate commands, the parameters with links to the documentation on dnsk.sawking.tech, and a link to the notes of its release.
• The README and the site install the template from nuget.org; a release still carries the package as a file.
• dotnet new list and search show the template with a plain description and the Web and WebAPI classifications; its identity is SawKing.DotNetSolutionKit, as the package's. Installed from nuget.org, 2.6.1 is replaced by the update. Installed from a .nupkg file, remove it first with dotnet new uninstall, or both stay listed.

How to update a solution generated from an earlier version: upgrading.

v2.6.1: The first push of a generated solution passes the secret scan.

The first push of a generated solution passes the secret scan.

• The idempotency test's key looked like an API key to gitleaks. The generated secret scan checks only the commits a push brings in, so it failed only the first push of a new solution, where every file is new.
• The template's CI scans each generated solution in full with the solution's own gitleaks rules.

How to update a solution generated from an earlier version: upgrading.

v2.6.0: A service's tests can be NUnit or xUnit, on one shared test infrastructure.

A service's tests can be NUnit or xUnit, on one shared test infrastructure.

• --TestFramework xunit generates a service's tests on xUnit v3; an integration test carries its category as the trait TestCategory, so CI selects it as it selects an NUnit category.
• Common.Testing holds the test execution contexts, the PostgreSQL test databases, the stubs and the rule checks, with no test framework; Common.Tests and the services' tests reference it. TestSkip lets each test framework say how it skips a test.
• Updating an earlier solution: a service's test project references Common.Testing instead of Common.Tests, and sets TestSkip.Handler; see upgrading.

How to update a solution generated from an earlier version: upgrading.

v2.5.0: An audit journal of entity changes, published through the outbox, with guards for writes it cannot see.

An audit journal of entity changes, published through the outbox, with guards for writes it cannot see.

• --Audit with --Messaging outbox: an entity marked [Auditable] publishes AuditRecordedV1 for every change, in the same transaction, with the actor, the tenants, the diff and the correlation identifier; [AuditRedact] records a secret changing without its value.
• IAuditRecorder and ISetBasedAuditCapture record writes past the change tracker; AuditBulkRecordedV1 carries the rows before and after.
• A generated service runs four guards: every entity decided, markers valid, no secret in the journal, every set-based write declared with [SetBasedWrite].

How to update a solution generated from an earlier version: upgrading.

v2.4.0: Tokens in HttpOnly cookies with CSRF protection, set by the deployment instead of guessed.

Tokens in HttpOnly cookies with CSRF protection, set by the deployment instead of guessed.

• AuthCookies:SameSite and AuthCookies:ServedOverHttps state the deployment; SameSite=None without HTTPS, or with any CORS origin and credentials, refuses to start with what to change.
• With AuthCookies:RequireCsrfHeader, a POST, PUT, PATCH or DELETE a token cookie would authenticate needs the X-CSRF header, or is refused with 403 CSRF_HEADER_MISSING; Authorization headers and API keys are not checked.
• IssueTokenCookies, ReadRefreshTokenCookie and ClearTokenCookies cover login, refresh and logout; a rule test in a generated service fails when a response carries a token.
• A service generated now has the section with Lax and the check on. Without it, as in an earlier solution, cookies behave as before; add the section once the frontend sends the header.

How to update a solution generated from an earlier version: upgrading.

v2.3.0: A secret store outage is survivable, and one feature flag can be changed during it.

A secret store outage is survivable, and one feature flag can be changed during it.

• Infisical__SnapshotPath: every successful read of the secret store is copied to a file only its owner can read, and a start that cannot reach the store runs on that copy, with a warning. Off by default, because the copy holds the secrets.
• "pinned": true on a flag in features.json makes the file decide it, over the store, its snapshot and environment variables; such flags report the source Pinned, and every start names them in a warning.
• Only the file can pin a flag, so the store cannot lock its own values in.

How to update a solution generated from an earlier version: upgrading.

v2.2.0: Commands a client may repeat run once per key.

Commands a client may repeat run once per key.

• IIdempotentExecutor: the first request with a key does the work and records its answer in the same transaction; a repeat gets that answer. Two requests racing with one key create one thing, decided by a unique index.
• A key reused for another operation, a failed attempt, an answer that must not be stored and a duplicate the work itself refuses each get their own outcome; see persistence.
• Opt in per service: modelBuilder.AddIdempotencyLog() and services.AddIdempotency(). Tested on PostgreSQL.

How to update a solution generated from an earlier version: upgrading.

v2.1.3: Images are named after the product too, so two solutions on one host keep their own.

Images are named after the product too, so two solutions on one host keep their own.

• Fixed: an image was named /, and two solutions with an Orders service on one host built and ran each other's image; it is now /-.
• deploy/build-images.sh reads each service's image name from its deploy files, so a service generated by an earlier version keeps its name. In a solution generated earlier, take the new build-images.sh before generating a service with this version.

How to update a solution generated from an earlier version: upgrading.

v2.1.2: Blue-green keeps the serving color serving when a deploy fails.

Blue-green keeps the serving color serving when a deploy fails.

• Fixed: when the edge did not answer after the switch, bluegreen.sh exited with the edge left on the new color; it now points the edge back at the previous one.
• Fixed: an infrastructure container recreated during up, by a changed setting or image, left the running color without its database; both colors are reconnected.
• A color that does not become ready is stopped and its last log lines printed; the active color is not touched.
• One bluegreen.sh run at a time; a lock left by a killed run is taken over.

How to update a solution generated from an earlier version: upgrading.

v2.1.1: Services are added to All.sln without a terminal too.

Services are added to All.sln without a terminal too.

• Fixed: src/services/manual-add-projects.sh failed with exit code 1 when run without a terminal, as in CI, on the pause it kept for a window opened by a double click.

How to update a solution generated from an earlier version: upgrading.