Repository navigation
Description
Usage Information
Fallout: 10.4.0, SDK: 10.0.401, Target: .NET 10, OS: Win11 26H2
Description
Hey again, I ran into a small problem with one of my repos the other day when trying to create a new workflow target.
The workflow failed to restore the builder.
This is the current BuildSystem.csproj
<Project Sdk="Microsoft.NET.Sdk">
<PropertyGroup>
<OutputType>Exe</OutputType>
<TargetFramework>net10.0</TargetFramework>
<RootNamespace/>
<NoWarn>CS0649;CS0169;CA1050;CA1822;CA2211;IDE1006</NoWarn>
<FalloutRootDirectory>..</FalloutRootDirectory>
<FalloutScriptDirectory>..</FalloutScriptDirectory>
<IsPackable>false</IsPackable>
<ManagePackageVersionsCentrally>false</ManagePackageVersionsCentrally>
<UseArtifactsOutput>false</UseArtifactsOutput>
</PropertyGroup>
<ItemGroup>
<PackageReference Include="Fallout.Common" Version="10.4.0" />
<PackageReference Include="Fallout.Components" Version="10.4.0" />
<PackageReference Include="NuGet.CommandLine" Version="7.9.0">
<PrivateAssets>all</PrivateAssets>
<IncludeAssets>runtime; build; native; contentfiles; analyzers; buildtransitive</IncludeAssets>
</PackageReference>
</ItemGroup>
</Project>
At the time, I had only Fallout.Common@11.0.1 as the only Fallout package installed.
Was the 11.0.1 version pulled from Nuget per-chance? I reduced my version to 10.4.0 but that didn't seem to solve the restore error.
Locally everything restores just fine. I did also try a Nuget package cache purge on my local machine in-case 11.0.1 is still present there
(dotnet nuget locals all -c)
This lead me to test if restore works on a fresh directory with nothing inside. Since I did the version purge, my only version recommendation for Fallout.Common was "10.4.0.15" (Same as tool version).
Since 10.4.0.15 doesn't exist, it tries to use the closest available version
warning NU1603: _build depends on Fallout.Common (>= 10.4.0.15) but Fallout.Common 10.4.0.15 was not found. Fallout.Common 11.0.1 was resolved instead.
My thoughts are that my Restore never failed before due to the packages being cached on GitHub for the runner.
I have absolutely no idea why the Actions runner would fail on the restore.
Reproduction Steps
scoop install dotnet-sdk@10.0.401
dotnet tool install Fallout.GlobalTool --global
mkdir temp_test
cd temp_test
fallout :setup
fallout
cd ..
rm temp_test -RecurseExpected Behavior
Restore works in the cloud, and the versions don't resolve incorrectly
Actual Behavior
Restore fails in GitHub's CI env and a fresh tool install and example project fails to build.
Regression?
I don't know if this could be considered a regression, since it's trying to resolve a non-existent future version. But this is technically just semantics at this point.
Known Workarounds
No response
Could you help with a pull-request?
No
Activity