Further attempts at building with .NET 8 #2852

Numpsy · 2025-01-09T11:36:06Z

Description

As #2818, but updated on top of the latest changes and with a couple of extra commits to try to get more tests passing - see further comments for details

Numpsy · 2025-01-09T11:38:29Z

src/test/Fake.Core.IntegrationTests/SimpleHelloWorldTests.fs

              let scenarioPath = resolvePath scenario ""
              // dotnet tool install --version 5.19.0-alpha.local.1 fake-cli --add-source /e/Projects/FAKE/release/dotnetcore/
+
+              // Work around https://github.com/dotnet/sdk/issues/40655 by specifying the tool manifest explicitly


Some of tests in previous runs seemed to be failing with dotnet/sdk#40655, whereby installing the dotnet tool in a subdirectory that contains a tools config file will ignore that file and use the one in the repo root, but then trying to use that tool will use the local config file and then fail.
That issue is marked as resolved, but it still seemed to be occuring in the SDK version used by the tests

Numpsy · 2025-01-09T11:44:05Z

build.fsx

        |> Async.RunSynchronously
        |> List.ofSeq
-        |> List.find (fun product -> product.ProductVersion.Equals("6.0"))
+        |> List.find (fun product -> product.ProductVersion.Equals("8.0"))


I'm not sure what the logic for this (or cachedDotnetSdkReleases.json) should be when updating .NET versions.
The current cachedDotnetSdkReleases.json only contains the .NET 6 releases and that seemed to cause test failures when built as .NET 8 and looking for the v8 SDK versions.
Changing this to 8.0 fixed that, but that might then not be right if fake-cli is multi-targetted at .NET 6 and .NET 8 as the .NET 6 version might still need the list of v6 releases?

github-actions · 2025-01-09T11:54:23Z

Test Results

12 files ±0 12 suites ±0 31m 3s ⏱️ - 2m 12s
451 tests ±0 450 ✅ ±0 1 💤 ±0 0 ❌ ±0
1 287 runs ±0 1 284 ✅ ±0 3 💤 ±0 0 ❌ ±0

Results for commit afe43a2. ± Comparison against base commit d95a3ad.

This pull request removes 3 and adds 3 tests. Note that renamed tests count towards both.

[Fake.DotNet.sdkAssemblyResolverTests; Runner run script with 6.0.300 SDK version assemblies and resolve runtime version from cached file]
[Fake.DotNet.sdkAssemblyResolverTests; Runner run script with 6.0.300 SDK version assemblies]
[Fake.DotNet.sdkAssemblyResolverTests; Runner run script with 6.0.301 SDK version assemblies]

[Fake.DotNet.sdkAssemblyResolverTests; Runner run script with 8.0.400 SDK version assemblies and resolve runtime version from cached file]
[Fake.DotNet.sdkAssemblyResolverTests; Runner run script with 8.0.400 SDK version assemblies]
[Fake.DotNet.sdkAssemblyResolverTests; Runner run script with 8.0.401 SDK version assemblies]

♻️ This comment has been updated with latest results.

Numpsy · 2025-01-09T11:58:25Z

The remaining failures are in the TemplateIntegrationTests, with errors like

