跳到主要内容

Release

Today's release flow is fully manual. A couple of auto-update approaches are sketched below as a design-doc placeholder — none are implemented yet.

Current manual flow​

1. Bump and commit​

  • WmsSyncHub/Properties/AssemblyInfo.cs → bump AssemblyVersion + AssemblyFileVersion.
  • WmsSyncHubApi/Properties/AssemblyInfo.cs → same.
  • Update CHANGELOG.md in the main repo with what shipped.
  • Commit: chore(release): v1.0.3.

2. Build​

msbuild WmsSyncHub.sln /p:Configuration=Release /t:Rebuild

3. Package​

  • The plugin: pack the .app per Outer Loop.
  • The API: zip up WmsSyncHubApi\bin\Release\* plus appsettings.json (with customer credentials patched in, not dev).

4. Ship via AnyDesk​

  1. Connect to the customer workstation via AnyDesk.
  2. Stop the running WmsSyncHubApi.exe (Task Manager or Services).
  3. Copy the new API zip, unzip over the existing folder (keep their appsettings.json).
  4. In AutoCount → Tools → Plug-in Manager → Uninstall old version → restart → Install plug-in new .app → restart again.
  5. Start WmsSyncHubApi.exe (it auto-runs migrations).
  6. Open FormWmsSync, verify the 5 tabs load and the API ping is green.
  7. Smoke-test: sync one item, push one picking note, simulate a Shipped callback.

5. Commit the deployed version tag​

Tag the commit v1.0.3 in git, push.

Future — auto-update (not implemented)​

We have considered four approaches. None are implemented; this section is a design-doc stub so whoever picks up the work does not start from zero.

Option A — plugin-initiated​

Plugin pings a central manifest on launch, compares versions, offers to download + install.

  • Pro: zero infra, updates on every form open.
  • Con: Plug-in Manager requires an AutoCount restart, which the plugin cannot force. User must cooperate.

Option B — service-polling​

WmsSyncHubApi.exe polls a manifest, downloads, and swaps files on next restart.

  • Pro: background-silent.
  • Con: Can only update the API half, not the plugin half. Plugin updates still need manual install.

Option C — scheduled task​

A Windows Scheduled Task runs a small updater .exe nightly, which pulls from a central URL and restarts both services.

  • Pro: fully hands-off.
  • Con: needs Windows admin rights on the customer box — which is exactly the thing we try to avoid during install.

Option D — manual ZIP + instructions​

The status quo. A RELEASE.md + ZIP package, emailed to the customer.

  • Pro: no infra at all.
  • Con: brittle, error-prone, time-consuming.

Likely decision​

Hybrid of B + D: API polls and self-updates silently; plugin stays manual-via-AnyDesk because AutoCount restarts are a human-involved step anyway.

Caution​

:::caution Always migrate the API and the plugin together Migrations.cs exists in both projects and must stay in sync. If you ship a new API with M006 but the plugin is still at M005, the plugin may read a column it does not know about — or worse, write a schema shape the API assumes is already fixed. Bump both, ship both. :::

:::caution Never ship dev credentials The dev WMSSyncHubShadowMain\App.config is only for the inner loop. Release packaging must strip it. Similarly appsettings.Development.json must not ship. The canonical templates end in .example. :::