Bump JasperFx to 2.101.0; point the CLI docs at JasperFx and its Native AOT support

Directory.Packages.props

@@ -301,16 +301,16 @@
              INERT:
              jasperfx#1099/#1103 fold an HTTP endpoint and a message handler in the Event Model, which
              Fisher contributes to but does not assert on. -->
-        <PackageVersion Include="JasperFx" Version="2.100.0" />
-        <PackageVersion Include="JasperFx.Events" Version="2.100.0" />
+        <PackageVersion Include="JasperFx" Version="2.101.0" />
+        <PackageVersion Include="JasperFx.Events" Version="2.101.0" />
         <!-- The shared cross-store event sourcing compliance suites. Source-only package: the
              suites compile inside Fisher.Tests so JasperFx's aggregate source generator binds
              Fisher's own session types. See src/Fisher.Tests/Compliance. -->
-        <PackageVersion Include="JasperFx.Events.ComplianceTests" Version="2.100.0" />
-        <PackageVersion Include="JasperFx.Events.SourceGenerator" Version="2.100.0" />
+        <PackageVersion Include="JasperFx.Events.ComplianceTests" Version="2.101.0" />
+        <PackageVersion Include="JasperFx.Events.SourceGenerator" Version="2.101.0" />
         <!-- Fisher.Tests only: the Microsoft.Extensions.AI adapter to IEmbeddingProvider, so the
              vector projection page's provider-wiring sample compiles. Fisher itself never takes it. -->
-        <PackageVersion Include="JasperFx.Events.MicrosoftExtensionsAI" Version="2.100.0" />
+        <PackageVersion Include="JasperFx.Events.MicrosoftExtensionsAI" Version="2.101.0" />
 
         <!-- Weasel 9.46.0 (from 9.42.0, spanning 9.43.0, 9.44.0, 9.45.0 and 9.45.1). JasperFx floor
              2.90.2, which Fisher already pins. Reaching Fisher:

HANDOFF.md

@@ -15,7 +15,7 @@ scoreboard and the things that are true right now but not obvious from either.
 **2996 tests green on net9.0 and net10.0** — 2925 in `Fisher.Tests`, 40 in
 `Fisher.AspNetCore.Tests` and 31 in `Fisher.EntityFrameworkCore.Tests`. 783 of
 them are shared cross-store compliance tests — 552 event sourcing and 231 document.
-On JasperFx **2.100.0** / Weasel **9.49.0**.
+On JasperFx **2.101.0** / Weasel **9.49.0**.
 
 ## The JasperFx 2.95.0 bump — the CritterWatch 1.1 checklist (fisher#475), and fisher#372
 
@@ -1004,7 +1004,7 @@ Three of the seven turned up a real defect or a wrong premise, which is the usef
 
 ## Where we are against the compliance suites
 
-`JasperFx.Events.ComplianceTests` 2.100.0 ships 64 suites; Fisher enrolls **63 of them, 783 tests**.
+`JasperFx.Events.ComplianceTests` 2.101.0 ships 64 suites; Fisher enrolls **63 of them, 783 tests**.
 Fisher passes **783 of them, across all
 63 suites**. Every suite compiles; every one is also subclassed and running. The five that did not
 pass on the 2.65.0 pin were the upstream ones described at the top of this file, and 2.66.0 closed

docs/configuration/native-aot.md

