Earthmark
commented
2 years ago I'm still investigating this, but I saw this come up in the discord as well so I figure a github issue is good then.
Closed Earthmark closed 2 years ago
Earthmark
commented
2 years ago I'm still investigating this, but I saw this come up in the discord as well so I figure a github issue is good then.
Eideren
commented
2 years ago Could you try PR #1276 , I'm pretty sure that's the same issue.
Earthmark
commented
2 years ago That branch does build successfully, some tests are failing as well, but it seems much more tests are able to run than before. The PR seems to be holding.
Was there something holding up the merging of that branch that I can help with? It seems like that is a bit of a more stable basis to work from at least in terms of testability.
Eideren
commented
2 years ago I would like to wait for @xen2 to take a look at it since the build system is really more his thing, but I guess if he hasn't had the time to take a look at it by sunday I'll go ahead and merge it and revert later if needed.
Release Type: GitHub
Version: development head
Platform(s): Windows during editor build
Describe the bug When doing a clean build, some sub component of the asset compiler fails to find nuget and fails the build.
To Reproduce Wipe the whole local repo, and restore from scratch (
git cleanorgit reset --hardwill not cut it, delete all files and then reset).Expected behavior The build succeeds without errors on first clone.
Screenshots N/A
Additional context I'm currently looking into this, but I figure it's good to make an issue for traceability.
This seems to not reliably occur, and building random projects seems to somehow resolve the issue.
I do have MSBuild in my path per the vs-free build instructions, the command to do a clean compile was
msbuild Stride.slnthough,dotnetdidn't like trying to compile C++.In this case I do not have nuget in my path at the moment, however from before this error occurred with or without
MSBUILD_NUGET_PATHbeing defined.I believe the loader error caused VS crashes for me with a similar looking error when VS tries to inspect the tests with the test explorer.
Log, callstacks, and a lot of fluff The build itself has the same error repetitively, but the true error ends up being caused by a command of the form:
Newlines were added for readability.
--debugwas added for the below logs to be sure everything was there.$repoRootis really my repo location in the drive, I'm replacing it whever my drive path shows up. Different variants of this command are called and fail for the same reason, all examples here were gathered from this specific command sequence.The tool is accessable as a target via
$repoRoot\sources\assets\Stride.Core.Assets.CompilerApp\build\Stride.Core.Assets.CompilerApp.targetsWell that's a mouthful.
hypotheses It looks like it found the nuget version dll and everything, but failed just short of actually loading it. Previously I started on dotnet 5 and the assembly version was listed as a 5. version. Now that I have 6 it's listing a 6. version, it seems to be finding an appropriate dll but fails to bind.
The call originates from https://github.com/NuGet/NuGet.Client/blob/dev/src/NuGet.Core/Microsoft.Build.NuGetSdkResolver/NuGetSdkResolver.cs It looks like the runtime is attempting to load the NuGet.Versioning assembly for the jit compiler, fails to bind, and throws an exception.
One difference I did notice between the instructions and my local setup is that my VS and msbuild are x64, not x86, this might be architecture related.