Skip to content

chore: sync alpha → alpha-backup (automated) - #3353

Merged
PWagner1 merged 2 commits into
alpha-backupfrom
alpha
Apr 25, 2026
Merged

chore: sync alpha → alpha-backup (automated)#3353
PWagner1 merged 2 commits into
alpha-backupfrom
alpha

Conversation

@github-actions

Copy link
Copy Markdown

Automated PR: alpha has had commits in the last 24 hours. Merge to update alpha-backup.

Triggered by Alpha to Alpha-Backup Sync workflow.

PWagner1 and others added 2 commits April 21, 2026 18:33
# Fix Discord release notifications reporting wrong version (4.0.0.0)

## Summary

Fixes incorrect version strings (notably **`4.0.0.0`**) in Discord embeds for nightly, canary, and stable release workflows by obtaining the package version through **evaluated MSBuild** and by removing a fragile **XPath fallback** that matched the wrong XML node.

Closes [#3341](#3341).

## Problem

The “Get Version” steps used this fallback when reading the version from `Krypton.Toolkit 2022.csproj`:

```powershell
$projXml.SelectSingleNode("//Version")
```

`//Version` matches the **first** `Version` element in the project file. In the Toolkit project, that is **not** the NuGet/assembly package version; it is the **`System.Design`** reference metadata (`<Version>4.0.0.0</Version>`). The real version is supplied by MSBuild imports (`LibraryVersion` / `Version` in `Directory.Build.props`).

Whenever assembly-based discovery failed or was skipped, the workflow fell back to this XPath and Discord showed **`4.0.0.0`** instead of the actual **110.x** style version.

## Solution

1. **Primary:** `dotnet msbuild` with **`-getProperty:Version`** and the correct **`-p:Configuration=…`** (`Nightly`, `Canary`, or `Release`) so the version matches full MSBuild evaluation (same as the build).
2. **Secondary:** Resolve `Krypton.Toolkit.dll` by walking candidate paths in a **fixed order** (`artifacts/bin/...` then `Bin/...`), using `Test-Path` / `Get-Item`, instead of `Get-ChildItem` on an array combined with `Select-Object -First 1` (order of results is not guaranteed).
3. **Removed** the broken `//Version` XML fallback entirely.

## Files changed

| File | Change |
|------|--------|
| `.github/workflows/nightly.yml` | Get Version step |
| `.github/workflows/canary.yml` | Get Version step |
| `.github/workflows/release.yml` | Get Version steps (stable ×2, canary ×1) |
| `.github/workflows/canary-lts-release.yml` | Get Version step + DLL candidates include `artifacts`, `Bin`, and legacy `Artefacts` |

## How to verify

- Locally (example for nightly):

  ```powershell
  dotnet msbuild "Source/Krypton Components/Krypton.Toolkit/Krypton.Toolkit 2022.csproj" -getProperty:Version -p:Configuration=Nightly -nologo -v:q
  ```

  Expect a **four-part numeric** version (e.g. `110.xx.mm.ddd`), not `4.0.0.0`.

- After merge: trigger or wait for a workflow that publishes and posts to Discord; the embed “Version” field should match the real toolkit build version.

## Notes

- This description file (`Documents/PR-3341-description.md`) is for maintainers to paste into the GitHub PR body; it can be deleted after the PR is merged if you prefer not to keep it in the tree.
# Fix Discord release notifications reporting wrong version (4.0.0.0)

## Summary

Fixes incorrect version strings (notably **`4.0.0.0`**) in Discord
embeds for nightly, canary, and stable release workflows by obtaining
the package version through **evaluated MSBuild** and by removing a
fragile **XPath fallback** that matched the wrong XML node.

Closes
[#3341](#3341).

## Problem

The “Get Version” steps used this fallback when reading the version from
`Krypton.Toolkit 2022.csproj`:

```powershell
$projXml.SelectSingleNode("//Version")
```

`//Version` matches the **first** `Version` element in the project file.
In the Toolkit project, that is **not** the NuGet/assembly package
version; it is the **`System.Design`** reference metadata
(`<Version>4.0.0.0</Version>`). The real version is supplied by MSBuild
imports (`LibraryVersion` / `Version` in `Directory.Build.props`).

Whenever assembly-based discovery failed or was skipped, the workflow
fell back to this XPath and Discord showed **`4.0.0.0`** instead of the
actual **110.x** style version.

## Solution

1. **Primary:** `dotnet msbuild` with **`-getProperty:Version`** and the
correct **`-p:Configuration=…`** (`Nightly`, `Canary`, or `Release`) so
the version matches full MSBuild evaluation (same as the build).
2. **Secondary:** Resolve `Krypton.Toolkit.dll` by walking candidate
paths in a **fixed order** (`artifacts/bin/...` then `Bin/...`), using
`Test-Path` / `Get-Item`, instead of `Get-ChildItem` on an array
combined with `Select-Object -First 1` (order of results is not
guaranteed).
3. **Removed** the broken `//Version` XML fallback entirely.

## Files changed

| File | Change |
|------|--------|
| `.github/workflows/nightly.yml` | Get Version step | |
`.github/workflows/canary.yml` | Get Version step | |
`.github/workflows/release.yml` | Get Version steps (stable ×2, canary
×1) | | `.github/workflows/canary-lts-release.yml` | Get Version step +
DLL candidates include `artifacts`, `Bin`, and legacy `Artefacts` |

## How to verify

- Locally (example for nightly):

```powershell dotnet msbuild "Source/Krypton
Components/Krypton.Toolkit/Krypton.Toolkit 2022.csproj"
-getProperty:Version -p:Configuration=Nightly -nologo -v:q ```

Expect a **four-part numeric** version (e.g. `110.xx.mm.ddd`), not
`4.0.0.0`.

- After merge: trigger or wait for a workflow that publishes and posts
to Discord; the embed “Version” field should match the real toolkit
build version.

## Notes

- This description file (`Documents/PR-3341-description.md`) is for
maintainers to paste into the GitHub PR body; it can be deleted after
the PR is merged if you prefer not to keep it in the tree.
@github-actions
github-actions Bot requested a review from a team as a code owner April 25, 2026 01:13
@PWagner1
PWagner1 merged commit 10930ce into alpha-backup Apr 25, 2026
10 of 12 checks passed
Sign up for free to join this conversation on GitHub. Already have an account? Sign in to comment

Labels

None yet

Projects

None yet

Development

Successfully merging this pull request may close these issues.

1 participant