Add Stride.Core.CompilerServices to the solution filters (.slnf)

[Ethereal77]

PR Details

Stride.Core packs the analyzers DLL (Stride.Core.CompilerServices) directly from the bin folder. From the .csproj:

<None Include="...\Stride.Core.CompilerServices\bin\$(Configuration)\netstandard2.0\Stride.Core.CompilerServices.dll"
      Pack="true" PackagePath="analyzers/dotnet/cs" />

That means Stride.Core.CompilerServices.dll must already exist on disk when Stride.Core is packed.

Building the full solution Stride.sln succeeds because it has Stride.Core.CompilerServices in its build graph, and when the SDK targets reference that project it automatically builds it first. However, Stride.Runtime.slnf omitted it, and then Stride.Core later failed when it tried to pack the analyzer DLL from disk.

This PR adds the Stride.Core.CompilerServices project to the Stride.Runtime.snlf to fix this. It also adds it to the Stride.Android.slnf and Stride.iOS.slnf for the same reasons.

Related Issue

No issue. Commented on Discord.

Types of changes

• Docs change / refactoring / dependency upgrade
• Bug fix (non-breaking change which fixes an issue)
• New feature (non-breaking change which adds functionality)
• Breaking change (fix or feature that would cause existing functionality to change)

Checklist

• My change requires a change to the documentation.
• I have added tests to cover my changes.
• All new and existing tests passed.
• I have built and run the editor to try this change out.

[Kryptos-FR]

Did you use dotnet or msbuild to build the solution? I think the behavior can be different.

[Ethereal77]

For the Stride solution itself (and the .slnf files) I always use MSBuild because of the VC++ targets. At least before, using dotnet failed for me the moment it tried to compile one of the .vcxproj files.

[Kryptos-FR]

Since a little while ago, you can use llvm+clang instead of MSVC which makes it work with dotnet build. Just add -p:StrideNativeBuildMode=Clang to the dotnet command line (see #3045).

The reason I asked is because it seems that dotnet build is able to get the transitive dependencies that might be msising from the .slnf file, while msbuild needs the full set from the get-go. So that could explain why we didn't see that issue before.

In any case, adding to the .slnf is a reasonable fix.

[Kryptos-FR]

Order in the .slnf has no influence on build order I believe (it's based on the same resolution order than the corresponding .sln), so I think it's better to just keep them sorted.

[Ethereal77]

Oh, yes. Until I saw Stride.Core.CompilerServices was being included by the SDK targets, I thought order was somehow affecting the build. I'll revert the reordering of Stride.Core.

[Kryptos-FR]

Same

[Kryptos-FR]

Same

[Ethereal77]

Here it was already below the other Core projects. I only placed the new one above Stride.Core. I'll place it below instead (although it won't matter)

[Ethereal77]

Since a little while ago, you can use llvm+clang instead of MSVC which makes it work with dotnet build. Just add -p:StrideNativeBuildMode=Clang to the dotnet command line (see #3045).

Oh, I remember having read about that, but haven't tested. Will do tomorrow.