25h[11:48:10 ERR] Fake.DotNet.Cli.IntegrationTests.TemplateTests.can install and run the template.fails to build a target that doesn't exist failed in 00:00:09.6230000. 
Expected the message 'Target Nonexistent is not defined' but got: No exact match of product releases 8.0.401 found.
No product release found for 8.0.401. Maybe a pre-release? Returning all the versions.
No exact match of product releases 8.0.404 found.
No product release found for 8.0.404. Maybe a pre-release? Returning all the versions.
There was a problem while setting up the environment:
-> Could not find referenced assemblies in path: '[C:\Users\runneradmin\AppData\Local\Microsoft\dotnet\packs\Microsoft.NETCore.App.Ref\6.0.36\ref\net6.0],[C:\Users\runneradmin\AppData\Local\Microsoft\dotnet\packs\Microsoft.NETCore.App.Ref\6.0.35\ref\net6.0],[C:\Users\runneradmin\AppData\Local\Microsoft\dotnet\packs\Microsoft.NETCore.App.Ref\6.0.33\ref\net6.0],[C:\Users\runneradmin\AppData\Local\Microsoft\dotnet\packs\Microsoft.NETCore.App.Ref\6.0.32\ref\net6.0],[C:\Users\runneradmin\AppData\Local\Microsoft\dotnet\packs\Microsoft.NETCore.App.Ref\6.0.31\ref\net6.0],[C:\Users\runneradmin\AppData\Local\Microsoft\dotnet\packs\Microsoft.NETCore.App.Ref\6.0.30\ref\net6.0],[C:\Users\runneradmin\AppData\Local\Microsoft\dotnet\packs\Microsoft.NETCore.App.Ref\6.0.29\ref\net6.0],[C:\Users\runneradmin\AppData\Local\Microsoft\dotnet\packs\Microsoft.NETCore.App.Ref\6.0.28\ref\net6.0],[C:\Users\runneradmin\AppData\Local\Microsoft\dotnet\packs\Microsoft.NETCore.App.Ref\6.0.27\ref\net6.0],[C:\Users\runneradmin\AppData\Local\Microsoft\dotnet\packs\Microsoft.NETCore.App.Ref\6.0.26\ref\net6.0],[C:\Users\runneradmin\AppData\Local\Microsoft\dotnet\packs\Microsoft.NETCore.App.Ref\6.0.25\ref\net6.0],[C:\Users\runneradmin\AppData\Local\Microsoft\dotnet\packs\Microsoft.NETCore.App.Ref\6.0.24\ref\net6.0],[C:\Users\runneradmin\AppData\Local\Microsoft\dotnet\packs\Microsoft.NETCore.App.Ref\6.0.23\ref\net6.0],[C:\Users\runneradmin\AppData\Local\Microsoft\dotnet\packs\Microsoft.NETCore.App.Ref\6.0.22\ref\net6.0],[C:\Users\runneradmin\AppData\Local\Microsoft\dotnet\packs\Microsoft.NETCore.App.Ref\6.0.21\ref\net6.0],[C:\Users\runneradmin\AppData\Local\Microsoft\dotnet\packs\Microsoft.NETCore.App.Ref\6.0.20\ref\net6.0],[C:\Users\runneradmin\AppData\Local\Microsoft\dotnet\packs\Microsoft.NETCore.App.Ref\6.0.19\ref\net6.0],[C:\Users\runneradmin\AppData\Local\Microsoft\dotnet\packs\Microsoft.NETCore.App.Ref\6.0.18\ref\net6.0],[C:\Users\runneradmin\AppData\Local\Microsoft\dotnet\packs\Microsoft.NETCore.App.Ref\6.0.16\ref\net6.0],[C:\Users\runneradmin\AppData\Local\Microsoft\dotnet\packs\Microsoft.NETCore.App.Ref\6.0.15\ref\net6.0],[C:\Users\runneradmin\AppData\Local\Microsoft\dotnet\packs\Microsoft.NETCore.App.Ref\6.0.14\ref\net6.0],[C:\Users\runneradmin\AppData\Local\Microsoft\dotnet\packs\Microsoft.NETCore.App.Ref\6.0.13\ref\net6.0],[C:\Users\runneradmin\AppData\Local\Microsoft\dotnet\packs\Microsoft.NETCore.App.Ref\6.0.12\ref\net6.0],[C:\Users\runneradmin\AppData\Local\Microsoft\dotnet\packs\Microsoft.NETCore.App.Ref\6.0.11\ref\net6.0],[C:\Users\runneradmin\AppData\Local\Microsoft\dotnet\packs\Microsoft.NETCore.App.Ref\6.0.10\ref\net6.0],[C:\Users\runneradmin\AppData\Local\Microsoft\dotnet\packs\Microsoft.NETCore.App.Ref\6.0.9\ref\net6.0],[C:\Users\runneradmin\AppData\Local\Microsoft\dotnet\packs\Microsoft.NETCore.App.Ref\6.0.8\ref\net6.0],[C:\Users\runneradmin\AppData\Local\Microsoft\dotnet\packs\Microsoft.NETCore.App.Ref\6.0.7\ref\net6.0],[C:\Users\runneradmin\AppData\Local\Microsoft\dotnet\packs\Microsoft.NETCore.App.Ref\6.0.6\ref\net6.0],[C:\Users\runneradmin\AppData\Local\Microsoft\dotnet\packs\Microsoft.NETCore.App.Ref\6.0.5\ref\net6.0],[C:\Users\runneradmin\AppData\Local\Microsoft\dotnet\packs\Microsoft.NETCore.App.Ref\6.0.4\ref\net6.0],[C:\Users\runneradmin\AppData\Local\Microsoft\dotnet\packs\Microsoft.NETCore.App.Ref\6.0.3\ref\net6.0],[C:\Users\runneradmin\AppData\Local\Microsoft\dotnet\packs\Microsoft.NETCore.App.Ref\6.0.2\ref\net6.0],[C:\Users\runneradmin\AppData\Local\Microsoft\dotnet\packs\Microsoft.NETCore.App.Ref\6.0.1\ref\net6.0],[C:\Users\runneradmin\AppData\Local\Microsoft\dotnet\packs\Microsoft.NETCore.App.Ref\6.0.0\ref\net6.0],[C:\Users\runneradmin\AppData\Local\Microsoft\dotnet\packs\Microsoft.NETCore.App.Ref\6.0.0-rc.2.21480.5\ref\net6.0],[C:\Users\runneradmin\AppData\Local\Microsoft\dotnet\packs\Microsoft.NETCore.App.Ref\6.0.0-rc.1.21451.13\ref\net6.0],[C:\Users\runneradmin\AppData\Local\Microsoft\dotnet\packs\Microsoft.NETCore.App.Ref\6.0.0-preview.7.21377.19\ref\net6.0],[C:\Users\runneradmin\AppData\Local\Microsoft\dotnet\packs\Microsoft.NETCore.App.Ref\6.0.0-preview.6.21352.12\ref\net6.0],[C:\Users\runneradmin\AppData\Local\Microsoft\dotnet\packs\Microsoft.NETCore.App.Ref\6.0.0-preview.5.21301.5\ref\net6.0],[C:\Users\runneradmin\AppData\Local\Microsoft\dotnet\packs\Microsoft.NETCore.App.Ref\6.0.0-preview.4.21253.7\ref\net6.0],[C:\Users\runneradmin\AppData\Local\Microsoft\dotnet\packs\Microsoft.NETCore.App.Ref\6.0.0-preview.3.21201.4\ref\net6.0],[C:\Users\runneradmin\AppData\Local\Microsoft\dotnet\packs\Microsoft.NETCore.App.Ref\6.0.0-preview.2.21154.6\ref\net6.0],[C:\Users\runneradmin\AppData\Local\Microsoft\dotnet\packs\Microsoft.NETCore.App.Ref\6.0.0-preview.1.21102.12\ref\net6.0]', please check installed SDK and runtime versions

