Solution filter (`*.slnf`) support
Nobody has claimed this yet.
- Dominant language
- C#
- Stars
- 7.8k
- Forks
- 1.2k
- Avg merge
- 2d 17h
- Merged PRs (30d)
- 49
Description
Is your feature request related to a problem? Please describe.
When opening a large solution in Stride Game Studio, all projects are loaded, including unit test projects and other non-Stride executables. This results in unnecessary load times and increased memory usage. Additionally, non-game projects (e.g., unit test projects) are often incorrectly set as startup projects, which leads to incorrect visual indicators in the asset view.
In larger solutions (in my case with about 50 projects), manually selecting the correct startup project each time is disruptive and inefficient.
Describe the solution you'd like
Stride Game Studio should support Solution Filter Files (*.slnf), enabling users to open only the necessary projects as a subset of the complete solution. This would improve load performance and prevent unwanted projects (e.g., unit test projects) from being included in the game editor.
The solution filter files are created in Visual Studio and can be opened with it. When opening a slnf-file, it is easy to update the included projects. The filter file has a reference to a solution file (sln) to achieve this.
Expected behavior:
- Stride Game Studio should support opening
.slnffiles just like.slnfiles. - Only the projects specified in the
.slnffile should be loaded, reducing memory usage and load time.
Describe alternatives you've considered
- Manually setting the startup project: This is possible but tedious, especially when frequently switching between game studio and Visual Studio or often restarts of the game studio to refresh scripts.
- Using separate solution files (
.sln): A workaround is to create a secondary.slnfile containing only the relevant projects. However, maintaining multiple solution files is cumbersome, as any new project additions must be manually synchronized.
Additional context
Use Cases
- Developers working on large solutions containing both game-related and non-game-related projects.
- Teams using unit tests that should not be loaded in Stride Game Studio.
- Optimizing memory usage and load performance by excluding unnecessary projects.
- Selecting the correct startup project when opening the game studio. Therefore, it is necessary only have one executable project loaded.
Editor Behavior
- The editor should allow
.slnffiles to be opened just like.slnfiles. - When opening a
.slnffile, only the projects listed in it should be loaded.
Components Involved
- Project loading mechanism in Stride Game Studio. Especially the
Stride.Core.Assetsproject. - Launcher must list the last opened
slnandslnf-files.
Contributor guide
First steps
- Read the whole issue, then the project's contributing guide.
- Comment on the issue to say you are picking it up — it saves two people doing the same work.
- Fork the repository and make your change on a branch.
- Open a pull request that references the issue number.
Research direction
Start by tracing the project loading mechanism in Stride.Core.Assets and how the launcher handles recently opened solution files. Compare the existing .sln flow with the .slnf requirements in the issue. Done means the editor opens .slnf files, loads only their listed projects, and the launcher retains both .sln and .slnf entries.
Written by the indexing model from the issue text.
Assessment
- Tech stack
- csharp
- Domain
- game-dev, tooling
- Issue type
- Feature
- Difficulty
- 4/5
- Estimated time
- 3-5 days
- Activity status
- Stale
- Clarity
- Mostly clear
- Newbie friendliness
- 38/100