feat: Refactor old build system into a proper Sdk#3085
Open
Kryptos-FR wants to merge 89 commits intostride3d:masterfrom
Open
feat: Refactor old build system into a proper Sdk#3085Kryptos-FR wants to merge 89 commits intostride3d:masterfrom
Kryptos-FR wants to merge 89 commits intostride3d:masterfrom
Conversation
- Add stride-build-properties-inventory.md documenting 100+ MSBuild properties - Catalog all custom items, targets, and conditional patterns - Document import chains and file structure - Update roadmap to mark Phase 1 as complete - Add cross-references between documentation files The inventory provides a complete specification for implementing Stride.Sdk in Phase 2.
To be removed
Looks like we don't need Stride.Sdk.Runtime after all
Add CLAUDE.md with build instructions, architecture overview, and coding guidelines for working with the Stride codebase. Add .claude/ folder with skill commands: - /build - Build solution or specific project via MSBuild - /build-sdk - Build SDK packages with NuGet cache management - /test - Run tests by category - /find-component - Find ECS components - /analyze-asset - Analyze Stride asset files - /explain-rendering - Explain rendering features - /sdk-status - Check SDK work progress - /msbuild-debug - Debug MSBuild issues
Create comprehensive SDK-WORK-GUIDE.md based on analysis of build system documentation from feature/build-analysis-and-improvements branch. The guide covers: - SDK development workflow and NuGet cache management - Package structure and MSBuild SDK conventions - Migration strategy from current 17-file build system - Current challenges (Graphics API targeting, platform detection) - Testing strategy and troubleshooting Update CLAUDE.md: - Add Build System section explaining multi-targeting complexity - Document key build properties (StridePlatform, StrideGraphicsApi) - Add SDK build commands with cache clearing instructions - Reference new SDK-WORK-GUIDE.md Update /build-sdk command: - Add context about SDK work goals and current status - Reference SDK-WORK-GUIDE.md for details This provides foundation for ongoing SDK-style build system rework that aims to consolidate ~3500 lines of MSBuild across 17 files into a clean, versioned Stride.Sdk package.
Add front matter with name and description to all 8 skill commands: - build, test, find-component - build-sdk, sdk-status - analyze-asset, explain-rendering - msbuild-debug This enables lazy loading of skill commands, preventing them from consuming context tokens until they are actually invoked. The front matter includes the command name and a brief description for display in skill listings.
Create SUMMARY.md capturing current session's work: - Claude Code configuration setup (CLAUDE.md, 8 skills) - SDK work documentation (SDK-WORK-GUIDE.md) - Critical SDK workflow with NuGet cache management - Build system context (17 files, 3500 lines, 30 configs) - Current SDK status and next steps Add /summarize-session skill command for automation: - Triggers at ~60% context usage (120k tokens) - Provides template and best practices for session handoffs - Ensures comprehensive context preservation - Includes examples of effective summaries This enables smooth context handoff when approaching token limits, maintaining continuity across sessions without losing critical information about workflows, gotchas, and progress.
- Add comprehensive MSBuild SDK evaluation order section to CLAUDE.md - Create SDK-PROPERTY-EVALUATION-ANALYSIS.md (400+ line detailed analysis) - Update SDK-WORK-GUIDE.md with evaluation timing and property phase analysis - Add explanatory header comments to Sdk.props and Sdk.targets - Document critical bug fix in Stride.Frameworks.targets - Update notes.txt with bug discovery and historical context - Create /analyze-csproj-migration and /compare-csproj-versions commands - Update /build-sdk and /sdk-status commands with evaluation reminders - Update SUMMARY.md with session handoff information Discovered critical evaluation order bug in sources/targets/Stride.Core.props:58 that has been silently failing for years. The old system checks StrideRuntime in the .props phase where user properties from .csproj are not yet visible, causing multi-targeting to only work via command-line properties. The new SDK correctly implements this check in Stride.Frameworks.targets (after .csproj loads), fixing this long-standing bug.
Add platform detection, code analysis, and assembly processor infrastructure to Stride.Sdk, enabling Stride.Core to build with SDK-style project format. New SDK files: - Stride.Platform.props: Platform detection (Windows/Linux/macOS) and output paths - Stride.Platform.targets: Platform defines (STRIDE_PLATFORM_DESKTOP, STRIDE_RUNTIME_CORECLR) - Stride.AssemblyProcessor.targets: Stub with defaults (full implementation deferred) - Stride.CodeAnalysis.targets: Code analysis ruleset integration Updated SDK files: - Sdk.props: Import Stride.Platform.props - Sdk.targets: Import new platform, assembly processor, and code analysis targets - Stride.Sdk.csproj: Package new files and Stride.ruleset - Stride.Frameworks.targets: Fix multi-targeting logic (remove StrideExplicitWindowsRuntime requirement) Updated project: - Stride.Core.csproj: Remove unused properties (StrideBuildTags, RestorePackages) Verified working: - Multi-targeting produces net10.0 and net10.0-windows outputs - Platform detection sets StridePlatform=Windows correctly - StridePlatforms property enables framework expansion - Code analysis uses Stride.ruleset from SDK package - Build succeeds with no errors Scope: Desktop platforms only (Windows/Linux/macOS) Deferred: Mobile/UWP platforms, full Assembly Processor implementation
Document completion of Stride.Core SDK migration for desktop platforms: - All 4 new SDK files created and working - Multi-targeting verified (net10.0 and net10.0-windows) - Platform detection and code analysis integration working - Critical NuGet cache clearing requirement documented Added comprehensive next steps: - High priority: Assembly Processor full implementation - Medium-term: Mobile/UWP support, additional project migrations - Long-term: Complete SDK migration for all projects Key learnings documented: - NuGet cache must be manually cleared after SDK changes - Property evaluation order critical for correctness - StridePlatforms semicolon pattern required for multi-targeting Next session should focus on Assembly Processor implementation.
…tion) Compacted SUMMARY.md from ~595 to 188 lines following new guidelines: - Latest session: Full detail on Assembly Processor implementation - Previous session: Condensed to key points only - Removed older session verbose details - Updated critical information and next steps Implementation status: - 3 files modified (~200 lines added) - Assembly Processor integration complete - Path fix applied, ready for testing
- Package Assembly Processor binaries with SDK in tools/AssemblyProcessor/ - Add TEMP property for cross-platform compatibility - Implement full Assembly Processor targets file (184 lines): * Path detection (SDK package vs source build) * Hash-based temp directory for file locking avoidance * PrepareForRunDependsOn integration * Explicit NuGet package references (add-reference) * Dev mode support (StrideAssemblyProcessorDev) * .usrdoc file handling for public APIs * Validation warnings if processor not found Tested with Stride.Core - builds successfully with processor execution verified. Implementation follows sources/core/Stride.Core/build/Stride.Core.targets pattern.
Final update to SUMMARY.md documenting successful completion: - Assembly Processor implementation verified working (commit 35eb779) - All success criteria met (SDK builds, packages binaries, Stride.Core builds) - Documented key discoveries (packaging gotchas, build tool requirements) - Ready for next phase: unit tests and additional project migrations Also updated summarize-session.md command with improved guidelines.
Migrated three core projects from old build system to SDK-style: - Stride.Core.IO: Removed unused StridePlatformDependent, StrideBuildTags - Stride.Core.MicroThreading: Removed unused StrideBuildTags - Stride.Core.Serialization: Clean migration with serialization support All projects build successfully with multi-targeting (net10.0, net10.0-windows). Note: Serialization unit tests currently failing with NullReferenceException in generated serializers - investigation needed for Assembly Processor.
Created comprehensive SDK for Stride test projects:
**Stride.Sdk.Tests features:**
- Composes Stride.Sdk + test-specific configuration
- Automatic xunit package references (Microsoft.NET.Test.Sdk, xunit, etc.)
- Test-specific output paths (bin/Tests/{ProjectName}/{Platform}/)
- Graphics API configuration for test projects
- IsTestProject=true for dotnet test discovery
- Shader code generation support
- Platform target metadata for test runners
**Stride.Core.Tests migration:**
- Migrated from old Stride.UnitTests.props/targets to Stride.Sdk.Tests
- Reduced from 30 lines to 29 lines (cleaner, SDK-based)
- Disabled xunit launcher (not needed for dotnet test)
- OutputType=Library instead of WinExe for standard test library
**Benefits:**
- Consistent SDK-based build system for both runtime and test projects
- Easier to maintain and extend
- Follows MSBuild SDK best practices
- Test projects can now use simple `<Project Sdk="Stride.Sdk.Tests">`
Note: All projects now use SDK-style, providing consistent build behavior
for investigating serialization test issues.
Migrate 10 more projects to SDK-style: - Runtime: Mathematics, Reflection, Design, Translation, Yaml, Tasks - Tests: Mathematics.Tests, Design.Tests, Yaml.Tests, CompilerServices.Tests Fix xunit launcher in Stride.Sdk.Tests: embed launcher .cs files in SDK package instead of using relative path to source tree (broke from NuGet). Re-enable xunit launcher for all test projects (was incorrectly disabled). Update roadmap to reflect completed phases 1-3.
Roslyn analyzer project - uses Stride.Sdk for versioning consistency. Removed unused StrideSkipAutoPack, empty Folder items, duplicate Using.
SDK changes: - Add Stride.Graphics.props (default graphics API per platform) - Add Stride.Graphics.targets (API defines, UI framework, multi-API lists) - Wire into Sdk.props and Sdk.targets Engine projects migrated to Sdk="Stride.Sdk": - Stride, Stride.Shaders, Stride.Rendering, Stride.Particles - Stride.Engine, Stride.Audio, Stride.UI, Stride.Navigation - Stride.Physics, Stride.SpriteStudio.Runtime, Stride.Voxels Removed unused properties: StrideBuildTags, StridePlatformDependent, ProductVersion, SchemaVersion, RestorePackages. Added explicit AllowUnsafeBlocks (was inherited from old Stride.props). Replaced $(StrideAssemblyProcessorDefaultOptions) with literal values.
…ls, presentation Migrated remaining engine projects (13), shader projects (3), build engine projects (2), asset projects (4), tool projects (17), and presentation projects (7) to Stride.Sdk format. Removed unused properties (StrideBuildTags, ProductVersion, SchemaVersion, RestorePackages, ProjectTypeGuids, ProjectGuid, ParadoxBuildTags). Replaced $(StrideAssemblyProcessorDefaultOptions) with literal values. Skipped: PublicApiCheck, PackageInstall, VisualStudio.PackageInstall (already SDK-style with Microsoft.NET.Sdk), editor projects (deferred), and test projects (use Stride.Sdk.Tests).
…m base SDK Introduces Stride.Sdk.Editor MSBuild SDK package that owns StrideEditorTargetFramework and StrideXplatEditorTargetFramework properties. This prevents engine/runtime projects from accidentally using editor-specific frameworks and prepares for future WPF to Avalonia migration by isolating editor build concerns. SDK hierarchy: Stride.Sdk -> Stride.Sdk.Editor -> Stride.Sdk.Tests - Created Stride.Sdk.Editor package (csproj, Sdk.props/targets, Stride.Editor.Frameworks.props) - Removed editor framework properties from Stride.Sdk/Stride.Frameworks.props - Updated Stride.Sdk.Tests to compose Stride.Sdk.Editor instead of Stride.Sdk - Updated 38 editor/tool/presentation .csproj files: Sdk="Stride.Sdk" -> Sdk="Stride.Sdk.Editor" - Added Stride.Sdk.Editor to global.json and Stride.Sdk.slnx
Runtime projects use Stride.Sdk directly with StrideRuntime=true. The Stride.Sdk.Runtime package was never referenced by any project.
Phases 1-5 complete, Phase 6 in progress. Added Stride.Sdk.Editor package, removed Stride.Sdk.Runtime. ~67% of projects migrated.
…e user-facing SDK Renames all three internal MSBuild SDK packages: - Stride.Sdk -> Stride.Build.Sdk - Stride.Sdk.Editor -> Stride.Build.Sdk.Editor - Stride.Sdk.Tests -> Stride.Build.Sdk.Tests Updates 126 consuming .csproj files, global.json, nuget.config, build scripts, GitHub actions, and documentation. Adds README.md to all SDK packages to eliminate NuGet warnings. Removes notes.txt.
Member
|
Except #3085 (comment) and some testing, is there any blocker? |
VaclavElias
changed the title
Add SDK build step to README.md build instructions with an explanation of why it must happen before opening Stride.sln in Visual Studio. Update sources/README.md to reflect the SDK-style build system. Add SDK build step to compile.bat and bump MSBuild version check to 17.
- Remove unnecessary condition on StrideAssemblyProcessor (nothing sets it before Sdk.props evaluation) - Replace StrideGraphicsApiDependent checks with StrideGraphicsApi checks for output/intermediate paths. StrideGraphicsApiDependent is set in .csproj which runs after Sdk.props, making the old conditions dead code. StrideGraphicsApi is available as a global property during inner builds.
Note that this workaround can be removed once NuGet supports custom inner build dimensions beyond TargetFramework.
Member
Author
|
@xen2 aside from testing, there shoudn't be any blockers. |
These were injected-layer wrappers pointing to Stride.sln.DotSettings, used by the old per-platform .sln files. The .slnf replacements all reference Stride.sln directly, so Stride.sln.DotSettings applies automatically.
Microsoft.VisualStudio.SDK: 17.0.31902.203 → 17.14.40265 Microsoft.VSSDK.BuildTools: 17.0.5232 → 17.14.2120
.NET SDK 10.0.201 promoted the MSBuild version check from warning (NETSDK1233) to a hard error: "Version 10.0.201 of the .NET SDK requires at least version 18.0.0 of MSBuild." This broke the build since windows-latest (windows-2025) only ships VS 2022 / MSBuild 17.x. Fix by switching to the windows-2025-vs2026 runner which has VS 2026 / MSBuild 18.x, and pin vs-version to [18.0,19.0). Alternative workaround: pin dotnet-version to '10.0.1xx' to stay on the SDK band where MSBuild 17.x is still allowed (with a warning).
Ethereal77
reviewed
Mar 23, 2026
The previous commit removed this section during the SDK documentation update. Restored with updated instructions reflecting the SDK-based build system: use Sdk="Stride.Build.Sdk" instead of the old PostSettings.Local.targets mechanism, and set StrideAssemblyProcessor directly in the project file.
Documents why it uses Microsoft.NET.Sdk instead of Stride.Build.Sdk (circular dependency), how it deploys binaries to deps/, and how projects opt in via StrideAssemblyProcessor property.
Ethereal77
reviewed
Mar 23, 2026
Contributor
|
Hey @Kryptos-FR , is there anything blocking migration to the new This new SDK refactor seems like a good opportunity to modernize that if possible. |
Member
Author
|
One drawback is that there is no filter format for .slnx, so either we need to have several .slnx and no .slnf, or we keep .sln along .slnf. |
Contributor
|
slnf works with slnx too. |
Member
Author
|
I didn't work for me earlier. I will try again. |
- Remove references to deleted .targets files - Add the Sdk projects
Kryptos-FR
force-pushed
the
feature/stride-sdk
branch
from
19ba691 to
f0ddfb6
Compare
Member
Author
|
I think I have handled all feedbacks. Ready for the final review. edit: Actually going back to manual imports breaks completely in Visual Studio. I need to check what I did. |
Projects no longer use `<Project Sdk="Stride.Build.Sdk">`. Every .csproj
now imports SDK props/targets directly from source:
<Project>
<Import Project="$([MSBuild]::GetDirectoryNameOfFileAbove(...))\sdk\...\Sdk.props" />
...
<Import Project="$(StrideRoot)sources\sdk\...\Sdk.targets" />
</Project>
The props import uses GetDirectoryNameOfFileAbove (no pre-set property
needed) and the targets import uses $(StrideRoot) (safe after the SDK
chain is loaded).
SDK internal cross-references (Editor and Tests SDKs) now use
$(MSBuildThisFileDirectory) relative paths instead of the Sdk= resolver.
Other changes:
- global.json: msbuild-sdks entries commented out
- nuget.config: stride-sdks source and packageSourceMapping commented out
- .github/actions/build-sdk: removed (no longer a prerequisite)
- build/compile.bat: removed SDK build step
- sources/Directory.Build.props: replaced TODO with explanatory comment
- build/docs/SDK-GUIDE.md: added direct-import section and revert guide
- sources/sdk/README.md: new file explaining import modes and revert steps
To revert to full-SDK mode: build SDK packages, uncomment global.json
and nuget.config entries, restore <Project Sdk="..."> opening tags, and
revert the four SDK internal files. See sources/sdk/README.md.
…ons.bat The tool generated platform-specific .sln files from Stride.sln using <StrideBuildTags> filtering and .Windows.csproj renaming. Both workflows are obsolete: - Platform solutions are now .slnf filters on Stride.slnx - Cross-platform targets are handled by multi-TFM in a single .csproj The project-unittest subcommand generated old-style multi-platform test project scaffolding (.Windows.csproj, AndroidManifest.xml, etc.) which is incompatible with the current SDK-style build system. Also removes: - build/update_solutions.bat (sole caller of the tool) - Stride.ProjectGenerator entry from build/Stride.slnx - /sources/tools/Stride.ProjectGenerator/build/ from .gitignore - Stale generator reference from Stride.Graphics.Tests/README.md
Kryptos-FR
force-pushed
the
feature/stride-sdk
branch
from
f0ddfb6 to
3c44c74
Compare
This file contains hidden or bidirectional Unicode text that may be interpreted or compiled differently than what appears below. To review, open the file in an editor that reveals hidden Unicode characters.
Learn more about bidirectional Unicode characters
Sign up for free
to join this conversation on GitHub.
Already have an account?
Sign in to comment
4 participants
Add this suggestion to a batch that can be applied as a single commit.This suggestion is invalid because no changes were made to the code.Suggestions cannot be applied while the pull request is closed.Suggestions cannot be applied while viewing a subset of changes.Only one suggestion per line can be applied in a batch.Add this suggestion to a batch that can be applied as a single commit.Applying suggestions on deleted lines is not supported.You must change the existing code in this line in order to create a valid suggestion.Outdated suggestions cannot be applied.This suggestion has been applied or marked resolved.Suggestions cannot be applied from pending reviews.Suggestions cannot be applied on multi-line comments.Suggestions cannot be applied while the pull request is queued to merge.Suggestion cannot be applied right now. Please check back later.
PR Details
Replaces the legacy build system (
sources/targets/+ scattered.props/.targetsfiles) with three MSBuild SDK packages undersources/sdk/. All 112 projects now use<Project Sdk="Stride.Sdk">(orStride.Sdk.Editor/Stride.Sdk.Tests).Motivation
The old build system was a web of 20+
.propsand.targetsfiles imported via relative paths in every.csproj. This made project files verbose, fragile to move, and hard to reason about. The new SDK approach follows .NET conventions: build logic lives in versioned SDK packages, and project files only declare what makes them unique.What changed
New SDK packages (
sources/sdk/):Stride.SdkStride.Sdk.EditorStride.Sdk+ editor framework propertiesStride.Sdk.TestsStride.Sdk.Editor+ xunit infrastructure, test launchers, asset compilationSimplified project files — 184
.csprojfiles modified with a net reduction of ~2,100 lines. A typical project went from 30+ lines of imports and boilerplate to a clean SDK-style file.Deleted legacy files:
sources/targets/(20 files, ~1,500 lines) — the old build systembuild/*.propsandbuild/*.targetsfilesSolution filters —
.slnffiles replace separate.slnfiles for Android/iOS builds.CI updated — all workflows now build the SDK packages first via a shared
build-sdkaction.How to review
sources/sdk/Stride.Sdk/Sdk/Sdk.propsandSdk.targetsto understand what the SDK provides.csprojdiffs to see the simplification (e.g.,Stride.Core.csproj,Stride.Engine.csproj)build/docs/SDK-GUIDE.mdexplains the SDK hierarchy, property evaluation order, and development workflowRelated Issue
Build system modernization — no prior issue.
Types of changes
Checklist