and I'm not sure if this is really a problem with the new stuff, or if it's because it's trying to use the 6.1.3 release to test the templates, and failing when running as .NET 8? (I suppose it shou;dn't be looking at the 6.0 assemblies when running as 8.0)

Thorium · 2025-07-17T09:50:53Z

I expect that there is a chicken-and-egg problem, and the integration tests are actually restoring the .NET6 fake to try compiling .NET8, instead of referring to the just built .NET 8 version.

I tried this branch locally (Numpsy/new8-build-bump-roll-tests-2) on my machine, and my observations are here:

src\app\fake-cli\bin\Release\ has now net6.0 and net8.0 paths. Can a dotnet tool even have multiple target frameworks? Or should we just accept that FAKE 6.1.3 is working well for .NET6 projects and from now on everything else is .NET 8 only?

I run on my Windows machine dotnet build, and then from the actions:
dotnet tool install fake-cli --add-source "./src/app/fake-cli/bin/Debug" --add-source "./src/app/fake-cli/bin/Release" --version 1.0.0-1

It turned out that this didn't work properly. So I removed the Clean-task and called fake manually:

C:\git\FAKE>src\app\fake-cli\bin\Debug\net8.0\fake-cli -v build -e FAKE_DETAILED_ERRORS=true

And behold, all the integration tests went through, after painfully long half-an-hour later:

Where it did finally fail is:

