Show deployed version on the web viewer#257
Conversation
Reads PlanViewer.Web assembly version at runtime and renders it in two places so Joe (and anyone else giving feedback) can tell at a glance what version is deployed: - Landing page: small badge appended to the "Powered by Performance Studio" line - Toolbar (when a plan is loaded): badge on the right side next to the SQL Server build info deploy-web.yml now auto-syncs src/PlanViewer.Web/PlanViewer.Web.csproj Version with src/PlanViewer.App/PlanViewer.App.csproj Version before publishing, so the displayed version always matches the App release tag without needing manual csproj bumps in two places. Also widened the deploy-web path trigger to include App.csproj so version-only releases still redeploy the web. Version bump 1.7.2 -> 1.7.3. Co-Authored-By: Claude Opus 4.7 (1M context) <noreply@anthropic.com>
erikdarlingdata
left a comment
There was a problem hiding this comment.
What it does
- Surfaces the deployed
PlanViewer.Webassembly version as a badge on the landing page ("Powered by..." line) and on the toolbar when a plan is loaded. - Adds a CI step in
deploy-web.ymlthat rewrites<Version>inPlanViewer.Web.csprojfromPlanViewer.App.csprojbefore publish, so the two can't drift. - Bumps
PlanViewer.App1.7.2 → 1.7.3 and one-time-syncsPlanViewer.Web1.4.0 → 1.7.3 in source. - Broadens the workflow
paths:trigger to includePlanViewer.App.csprojso pure version-bump releases redeploy the web.
What's good
- Targets
dev, notmain. - Version-drift problem solved at the CI boundary rather than by process/discipline.
- Both new CSS classes reuse
var(--text-muted)instead of hardcoding a dim hex — good. AppVersionhelper handles a null.Versionwith a"?"fallback.
What needs attention
- PowerShell XML read in
deploy-web.ymlis brittle ifPlanViewer.App.csprojever gains a second<PropertyGroup>— see inline comment. Set-Content -NoNewlinesilently strips the trailing newline on the Web csproj — inline comment.margin-left: autoon.toolbar-app-versionwill carry share-url/delete-btn to the right with it, so the badge isn't solo-rightmost when those are rendered. Confirm intent — inline comment onapp.css:461.- Minor:
v.Buildassumption on a 3-part<Version>works today but silently drops a 4th component if ever used.
Not applicable / clean
- No Avalonia surface touched (no AvaloniaEdit/ComboBox/
:pointerover/code-behind concerns). - No PlanAnalyzer rule or scoring changes — no Dashboard/Lite sync needed.
- No logic in
src/beyond a display helper, so no missing test coverage to flag. - No swallowed exceptions, off-thread UI work, or post-dispose usage.
Generated by Claude Code
| - name: Sync web version with app version | ||
| shell: pwsh | ||
| run: | | ||
| $appVersion = ([xml](Get-Content src/PlanViewer.App/PlanViewer.App.csproj)).Project.PropertyGroup.Version | Where-Object { $_ } |
There was a problem hiding this comment.
([xml]...).Project.PropertyGroup.Version | Where-Object { $_ } assumes PlanViewer.App.csproj has exactly one <PropertyGroup> carrying <Version>. If a conditional second PropertyGroup is ever added (common when adding <PropertyGroup Condition="..."> blocks), .PropertyGroup becomes an array, .Version becomes a collection, and $appVersion interpolates as a space-separated string into the regex replace — producing an invalid <Version>1.7.3 </Version> or similar. Safer: Select-Xml -Path ... -XPath '/Project/PropertyGroup/Version[1]/text()' | ForEach-Object { $_.Node.Value }.
Generated by Claude Code
| $webCsproj = 'src/PlanViewer.Web/PlanViewer.Web.csproj' | ||
| $content = Get-Content $webCsproj -Raw | ||
| $content = [regex]::Replace($content, '<Version>[^<]+</Version>', "<Version>$appVersion</Version>") | ||
| Set-Content -Path $webCsproj -Value $content -NoNewline |
There was a problem hiding this comment.
Set-Content -NoNewline strips the trailing newline the csproj currently has. Harmless in CI since the file isn't committed back, but if anyone ever commits the rewritten file (e.g. a future step that does git add), they'll see a spurious EOL-only diff. Drop -NoNewline or append [Environment]::NewLine to $content.
Generated by Claude Code
| padding: 0.1rem 0.4rem; | ||
| border-radius: 3px; | ||
| background: rgba(0, 0, 0, 0.05); | ||
| margin-left: auto; |
There was a problem hiding this comment.
margin-left: auto on .toolbar-app-version pushes the badge right, but .toolbar is display: flex with .share-url and .delete-share-btn rendered after the badge in the markup (Index.razor:60-71). Those siblings get carried along to the right edge too, so the badge ends up left-of the share URL rather than solo on the right. If the intent (per PR body: "badge on the right when a plan is loaded") is for the badge to be the rightmost element, move the <span class="toolbar-app-version"> after the share-url/delete-btn blocks in the razor, or put margin-left: auto on whichever element should be the left edge of the right-aligned group.
Generated by Claude Code
| private static string GetAppVersion() | ||
| { | ||
| var v = typeof(Index).Assembly.GetName().Version; | ||
| return v == null ? "?" : $"v{v.Major}.{v.Minor}.{v.Build}"; |
There was a problem hiding this comment.
v.Build is the third component of System.Version (Major.Minor.Build.Revision), which for a <Version>1.7.3</Version> csproj resolves to AssemblyVersion 1.7.3.0 and renders v1.7.3 — correct. Worth noting: if the csproj ever uses a 4-part <Version> (e.g. 1.7.3.4), the Revision is silently dropped. Probably fine given the sync script writes 3-part versions, but flag if that assumption ever loosens.
Generated by Claude Code
Summary
Renders the deployed PlanViewer.Web assembly version on two surfaces so Joe (and anyone reviewing) can tell at a glance which release is live:
Why the small pile of changes
Test plan
🤖 Generated with Claude Code