17.12.3 breaks build with F# issues

[vsfeedback]

This issue has been moved from a ticket on Developer Community.

---

[severity:I'm unable to use this version] [regression] [worked-in:17.10.9]
Scenario:
F# project (.Net 6 - project A) references F# project (.Net Standard 2.0 - Project B)
Build fails for project A finding namespaces referenced in project B.
The referenced project (project B) builds without error.

The same source code builds fine with 17.10.6 (and 17.10.9)

Last successful Azure build was 14 November (see Log_24632_SUCCESS.zip).
Same source code (same commit on Master branch) fails from 27 November (see Log_24757_FAILED.zip)

I was able to reproduce the same build issues when I upgraded my local instance of VS2022 from 17.10.6 to 17.12.3

I'm restoring my old version so I can continue to build without issues, but my pipeline is Azure hosted and fails.

I have logged a DevOps / Azure ticket - TrackingID#2412040030001596

---

Original Comments

Feedback Bot on 12/5/2024, 05:32 AM:

We have directed your feedback to the appropriate engineering team for further evaluation. The team will review the feedback and notify you about the next steps.

[0101]

Can you provide a minimal repro for this?

[vzarytovskii]

Can you provide a minimal repro for this?

That is a feedback issue, please refer to internal ticket, it has logs provided.

[0101]

From the logs we can see that fscAnyCpu.exe from VS 17.12.3 produces a (netstandard2.0) DLL that dotnet\sdk/6.0.405/FSharp/fsc.dll seems to have issues consuming (The namespace or module '...' is not defined.)

It's hard to say what the problem is without the source code or at least the DLL that was produced.

[0101]

Another question is why the 6.0.405 compiler is used. Since it's now officially out of support we recommend using a newer version by removing the pinned version from global.json or choosing a newer one.

It's also not quite clear why the ADO VS Build step uses VS built-in compiler for some targets and the SDK one for others.

[semaxtremesoftware]

Another question is why the 6.0.405 compiler is used. Since it's now officially out of support we recommend using a newer version by removing the pinned version from global.json or choosing a newer one.

It's also not quite clear why the ADO VS Build step uses VS built-in compiler for some targets and the SDK one for others.

Hi,
The solution is massive - it has 250 projects in it.
Some target .Net 4.8, others .Net 6.0 - hence the 6.0.4.5 in global.json
Some are in C# and a few are in F#.
The F# are all .Net 6.0 but are consumed by both .Net 6.0 and .Net 4.8 projects.

I'm not really sure why the build pipeline uses both VS-built-in compile and SDK to build - but there are several outputs from this process.
The main project is a web application that runs under Azure (.Net 4.8).
There is a Desktop app as well (WPF in .Net 4.8) that is not specifically built in this process (there is another pipeline that builds the desktop app), but there are a lot of projects that are shared between the web and desktop apps.
There are some UIs for the web app that are done in F# and require Fable to transpile them.
Typically, these are the ones that are compiled using the SDK - probably done to get Fable to build correctly.
This is then all packaged up using webpack and deployed as part of the main web app.

The build process has been working for a while - at least the 2 years I've been working for the company.

[T-Gro]

Thanks for the added explanation @semaxtremesoftware .

Newer SDK (v9, ideally) can target older frameworks, including net481 or net6.
In general, newer SDK will give you more compiler fixes and optimizations even if your target runtime is an older one.

Could you please try either removing the pinned SDK in global.json alltogether, or changing it to a newer one like 9.0.200 ?

[semaxtremesoftware]

Thanks for the added explanation @semaxtremesoftware .

Newer SDK (v9, ideally) can target older frameworks, including net481 or net6. In general, newer SDK will give you more compiler fixes and optimizations even if your target runtime is an older one.

Could you please try either removing the pinned SDK in global.json alltogether, or changing it to a newer one like 9.0.200 ?

Will try and get back to you - thanx

[semaxtremesoftware]

I have changed the global.json file to reflect version 9.0.200 and changed the builds back to cloud hosted agent on windows-latest.
I now get these errors:
##[error]C:\hostedtoolcache\windows\dotnet\sdk\9.0.200\Sdks\Microsoft.NET.Sdk\targets\Microsoft.PackageDependencyResolution.targets(266,5): Error NETSDK1004: Assets file 'D:\a\1\s\Semaphore.Accelerus.Data\obj\project.assets.json' not found. Run a NuGet package restore to generate this file.

The thing is that I do a Nuget restore already, then a dotnet restore (on specific .Net projects) then dotnet build (on specific dotnet projects) and then the VSBuild on the main web solution.

The pipeline hasn't changed and works on the self-hosted agent and worked up-until December when the cloud agent broke the build