dotnet.exe  deb --runtime linux-x64 --framework net8.0 --configuration Release --output "C:\git\FAKE\release\dotnetcore" --no-restore`

error NETSDK1045: The current .NET SDK does not support targeting .NET 8.0.  Either target .NET 6.0 or lower, or use a version of the .NET SDK that supports .NET 8.0. [C:\git\FAKE\src\app\fake-cl

So basically, dotnet deb tool has to be updated from 0.1.220 to version 0.1.232

FAKE/.config/dotnet-tools.json

Line 6 in 73fc961

"version": "0.1.220",

...and that's it, I think we could consider merging this and releasing a beta or new major version.

xperiandri · 2025-07-17T12:51:48Z

Can a dotnet tool even have multiple target frameworks?

@Thorium yes it can.
But there are some challenges with that.
You can see my changes in this PR to test that the older framework works fsprojects/FSharpLint#748

Numpsy · 2025-07-17T13:11:26Z

well for .NET6 projects and from now on everything else is .NET 8 only?

Whether there's any benefit to supporting .NET 6 in fake-cli any more is another question, and given the amount of pain in testing it all, just doing 8 seems simpler for a new major release?

.NET 10 is on the horizon, so making sure it works for that going forward seems more important than keeping 6 working in new versions. (My personal opinion anyway).

I'll see about rebasing it and fixing the conflicts anyway

Thorium · 2025-07-17T13:25:11Z

Many projects use a separate non-FAKE fsproj as a build-project and reference the FAKE libraries, and there I see value in having .NET6 support kept.

But the fake-cli tool, I think, could target only the NET8 (or even 10 later).

xperiandri · 2025-07-17T14:35:43Z

Then it will be impossible to run it unless you have the latest SDK installed

Numpsy · 2025-07-17T15:36:51Z

Then it will be impossible to run it unless you have the latest SDK installed

The 'DNX' stuff that MS are talking about with .NET 10 (https://github.com/dotnet/core/blob/main/release-notes/10.0/preview/preview6/sdk.md#platform-specific-net-tools) could maybe help if the tool could be self contained, but that's a work in progress so it remains to be seen

Numpsy · 2025-07-17T16:32:04Z

On the subject of targetting multiple .NET versions in fake-cli, re-reading the old comments reminded me of the situation with cachedDotnetSdkReleases.json - i.e., if the tool i smulti-targetted, you might need multiple versions of that file for different .NET versions?

Numpsy · 2025-07-17T19:07:11Z

@Thorium I didn't see your other PR until after i'd rebased the changes to fix the merge conflicts, which caused conflicts in that, so I've cherry picked your dotnet-deb update straight into this PR

Thorium · 2025-07-18T08:35:27Z

I think this file https://github.com/fsprojects/FAKE/blob/master/src/template/fake-template/Content/.config/dotnet-tools.json
says "use the nuget version of FAKE in the integration test templates", which causes any major changes to FAKE (like .NET update) to break the integration tests, because the NuGet version doesn't have these changes yet.

But I'm not sure if there is any workaround possible.

Thorium · 2025-07-18T10:30:56Z

One more thing: Because the system uses FSharp.Compiler.Service v43.8, the fsdocs-tool has to be upgraded from 16 to 20, to make GenerateDocs task pass.

Edit: Updated my PR, but you can also just do dotnet tool update fsdocs-tool instead.

After this, my local build does pass:

xperiandri · 2025-10-21T08:10:21Z

@arialdomartini

build.fsx

Numpsy · 2025-10-26T10:51:21Z

General question about all the FAKE modules - should they all be both .NET 6 and .NET 8, or just NET 8? (or maybe only 6 if they don't have any dependencies where it matters?)

src/app/fake-cli/fake-cli.fsproj

Numpsy · 2025-10-26T10:56:15Z

Otherwise the basic question is whether this should be turned into 8.0.0 alpha 1 and then the templates and tests fixed on top of that, or if it's worth trying something more minimal with just a .NET 8 / v8 build of fake-cli and then doing the modules afterwards.

Numpsy · 2025-10-26T23:15:13Z

I expect that there is a chicken-and-egg problem, and the integration tests are actually restoring the .NET6 fake to try compiling .NET8, instead of referring to the just built .NET 8 version.

I tried this branch locally (Numpsy/new8-build-bump-roll-tests-2) on my machine, and my observations are here:

src\app\fake-cli\bin\Release\ has now net6.0 and net8.0 paths. Can a dotnet tool even have multiple target frameworks? Or should we just accept that FAKE 6.1.3 is working well for .NET6 projects and from now on everything else is .NET 8 only?

I run on my Windows machine dotnet build, and then from the actions: dotnet tool install fake-cli --add-source "./src/app/fake-cli/bin/Debug" --add-source "./src/app/fake-cli/bin/Release" --version 1.0.0-1

It turned out that this didn't work properly. So I removed the Clean-task and called fake manually:

C:\git\FAKE>src\app\fake-cli\bin\Debug\net8.0\fake-cli -v build -e FAKE_DETAILED_ERRORS=true

And behold, all the integration tests went through, after painfully long half-an-hour later:

Where it did finally fail is:
dotnet.exe  deb --runtime linux-x64 --framework net8.0 --configuration Release --output "C:\git\FAKE\release\dotnetcore" --no-restore`

