Version 1.0.0 — pages, pairing, and compatibility update
What changed
Added distinct routes for Workspace (/), Backups (/backups), Settings (/settings), User Guide (/user-guide), and What's New (/whats-new). The three control pages share the existing browser pairing and operation status. Navigating in the same tab does not generate a new code or replay a command.
Workspace now contains folder selection and backup creation. Backups has a case-insensitive description/filename search and bounded pagination: 25 rows by default, with 10/25/50/100 choices and Previous/Next. The companion's existing newest-2,500-archive metadata limit remains; older ZIPs stay on the PC. Settings contains retention and manual cleanup, plus the browser pairing lifetime setting.
The connected indicator has hover and keyboard-focus help: Connected to local PC: [computer name]. Its offline and unpaired messages reflect those states. The header and control-page footer display the application version.
Pairing timeout: actual behavior
Previously, unused codes expired after 10 minutes and browser sessions had a hardcoded two-hour inactivity rule. Every automatic status request updated that inactivity timestamp, so an open page could keep it alive. Neither setting was exposed in the UI.
Now, unused codes still expire after 10 minutes. A claimed browser pairing has a fixed lifetime of 120 minutes by default, starting when the code is entered. Auto-disconnect in is computed from the relay's server-side expiry and refreshed about every two seconds. It becomes amber in its last five minutes. Polling, navigation, and reloads do not renew it.
On Settings, Auto-disconnect after (minutes) and Apply timeout and restart countdown explicitly choose a duration and restart the current session's timer. The default permitted range is 5–480 minutes. This choice is for the current pairing; a new pairing starts with the publisher's default. It is a lifetime limit, not a timer based on mouse or keyboard inactivity.
At expiry, the relay revokes browser authority and drops pending commands. A job already started by the companion remains local and can finish. The expired browser token cannot extend its own session. Wait for local jobs to finish, disconnect the companion, generate a new code, enter it, and approve the new connection on the PC. Website restarts and prolonged companion loss can end a session earlier than the countdown.
The 10-minute code validity and disconnected-agent cleanup, 20-second online indication, and Blazor/IIS recovery timeouts are separate controls. The new countdown does not predict an app-pool restart or network failure.
Publisher defaults
The website works with the built-in defaults without editing appsettings.json. To customize them, merge this section into your existing web appsettings.json, keeping Publisher and other existing sections intact:
"Pairing": {
"DefaultTimeoutMinutes": 120,
"MaximumTimeoutMinutes": 480
}
MaximumTimeoutMinutes is bounded to 5–1,440 minutes. DefaultTimeoutMinutes is bounded to 5 through the maximum. Individual sessions cannot exceed that maximum. Values are normalized to valid bounds rather than adding a new startup failure condition. A configuration change takes effect when the web app restarts; defaults apply to new pairings.
Windows Bedrock and Realms
All application pages display Windows Bedrock Edition ONLY and Local worlds only. Does not work with Realms. Java Edition, consoles, and mobile editions are not supported. This is the supported product scope. The backup engine still copies selected files without interpreting or converting their game format; this patch does not add a world-edition detector or Realms API integration.
The publisher reports running the application with Minecraft Bedrock Windows Edition 26.50. The separate Reported Bedrock version label now shows 26.50, with User-reported use; backup/restore verification pending. Running the application does not by itself record a complete backup, restore, and restored-world opening test. The tool does not detect an installed game version.
After validating a disposable local Windows Bedrock world through backup, restore, and opening the restored world in that release, merge the actual tested release and date into web appsettings.json:
"Compatibility": {
"ReportedBedrockVersion": "26.50",
"TestedBedrockVersion": "",
"VerificationDate": ""
}
The reported value defaults to 26.50 without a configuration edit. Replace the empty strings with the actual tested release and date when you have that result. After restart, a supplied TestedBedrockVersion takes precedence and the label becomes Verified Bedrock version. To clear the report, set ReportedBedrockVersion to an empty string; if both version fields are empty, the version reads Pending. These public values record the publisher's report or verification, not official Mojang approval or automatic compatibility with every later game update.
Versioning and documentation
1.0.0 is the first numbered application release. Earlier delivered patches are described as unversioned; no historical version numbers were invented.
Directory.Build.props holds the single <Version>1.0.0</Version> property inherited by the solution projects. ProductBranding reads the Core assembly's informational version, omitting optional build metadata, so the web display follows compiled metadata. The default SDK supplies assembly/file versions from this property. The /health response also reports the application version.
Use patch increments for fixes, minor increments for compatible features, and major increments for breaking changes. For a future release, update that property and docs/RELEASE-NOTES.md, then run the optional Python 3.10+ documentation utilities from the solution folder:
python scripts/Update-UserGuide.py
python scripts/Update-ReleasePages.py
The first regenerates the guide page and offline copy. The second regenerates What's New and readable HTML snapshots of every Markdown file in docs. Current generated output is included; Python and a Markdown package are not required to build or run the site. Review documents before publishing because all Markdown documents in docs become public snapshots.
Apply and publish in Visual Studio 2022
- This is a cumulative patch for the uploaded project, with or without the previous User Guide patch or initial v1.0.0 patch applied. It also includes the guide files and documentation needed by the new pages. The revised v1.0.0 patch adds the reported Bedrock 26.50 value without changing the application release number.
- Save your work and close Visual Studio. Extract this ZIP outside your solution.
- Run Apply-Patch.cmd and select the solution folder containing src/Mcs.Web/Mcs.Web.csproj. Recognized-source hash checks and payload checks run before writes. A customized target file stops the entire apply so it can be merged manually. Modified files are backed up beside the solution.
- Reopen Visual Studio and build Release. Run scripts/Validate.ps1 on Windows to execute the added relay expiry and pagination checks along with the existing tests.
- Publish Mcs.Web using your working profile, including its rebuilt Mcs.Core.dll and the new static documentation/CSS files. Existing installed companions remain API-compatible; no new agent endpoint or command type was added.
- Retain your working OutOfProcess hosting configuration, dedicated pool, real Publisher contact, and actual ZIP in App_Data/Downloads. This update does not change web.config, app-pool settings, publish profiles, or existing appsettings.json values.
This ZIP is a source patch, not a compiled server package. Applying Razor source directly to the IIS folder cannot add compiled pages. Existing companions need no forced reinstall; future companion builds inherit the version and revised scope description.
Verification
Added deterministic C# checks using a custom TimeProvider for fixed expiry despite polling, local approval, invalid duration bounds, explicit timer restart, expired-token rejection, no command delivery after expiry, and continued agent updates for already-started jobs. Added pagination/search boundary checks. All seven C# console checks passed in this environment, including the new tests. Core and Web source, including all Razor components, compiled without diagnostics using the installed .NET 8 Roslyn compiler and Razor source generator. The normal MSBuild command could not run under this environment's process isolation, so a complete VS/Windows publish and PowerShell application still require verification on your Windows PC.
Live browser checks against the compiled ASP.NET Core/Blazor app with a simulated companion cover pairing/local approval, tooltip hover/focus, routes, edition/version labels, 25-row pagination, search, selecting the correct restore filename on a later page, the explicit five-minute timer reset, mobile layout, documentation routes, updated guide/download, session restoration, and no command replay. No real world files were used in these browser checks. Existing 14 reconnect JavaScript tests pass. Patch replay, repeat-apply behavior, payload hashes, ZIP CRC, and unchanged deployment/configuration file checks are also performed. These checks do not replace a Windows companion test against a disposable real Bedrock world or an IIS publish test.
After building, use a disposable world and a five-minute session to check:
- Pair and approve. Visit all three control pages; confirm the same PC and decreasing expiry.
- Hover/focus the connection indicator. Check the version, scope, and current compatibility label.
- On Settings, apply a five-minute duration; check the reset and final-five-minute amber state.
- Leave the page open while status polling continues. At expiry, commands must stop and a new code/approval must be required.
- Start a test backup before expiry and let it finish locally after browser control ends. Re-pair and verify the completed ZIP.
- Search and page a large test archive list. Verify every action targets its selected filename, page size remains bounded, and no commands replay after navigation or reload.
- Open What's New, each documentation link, and the updated offline guide. Verify existing companion download and restore confirmations still work.
Rollback
Use the timestamped backup printed by Apply-Patch. Restore modified originals and remove only new paths listed in its ADDED-FILES.txt. Rebuild and republish Mcs.Web and its Core assembly. Retain worlds, archives, publisher settings, and hosting configuration. The patch does not modify any local world data.