dtourolle/WatchedTogether
1
0
Fork 0
Code Issues Pull Requests Actions Packages Projects Releases 4 Wiki Activity

Set version to 0.0.1 and pin assembly identity for CI builds
🏗️ Build Plugin / build (push) Successful in 37s
Details
🚀 Release Plugin / build-and-release (push) Failing after 30s
Details
🧪 Test Plugin / test (push) Failing after 33s
Details

Browse Source 
The release and nightly workflows stamp a date-based version into
build.yaml (1.0.20260729.42). That build segment exceeds the 16-bit
limit AssemblyVersion and FileVersion require, so it would fail the
compile with CS7034 if it reached them.

Directory.Build.targets is imported after Directory.Build.props and is
not rewritten by CI, so pinning the assembly identity there keeps those
builds working. The manifest version is untouched - Jellyfin identifies
plugins by GUID plus manifest version, not assembly version. Verified by
building with a date-based version injected.
This commit is contained in:
dtourolle
2026-07-29 00:17:10 +02:00
parent b4134dd744
commit 92c7dcb871
3 changed files with 20 additions and 4 deletions
Download Patch File Download Diff File Expand all files Collapse all files
Directory.Build.targets
+16
View File
@@ -0,0 +1,16 @@
<Project>
<!--
The CI workflows stamp a date-based version into build.yaml (e.g. 1.0.20260729.42). The build
segment (20260729) exceeds the 16-bit limit (0-65535) that AssemblyVersion and FileVersion
require, which fails the compile with CS7034/CS7035 if it ever reaches those properties.
Directory.Build.targets is imported after the project and after Directory.Build.props, and no
workflow rewrites it, so pinning valid assembly identities here keeps the build safe. Only the
.NET assembly identity is normalised; the plugin manifest version is unaffected, and Jellyfin
identifies plugins by GUID plus manifest version rather than by assembly version.
-->
<PropertyGroup>
<AssemblyVersion>1.0.0.0</AssemblyVersion>
<FileVersion>1.0.0.0</FileVersion>
</PropertyGroup>
</Project>