error NETSDK1045: The current .NET SDK does not support targeting .NET 8.0.  Either target .NET 6.0 or lower, or use a version of the .NET SDK that supports .NET 8.0. [C:\git\FAKE\src\app\fake-cl
So basically, dotnet deb tool has to be updated from 0.1.220 to version 0.1.232

FAKE/.config/dotnet-tools.json

Line 6 in 73fc961

"version": "0.1.220",

...and that's it, I think we could consider merging this and releasing a beta or new major version.

It appears to work (all integration tests pass) if the .NET 6 runtime files are present in the local .NET install created by the tests, but not otherwise.

So

If i run the tests from this branch on a clean setup, if fails as the CI does.

If I run the build from the master branch, it installs the .NET 6 libs into %AppData%\Local\Microsoft\dotnet to run the .NET 6 tests, and leaves the files there.

If I then run the tests from this branch again, it installs the .NET 8 libs into %AppData%\Local\Microsoft\dotnet alongside the .NET 6 libs rather than replacing them, and the template integration tests find those and the tests pass.

Having .NET 6 installed in the default system location doesn't effect this as the tests are looking in the custom install location.

SteveGilham · 2025-10-27T10:24:22Z

As net6.0 is past end of support, as is net7.0, after any necessary bridging release to get to net8.0, it would make sense to drop all mention of net6.0 - and work to prepare for net10.0 so we don't have an end of support crisis this time next year as both net8.0 and net9.0 are superseded on 10-Nov-26.

Let us hope that that process that time can be made as easy as "for a bridging release add mention of net10.0 at these points in the build system, the project targets and the code, then enable this bridging flag; for real net10.0 release, remove net8.0 and clear the flag. Lather, rinse repeat for net12.0, net14.0 ..."

Numpsy · 2025-10-27T21:27:45Z

src/test/Fake.DotNet.Cli.IntegrationTests/TemplateTests.fs

+        <packageSources>
+        <clear />
+        <add key="api.nuget.org" value="https://api.nuget.org/v3/index.json" />
+        <add key="localBuild" value="{nugetPackageFolder}" />


This allows the tests to find the locally built v8-alpha fake-cli package instead of always using the 6.1.4 version off nuget.org, which lets the test pass by using the .NET 8 version instead of the .NET 6 version

SteveGilham · 2025-10-28T15:39:26Z

src/app/Fake.Runtime/SdkAssemblyResolver.fs

Although RuntimeAssemblyVersions now defaults to a 2-element list, this is actually pointless as everything derived from the value starts by goes through |> Seq.head - lines 65-68 of this file. Retaining the sequence nature may help with the net10.0 (and future) update.

Lines 283, 295 still refer to a method net60releases; this could do with renaming when it refers to net8.0 SDKs.

I'm not sure if it should be both 6/8 now, or just 8 (will something running on .NET 8 ever want the .NET 6 libs?)
@Thorium ?

Maybe line 51 should be ReleaseVersion "8.0.0" as well

Lines 283, 295 still refer to a method net60releases; this could do with renaming when it refers to net8.0 SDKs.

renamed to netReleases

RELEASE_NOTES.md

Thorium · 2025-11-21T07:47:54Z

Should we skip net8 and go straight to net10.0 ?

Numpsy · 2025-11-21T11:08:18Z

Personally I'd say It's a bit early to not support .NET 8.0, but as said earlier it could do with having some .NET 10 testing now rather than later.

On a related note, the preview version of the paket cli that adds .NET 10 support requires .NET 8 so this change is a blocker for updating that as well.

Numpsy · 2025-11-24T20:01:54Z

Also on the subject of Paket, I tried updating to Paket.Core v10 to get ,NET 10 support and the build failed with https://github.com/Numpsy/FAKE/actions/runs/19647052005/job/56264684996#step:6:729 which I guess is down to the compressed metadata changes in FSharp.Core 9 not5 working with the .NET 6.0 SDK any more?

xperiandri · 2025-11-26T09:15:11Z

So, is it ready for merge?

Numpsy · 2025-11-26T14:07:08Z

It all builds and the tests all pass at least.

Someone maybe needs to confirm if all of the libraries need to target both .NET 6.0 and .NET 8.0 or could just be 8.0 for simplicity (if the tests are only run as 8 then the .NET 6 versions might not get any testing), but that could be tuned after the base updates are done)

