Stride.GameStudio Startup - Error Restoring NuGet packages!

[DomeAlessi]

Release Type: Official Release/GitHub (please choose appropriate option)
GitHub

Version: Version number and/or git branch
v4.2.0.2188

Platform(s): Does the problem occur on Windows, Android...?
Windows 11

Describe the bug
After successfully building Stride.GameStudio in various configs (Debug/ Release - MixedPlatforms/ AnyCPU) I get an error when starting the application. The error says "Error Restoring NuGet packages!". Any hint on how I can fix this?

To Reproduce
Steps to reproduce the behavior:

1. Set Stride.GameStudio as Startup Application
2. Build
3. Run

Screenshots

Log and callstacks
[Verbose] Running restore with 16 concurrent jobs.
[Verbose] Reading project file StrideNugetResolver.json.
[Verbose] The restore inputs for 'StrideNugetResolver' have changed. Continuing restore.
[Error] Platform version is not present for one or more target frameworks, even though they have specified a platform: net8.0-windows
[Information] CACHE https://api.nuget.org/v3/vulnerabilities/index.json
[Information] CACHE https://api.nuget.org/v3-vulnerabilities/2024.08.29.05.32.17/vulnerability.base.json
[Information] CACHE https://api.nuget.org/v3-vulnerabilities/2024.08.29.05.32.17/2024.09.03.17.32.37/vulnerability.update.json
[Verbose] All packages and projects are compatible with net8.0-windows.
[Verbose] All packages and projects are compatible with net8.0-windows (win-x64).
[Information] Writing assets file to disk. Path: C:\Users\MyUser\AppData\Local\Temp\StrideNugetResolver-Stride.GameStudio-4.2.0.1-net8.0-windows-win-x64\project.assets.json
[Verbose] Writing cache file to disk. Path: C:\Users\MyUser\AppData\Local\Temp\StrideNugetResolver-Stride.GameStudio-4.2.0.1-net8.0-windows-win-x64\project.nuget.cache
[Verbose] Persisting dg to C:\Users\MyUser\AppData\Local\Temp\StrideNugetResolver-Stride.GameStudio-4.2.0.1-net8.0-windows-win-x64\StrideNugetResolver.json.nuget.dgspec.json
[Error] Error restoring NuGet packages: System.InvalidOperationException: Could not restore NuGet packages
at Stride.Core.Assets.NuGetAssemblyResolver.<>c__DisplayClass5_0.b__0(Object sender, ResolveEventArgs eventArgs) in W:\source\repos\stride\stride\sources\shared\Stride.NuGetResolver\NuGetAssemblyResolver.cs:line 126

[KingIAmStreaming]

I'm experiencing the same issue when running the source code for the first time, resulting in the same outcome.

[Basewq]

Most likely either you don't have the SDK for .NET 8 installed or the config of the SDK is somehow bad.

Even though this isn't MAUI, this link suggests the x86 might be taking priority causing the issue:

Visual Studio may not be resolving the required workloads if you try to compile a project and receive an error similar to the following text:

Platform version is not present for one or more target frameworks, even though they have specified a platform: net8.0-android, net8.0-ios, net8.0-maccatalyst

This problem typically results from having an x86 and x64 SDK installed, and the x86 version is being used. Visual Studio and .NET MAUI require the x64 .NET SDK. If your operating system has a system-wide PATH variable that is resolving the x86 SDK first, you need to fix that by either removing the x86 .NET SDK from the PATH variable, or promoting the x64 .NET SDK so that it resolves first. For more information on troubleshooting x86 vs x64 SDK resolution, see Install .NET on Windows - Troubleshooting.

This link has a solution to change the PATH priority:
https://learn.microsoft.com/en-us/dotnet/core/install/windows#no-net-sdk-was-found

[VaclavElias]

I also mentioned it here. Not sure if some recent commits didn't cause the issue? @Basewq, can you confirm that you can run the Game Studio from the code and have no errors?

https://discord.com/channels/500285081265635328/727168636770582581/1279863992227070123

[Basewq]

I also mentioned it here. Not sure if some recent commits didn't cause the issue? @Basewq, can you confirm that you can run the Game Studio from the code and have no errors?

https://discord.com/channels/500285081265635328/727168636770582581/1279863992227070123

Oh I see, I've not been on the latest commit, I've been on 8dd9a99 which has been working. I will try a newer commit and see if it bugs out.

[Basewq]

Ok, tested on the latest commit, yes it's broken.
Eideren points out in the discord #2205 is probably the culprit.
As far as I can confirm, nuget is extracting the .nupkg package and looking for files in lib\net8.0-windows folder, but this doesn't exist.
It seems the build's packaging is still placing it in lib\net8.0-windows7.0 subfolder. Not sure how Stride does the 'pack' thing.