@@ -193,3 +193,22 @@ services.AddFisherStore<ILedgerStore, LedgerStore>(options =>
 
 The one-type-argument overload is refused by name in a native image, naming this one. Under the JIT
 both work the same way.
+
+## The command line
+
+An application that ends in `RunJasperFxCommands(args)` goes through the JasperFx command line on every
+start, because `run` is the default command. Since JasperFx 2.101.0 that works from a native binary, and
+so do `help`, `describe`, `check-env`, `resources` and `projections`: `JasperFx.SourceGenerator` registers
+the commands at compile time, so none of them is found by reflection. Two things follow:
+
+- **Every assembly that contributes commands must be built with the generator.** JasperFx and
+  JasperFx.Events are; add it to your own application for your own commands. A command from an assembly
+  built without it is missing from `help` in the native binary.
+- **The `db-*` commands are Weasel's,** so they are available natively from Weasel 9.50.0, the first release
+  built with the generator.
+
+`ApplyJasperFxExtensions` and `RunJasperFxCommands` keep their trimming warnings for assemblies built
+without the generator. Suppress them on an explicit `Main`, as
+[Running the command line in an AOT binary](https://shared-libs.jasperfx.net/codegen/aot#running-the-command-line-in-an-aot-binary)
+shows, and see [Native AOT](https://shared-libs.jasperfx.net/cli/#native-aot) in the JasperFx command line
+documentation for the package reference.

docs/schema/index.md

@@ -83,6 +83,16 @@ dotnet run -- resources setup      # create or migrate each one
 | [`db-apply`](https://weasel.jasperfx.net/cli/db-apply.html), [`db-assert`](https://weasel.jasperfx.net/cli/db-assert.html), [`db-patch`](https://weasel.jasperfx.net/cli/db-patch.html), [`db-dump`](https://weasel.jasperfx.net/cli/db-dump.html), [`db-list`](https://weasel.jasperfx.net/cli/db-list.html) | Weasel's, and act on Weasel databases only. Fisher registers every database it manages with Weasel |
 | [`resources`](https://shared-libs.jasperfx.net/cli/resources.html) | JasperFx's stateful resource model. The Fisher store is one resource; on a Wolverine host its message storage and any broker queues are others, and one `resources setup` provisions all of them |
 
+::: tip The command line itself
+`RunJasperFxCommands` and the rest of the command line come from JasperFx; its
+[command line documentation](https://shared-libs.jasperfx.net/cli/) covers setup,
+[writing your own commands](https://shared-libs.jasperfx.net/cli/writing-commands),
+[arguments and flags](https://shared-libs.jasperfx.net/cli/arguments-flags),
+[environment checks](https://shared-libs.jasperfx.net/cli/environment-checks) and `describe`. Since JasperFx 2.101.0
+the commands also run from a Native AOT binary: see [Native AOT](https://shared-libs.jasperfx.net/cli/#native-aot)
+there and [the command line](/configuration/native-aot#the-command-line) on Fisher's Native AOT page.
+:::
+
 `db-apply` and `resources setup` are an *explicit* instruction to migrate, so both treat `AutoCreate.None` as
 `CreateOrUpdate`. `db-assert` and `resources check` never change anything.
 

smoke/aot-consumer/AotConsumer.csproj

@@ -32,7 +32,7 @@
         <!-- fisher#398. A project reference does not carry the analyzer the Fisher package bundles, so
              the generator is referenced here as an application referencing JasperFx directly would.
              Kept in step with Directory.Packages.props by hand. -->
-        <PackageReference Include="JasperFx.Events.SourceGenerator" Version="2.100.0" PrivateAssets="all" />
+        <PackageReference Include="JasperFx.Events.SourceGenerator" Version="2.101.0" PrivateAssets="all" />
     </ItemGroup>
 
 </Project>

src/Fisher.Tests/Compliance/compliance_suite_inventory.cs

@@ -5,7 +5,7 @@
 // Deliberately NOT Fisher.Tests.Compliance, although it sits beside the fixtures it audits:
 // scripts/check_scoreboard.py counts every test class in that namespace as an enrolled compliance suite,
 // and this class is an audit of the enrollment, not a suite JasperFx ships. In that namespace it would
-// read as a sixty-fourth enrolled suite of the sixty-four 2.100.0 ships, while it exists to prove that
+// read as a sixty-fourth enrolled suite of the sixty-four 2.101.0 ships, while it exists to prove that
 // exactly one of them (SingleTenantedEventSlicingCompliance) is not enrolled.
 namespace Fisher.Tests;
 

src/Fisher.Tests/Compliance/fisher_event_store_compliance.cs

@@ -9,7 +9,7 @@ namespace Fisher.Tests.Compliance;
  * these tests cannot drift between the products.
  *
  * Suites were added one at a time as Fisher grew into them, and sixty-three are enrolled from
- * JasperFx.Events.ComplianceTests 2.100.0, which itself ships sixty-four concrete suites across
+ * JasperFx.Events.ComplianceTests 2.101.0, which itself ships sixty-four concrete suites across
  * sixty-three files -- MultiDatabaseExplorerCompliance is one file holding two arms. One is not
  * enrolled: SingleTenantedEventSlicingCompliance, for the precondition reason set out below.
  *