Numpsy · 2025-11-26T19:08:49Z

Is there any value in completing #2880 and #2883 (on top on the unreleased #2879) for a last V6 release before moving everything to 8+, or is it not worth it?

Change global.json .NET 6 to 8 Search and replace targetframeworks from fsproj files to add net8.0 Add net8.0 to paket.dependencies dotnet paket install to find .NET8 compatible dependencies Expecto had to be hardcoded for now, because some tests are running on netstandard2.0 library (hopefully we can update this separately later) MSBuild.StructuredLogger problem: DisableInternalBinLog = true had to be added to build.fsx NuGet commands (hopefully we can update this separately later) A few places of code had new overrides so had to explicitly type to strings SdkAssemblyResolver to default .NET 8 as well Readme update GitHub pipeline configs: Add .NET 8 install.

…l has to be upgraded from 16 to 20, to make GenerateDocs task pass.

…the 8.0.0 alpha build Instead of pulling the 6.1.X build off NuGet.org. This might bootstrap the tests enough to get them all passing

…n 8.0.0 instead of 6.0.0

Because it might be .NET 8 releases now

… up the fix for GHSA-w3q9-fxm7-j8fq Also updates transitive dependencies on System.Text.Json to

xperiandri · 2025-11-26T21:07:02Z

#2880 does not pass. But I would merge if it does.
I think it is a good idea to include in v6 minor release

Numpsy · 2025-11-27T14:32:26Z

#2880 does not pass. But I would merge if it does. I think it is a good idea to include in v6 minor release

The build failure there looks like it needs Fantomas running on it

Numpsy commented Jan 9, 2025

View reviewed changes

Numpsy force-pushed the new8-build-bump-roll-tests-2 branch from 0364d81 to 233081b Compare July 17, 2025 17:31

Numpsy marked this pull request as ready for review July 17, 2025 19:07

Numpsy mentioned this pull request Sep 14, 2025

Update dotnet-deb to 0.1.232 #2869

Merged

Numpsy force-pushed the new8-build-bump-roll-tests-2 branch from 62084b1 to 7b0784d Compare October 21, 2025 10:09

Numpsy mentioned this pull request Oct 21, 2025

Using FAKE with recent frameworks (8.0 and 9.0) #2862

Open

Numpsy force-pushed the new8-build-bump-roll-tests-2 branch from 7b0784d to 41a04b5 Compare October 25, 2025 21:42

Numpsy commented Oct 26, 2025

View reviewed changes

build.fsx Outdated Show resolved Hide resolved

Numpsy commented Oct 26, 2025

View reviewed changes

src/app/fake-cli/fake-cli.fsproj Outdated Show resolved Hide resolved

Numpsy force-pushed the new8-build-bump-roll-tests-2 branch from 41a04b5 to ba8e1ed Compare October 26, 2025 13:47

Numpsy force-pushed the new8-build-bump-roll-tests-2 branch 2 times, most recently from fe22252 to 21017b8 Compare October 27, 2025 20:37

Numpsy commented Oct 27, 2025

View reviewed changes

SteveGilham reviewed Oct 28, 2025

View reviewed changes

xperiandri requested changes Oct 28, 2025

View reviewed changes

RELEASE_NOTES.md Outdated Show resolved Hide resolved

Numpsy force-pushed the new8-build-bump-roll-tests-2 branch from 21017b8 to 439ba10 Compare October 29, 2025 09:42

Thorium and others added 17 commits November 27, 2025 01:06