[VaclavElias]

Thanks for coming back so quickly on this 😀. Yes, there were some clean up updates and it seems the things are a bit tangled here and there so it needs to be reviewed again.

[Jklawreszuk]

Have you tried removing packages from the .nuget folder?
There is also a folder dedicated to local Nuget packages in the %LocalAppData%StrideNugetDev folder - delete that folder too.
If that wouldn't work I'll create a PR that reverses the change of TF 😀

[Basewq]

Have you tried removing packages from the .nuget folder? There is also a folder dedicated to local Nuget packages in the %LocalAppData%StrideNugetDev folder - delete that folder too. If that wouldn't work I'll create a PR that reverses the change of TF 😀

Yes, but the problem seems to be in how it's 'packing' the .nupkg file (though I could be wrong). Are you able to rebuild the Stride.GameStudio and find your Stride.GameStudio.4.2.0.XXXX.nupkg, manually extract it and confirm if you get a lib\net8.0-windows or lib\net8.0-windows7.0 folder?

EDIT: Also, yes this change also means needing to delete from C:\Users\USERNAME\.nuget\packages\stride.*\4.2.0.XXXX\ since nuget doesn't re-extract the files.

[VaclavElias]

Maybe, a related hint..

I am probably the first one who started having this or similar issue in the community toolkit a few months ago when I run dotnet build.

Later I discovered that only on the first build, probably on the PC, I have to run dotnet build --runtime win-x64 which resolved the NuGet packages differently.

After that, all is working ok, including additional new projects. I don't have to run anymore dotnet build --runtime win-x64 but just simple dotnet build.

The issue is that dotnet build should have resolved the packages correctly already by some defualts, which seems got messed up.

I have to test if I need to build Game Studio similar way I described above.

[IXLLEGACYIXL]

you had godot before? godot makes a fallback folder and changes nuget configs which can result in errors

[Basewq]

Have you tried removing packages from the .nuget folder? There is also a folder dedicated to local Nuget packages in the %LocalAppData%StrideNugetDev folder - delete that folder too. If that wouldn't work I'll create a PR that reverses the change of TF 😀

Yes, but the problem seems to be in how it's 'packing' the .nupkg file (though I could be wrong). Are you able to rebuild the Stride.GameStudio and find your Stride.GameStudio.4.2.0.XXXX.nupkg, manually extract it and confirm if you get a lib\net8.0-windows or lib\net8.0-windows7.0 folder?

EDIT: Also, yes this change also means needing to delete from C:\Users\USERNAME\.nuget\packages\stride.*\4.2.0.XXXX\ since nuget doesn't re-extract the files.

Ok, so as far as I can tell from the following link, nuget packages are supposed to output to -windows-7.0 folder, not -windows in nuget packages
https://learn.microsoft.com/en-us/dotnet/standard/frameworks#os-version-in-tfms

When an OS-specific TFM doesn't specify the platform version explicitly, it has an implied value that can be inferred from the base TFM and platform name. For example, the default platform value for iOS in .NET 6 is 15.0, which means that net6.0-ios is shorthand for the canonical net6.0-ios15.0 TFM. The implied platform version for a newer base TFM may be higher, for example, a future net8.0-ios TFM could map to net8.0-ios16.0. The shorthand form is intended for use in project files only, and is expanded to the canonical form by the .NET SDK's MSBuild targets before being passed to other tools, such as NuGet.

So this particular line fails:

stride/sources/shared/Stride.NuGetResolver/NuGetAssemblyResolver.cs

Line 119 in ba36a7e

var nugetFramework = NuGetFramework.Parse(targetFramework);

because "net8.0-windows" is being passed as targetFramework, but it needs to be "net8.0-windows7.0" (the 'canonical TFM')

This is called by some auto-generated file, eg.

class NuGetResolverModuleInitializer
{
    [ModuleInitializer(-100000)]
    internal static void __Initialize__()
    {
        // Only perform this for entry assembly
        if (!(Assembly.GetEntryAssembly() == null // .NET FW: null during module .ctor
            || Assembly.GetEntryAssembly() == Assembly.GetCallingAssembly())) // .NET Core: check against calling assembly (note: if using Stride.NuGetLoader, it will be skipped as well which is what we want)
            return;

        NuGetAssemblyResolver.SetupNuGet("net8.0-windows", "Stride.GameStudio", "4.2.0.9999-dev");
    }
}

But no idea how this is generated!

EDIT: File is generated via:

stride/sources/shared/Stride.NuGetResolver.Targets/Stride.NuGetResolver.Targets.projitems