try to run integration-tests with net6.0

6e44924

uninstall didn't seem to work well anyway

a764225

publish both test-artifacts, ensure test DirectorySeparatorChar

73c3c8f

parentheses added

42300bb

integration tests back to 8

111d681

typo fix

1b4fc5b

fix merge

637b4ae

Try using the .NET 8 SDK for the resolver tests

796ade5

Try to work around dotnet/sdk#40655

2ef4329

Because the system uses FSharp.Compiler.Service v43.8, the fsdocs-too…

8a9cf87

…l has to be upgraded from 16 to 20, to make GenerateDocs task pass.

Fix merge

5b31678

Try to get the template integration tests working by making them use …

5650e39

…the 8.0.0 alpha build Instead of pulling the 6.1.X build off NuGet.org. This might bootstrap the tests enough to get them all passing

update

94a7e31

Change SdkAssemblyResolver.SdkVersions to take an empty string to mea…

b7e4f67

…n 8.0.0 instead of 6.0.0

In GetProductReleasesForSdk(), rename 'net60releases' to 'netReleases'

c6c2ad7

Because it might be .NET 8 releases now

Update the Microsoft.Build libraries from 17.11.4 to 17.11.48 to pick…

afe43a2

… up the fix for GHSA-w3q9-fxm7-j8fq Also updates transitive dependencies on System.Text.Json to

xperiandri force-pushed the new8-build-bump-roll-tests-2 branch from ae027fd to afe43a2 Compare November 26, 2025 21:06

Further attempts at building with .NET 8 #2852

Are you sure you want to change the base?

Further attempts at building with .NET 8 #2852

Uh oh!

Conversation

Numpsy commented Jan 9, 2025

Description

Uh oh!

Choose a reason for hiding this comment

Uh oh!

Choose a reason for hiding this comment

Uh oh!

github-actions bot commented Jan 9, 2025 • edited Loading Uh oh! There was an error while loading. Please reload this page.

Uh oh!

Test Results

Uh oh!

Numpsy commented Jan 9, 2025

Uh oh!

Thorium commented Jul 17, 2025 • edited Loading Uh oh! There was an error while loading. Please reload this page.

Uh oh!

Uh oh!

xperiandri commented Jul 17, 2025

Uh oh!

Numpsy commented Jul 17, 2025

Uh oh!

Thorium commented Jul 17, 2025

Uh oh!

xperiandri commented Jul 17, 2025 • edited Loading Uh oh! There was an error while loading. Please reload this page.

Uh oh!

Uh oh!

Numpsy commented Jul 17, 2025

Uh oh!

Numpsy commented Jul 17, 2025

Uh oh!

Numpsy commented Jul 17, 2025

Uh oh!

Thorium commented Jul 18, 2025

Uh oh!

Thorium commented Jul 18, 2025 • edited Loading Uh oh! There was an error while loading. Please reload this page.

Uh oh!

Uh oh!

xperiandri commented Oct 21, 2025

Uh oh!

Uh oh!

Numpsy commented Oct 26, 2025

Uh oh!

Uh oh!

Numpsy commented Oct 26, 2025

Uh oh!

Numpsy commented Oct 26, 2025

Uh oh!

SteveGilham commented Oct 27, 2025

Uh oh!

Choose a reason for hiding this comment

Uh oh!

Choose a reason for hiding this comment

Uh oh!

Choose a reason for hiding this comment

Uh oh!

Choose a reason for hiding this comment

Uh oh!

Choose a reason for hiding this comment

Uh oh!

Choose a reason for hiding this comment

Uh oh!

Uh oh!

Thorium commented Nov 21, 2025

Uh oh!

Numpsy commented Nov 21, 2025

Uh oh!

Numpsy commented Nov 24, 2025

Uh oh!

xperiandri commented Nov 26, 2025

Uh oh!

Numpsy commented Nov 26, 2025

Uh oh!

Numpsy commented Nov 26, 2025

Uh oh!

xperiandri commented Nov 26, 2025

Uh oh!

github-actions bot commented Jan 9, 2025 •

edited

Loading

Thorium commented Jul 17, 2025 •

edited

Loading

xperiandri commented Jul 17, 2025 •

edited

Loading

Thorium commented Jul 18, 2025 •

edited

Loading