Line 27 in ba36a7e

<WriteLinesToFile File="$(NuGetResolverModuleInitializerFile)" Overwrite="true" Lines="$([System.IO.File]::ReadAllText('$(MSBuildThisFileDirectory)NuGetResolverModuleInitializer.cs')&#xD;&#xA; .Replace('STRIDE_NUGET_RESOLVER_TARGET_FRAMEWORK','&quot;$(TargetFramework)&quot;')&#xD;&#xA; .Replace('STRIDE_NUGET_RESOLVER_PACKAGE_NAME','&quot;$(PackageId)&quot;')&#xD;&#xA; .Replace('STRIDE_NUGET_RESOLVER_PACKAGE_VERSION','&quot;$(PackageVersion)&quot;'))" />

So the problem is $(TargetFramework) as-is is being used in place of STRIDE_NUGET_RESOLVER_TARGET_FRAMEWORK, whereas the canonical TFM is required, to get to the correct lib subfolder.

So the solution appears to either revert to explicitly declare platform version of the TFM, or fix it to determine the TFM + platform version instead of $(TargetFramework) (no idea how to do this)
Not a full list (I just did a 'Find All References'), but it looks like the following projects need the full TFM:

NuGetAssemblyResolver.SetupNuGet("net8.0-windows", "Stride.Samples.Tests", "4.2.0.9999-dev");
NuGetAssemblyResolver.SetupNuGet("net8.0-windows", "Stride.Core.Assets.CompilerApp", "4.2.0.9999-dev");
NuGetAssemblyResolver.SetupNuGet("net8.0-windows", "Stride.GameStudio", "4.2.0.9999-dev");
NuGetAssemblyResolver.SetupNuGet("net8.0-windows", "Stride.ConnectionRouter", "4.2.0.9999-dev");
NuGetAssemblyResolver.SetupNuGet("net8.0-windows", "Stride.EffectCompilerServer", "4.2.0.9999-dev");
NuGetAssemblyResolver.SetupNuGet("net8.0-windows", "Stride.SamplesTestServer", "4.2.0.9999-dev");
NuGetAssemblyResolver.SetupNuGet("net8.0-windows", "Stride.TestRunner", "4.2.0.9999-dev");
NuGetAssemblyResolver.SetupNuGet("net8.0-windows", "Stride.VisualStudio.Commands", "4.2.0.9999-dev");

[DomeAlessi]

Thank you very much for investigating this one, in effect my PATH config and SDK seems to be correct and I also tried to cleanup my system nuget packages and the ones created by stride while waiting.
@Basewq in your last message the list of assemblies has version 4.2.0.9999 is that last number correct?

[KingIAmStreaming]

var (request, result) = RestoreHelper.Restore(logger, nugetFramework, RuntimeInformation.RuntimeIdentifier, packageName, versionRange);

if (!result.Success)
{
     throw new InvalidOperationException($"Could not restore NuGet packages");
}

This is the exact line of code preventing the Application to run.
90-Tools/NuGetResolver/Stride.NuGetResolver.UI/NuGetAssemblyResolver.cs on line 126

I also noted that this is a referenced file from Stride.NuGetResolver and wondered why its duplicated like this? one has UI capability, would it not be better split instead of double referencing?
Sorry it just confuses me.

I am very new to this...

It is throwing an error even though the versions are matched in the AppData/Local/Stride/NuGetDev with the values checked from the solution file build/Stride.GameStudio.sln
The Version Range is also matched in the debugger so perhaps we shouldn't even get here? because result.success will always be false in this scenario? and I can not see a reason why it needs to run.

I must be missing something....

My Source is the latest commit? 4.2.0.1

All my initializers reference the same version as everywhere else in the code base
NuGetAssemblyResolver.SetupNuGet("net8.0-windows", "Stride.Samples.Tests", "4.2.0.1");

[DomeAlessi]

Not sure if that's related or useful in any case but i noticed that when modifying the values in the MSBuild script this project here is the only one that has net8.0 without (-windows)

[Basewq]

@Basewq in your last message the list of assemblies has version 4.2.0.9999 is that last number correct?

You can ignore that my version says 9999, I modified that on my local version which doesn't affect this issue.

For the time being, either work off from commit c7519cd (ie. before the changes with #2205), or revert commit c424213 on your local machine.

[DomeAlessi]

Worked by taking the changes before #2205, thanks!

[VaclavElias]

I can confirm that I can launch the Game Studio with the most recent commit. Thank you @Basewq.

Also, thanks @DomeAlessi for reporting it for us!

[KingIAmStreaming]

Fantastic, working for me too :)