Net 10.0
This is again the time of year to waste our time on mandatory technical infrastructure updates without real business benefit. But I guess that's the trade-off of having amazing technology stack.
We need to support running on Net 10 projects.
@Thorium did you check/test 0.26.8? I released it 2h ago and has a fix for running in .NET10.
Compiling master with .NET10 should also almost be there thanks to a couple of @Numpsy's fixes; if you find more issues please post them here.
It works!
Hijacking this issue, v0.26.8 doesn't work for me.
global.json
{
"sdk": {
"version": "10.0.100",
"rollForward": "latestMinor"
}
}
❯ dotnet fsharplint --version
Current version: 0.26.8+9e576592575d2fb2530656a9922876ebf6b66d15
❯ dotnet fsharplint lint Solution.slnx
Lint failed while analysing Solution.slnx.
Failed with: Could not load file or assembly 'System.Runtime, Version=10.0.0.0, Culture=neutral, PublicKeyToken=b03f5f7f11d50a3a'. The system cannot find the file specified.
Stack trace: at FSharpLint.Application.Lint.lintSolution$cont@516(OptionalLintParameters optionalParams, ToolsPath toolsPath, String solutionFilePath, String solutionFolder, FSharpResult`2 matchValue, Unit unitVar)
at FSharpLint.Application.Lint.lintSolution(OptionalLintParameters optionalParams, String solutionFilePath, ToolsPath toolsPath) in /home/runner/work/FSharpLint/FSharpLint/src/FSharpLint.Core/Application/Lint.fs:line 514
at FSharpLint.Console.Program.start(ParseResults`1 arguments, ToolsPath toolsPath) in /home/runner/work/FSharpLint/FSharpLint/src/FSharpLint.Console/Program.fs:line 182
global.json
what's this exactly? a global.json file that you have placed in the working directory before running the tool? If yes, can you try without this file please?
Current version: 0.26.8+9e576592575d2fb2530656a9922876ebf6b66d15
Sorry what? that version doesn't exist: https://www.nuget.org/packages/dotnet-fsharplint/#versions-body-tab
Hi,
global.json docs: https://learn.microsoft.com/en-us/dotnet/core/tools/global-json
I can try again later without it, but specifying a dotnet version using global.json is widely adopted and shouldn't break this tool.
Regarding tool version, I don't think I did anything special to get this version:
.config/dotnet-tools.json
{
"version": 1,
"isRoot": true,
"tools": {
"fantomas": {
"version": "7.0.3",
"commands": [
"fantomas"
],
"rollForward": true
},
"dotnet-fsharplint": {
"version": "0.26.8",
"commands": [
"dotnet-fsharplint"
],
"rollForward": true
}
}
}
❯ dotnet tool restore
Tool 'fantomas' (version '7.0.3') was restored. Available commands: fantomas
Tool 'dotnet-fsharplint' (version '0.26.8') was restored. Available commands: dotnet-fsharplint
Restore was successful.
❯ dotnet fsharplint --version
Current version: 0.26.8+9e576592575d2fb2530656a9922876ebf6b66d15
This is all on Linux, maybe different behavior on Windows?
I'm unable to reproduce this in a container with a simple console app, eg.
FROM mcr.microsoft.com/dotnet/sdk:10.0.100-alpine3.22@sha256:7d98d5883675c6bca25b1db91f393b24b85125b5b00b405e55404fd6b8d2aead AS restore
WORKDIR /build
COPY global.json global.json
COPY .config/dotnet-tools.json .config/dotnet-tools.json
COPY Solution.slnx Solution.slnx
COPY src/Console.fsproj src/Console.fsproj
COPY src/packages.lock.json src/packages.lock.json
RUN dotnet tool restore && dotnet restore --locked-mode
FROM restore AS source
COPY src/Program.fs src/Program.fs
FROM source AS lint
RUN dotnet fsharplint --version && dotnet fsharplint lint Solution.slnx
This works fine:
docker build --progress=plain --no-cache .
#14 [lint 1/1] RUN dotnet fsharplint --version && dotnet fsharplint lint Solution.slnx
#14 0.533 Current version: 0.26.8+9e576592575d2fb2530656a9922876ebf6b66d15
#14 2.975 ========== Linting /build/src/obj/Debug/Console.AssemblyInfo.fs ==========
#14 3.118 ========== Finished: 0 warnings ==========
#14 3.118 ========== Linting /build/src/obj/Debug/.NETCoreApp,Version=v10.0.AssemblyAttributes.fs ==========
#14 3.136 ========== Finished: 0 warnings ==========
#14 3.136 ========== Linting /build/src/Program.fs ==========
#14 3.163 ========== Finished: 0 warnings ==========
#14 3.164 ========== Summary: 0 warnings ==========
#14 DONE 3.2s
So maybe this is a more general issue with having multiple dotnet versions installed on a linux machine and not actually a problem with FSharpLint 🤔
Running the same command outside of the container still fails as reported previously:
❯ dotnet fsharplint lint Solution.slnx
Lint failed while analysing Solution.slnx.
Failed with: Could not load file or assembly 'System.Runtime, Version=10.0.0.0, Culture=neutral, PublicKeyToken=b03f5f7f11d50a3a'. The system cannot find the file specified.
Stack trace: at FSharpLint.Application.Lint.lintSolution$cont@516(OptionalLintParameters optionalParams, ToolsPath toolsPath, String solutionFilePath, String solutionFolder, FSharpResult`2 matchValue, Unit unitVar)
at FSharpLint.Application.Lint.lintSolution(OptionalLintParameters optionalParams, String solutionFilePath, ToolsPath toolsPath) in /home/runner/work/FSharpLint/FSharpLint/src/FSharpLint.Core/Application/Lint.fs:line 514
at FSharpLint.Console.Program.start(ParseResults`1 arguments, ToolsPath toolsPath) in /home/runner/work/FSharpLint/FSharpLint/src/FSharpLint.Console/Program.fs:line 182
Switching back to dotnet 9 also makes lint work outside of the container:
global.json
{
"sdk": {
"version": "9.0.308"
}
}
❯ dotnet tool restore
❯ dotnet restore
❯ dotnet fsharplint lint Solution.slnx
========== Linting /home/peter/Projects/test/fsharplint-net10/src/obj/Debug/Console.AssemblyInfo.fs ==========
========== Finished: 0 warnings ==========
========== Linting /home/peter/Projects/test/fsharplint-net10/src/obj/Debug/.NETCoreApp,Version=v9.0.AssemblyAttributes.fs ==========
========== Finished: 0 warnings ==========
========== Linting /home/peter/Projects/test/fsharplint-net10/src/Program.fs ==========
========== Finished: 0 warnings ==========
========== Summary: 0 warnings ==========
Edit: Looks like dotnet-ef has a very similar issue, see https://github.com/dotnet/efcore/issues/37201 and https://github.com/dotnet/efcore/issues/37128
They are working on a fix, so maybe this can be ported here later. 🤷
Current version: 0.26.8+9e576592575d2fb2530656a9922876ebf6b66d15
Sorry what? that version doesn't exist: https://www.nuget.org/packages/dotnet-fsharplint/#versions-body-tab
The --version option is printing the assembly informational version, which might include a git commit hash added by the build tools (source link etc)
The --version option is printing the assembly informational version, which might include a git commit hash added by the build tools (source link etc)
Ah thanks for clarifying @Numpsy , I didn't realise that --version command also prints the git hash prepending a + character.
global.json docs:
Of course I know what a global.json file is, what I was asking you is to frame that file, as in, why do you post its content and not its location? And why did you decide to use it instead of not using it? And why did you decide to use the .NET version and roll-forward policy in it this way?
Long story short: I bet that you have that global.json in the same directory to your file Solution.slnx because it is what you need yourself to build your solution file? But this my gut telling me this, but I wanted the information from you.
Thing is, there is a chance that this global.json, if I was right that you only need it for building Solution.slnx, it might unfortunately be affecting the execution of FSharpLint. Can you please test again but renaming the global.json file for it not to affect it? (Which essentially would probably achieve the same effect that you achieved by running in an isolated docker container, but please confirm this to us first and then we can dwelve about the contents of this global.json file and how it might be affecting FSharpLint.)
Yes, the global.json is placed next to the Solution.slnx at the root of the project. I don't think it can be placed anywhere else. I renamed it and still got the same error (after clean + restore). I also copied it into the container where everything works.
I looked into the similar issue dotnet-ef currently has. If I understand correctly they are switching their tool back to net8, so this is not applicable here, since you already target net9/net8. 🤔
I'm wondering if this is happening because you don't use actions/setup-dotnet to install a specific dotnet version for the CI build, but it doesn't really explain why everything works in the container.
I renamed it and still got the same error
That's weird. Let's try removing it instead of renaming it? Just to double check.
If that doesn't help, can you change your "rollForward" setting to LatestMajor? It's what we did recently to fix a problem with .NET10: https://github.com/fsprojects/FSharpLint/pull/784
I'm wondering if this is happening because you don't use actions/setup-dotnet
Our fix in PR784 included a regression test that basically reproduced your issue (well, not your issue in particular, but the same exception/crash you're facing) inside a docker container, and proved that our rollForward change fixed it. Now, you might notice that this regression test explicitly run without a global.json file in the current directory, so that's why I'm thinking that the bug you're running into now happens with a specific global.json configuration (so, slightly different bug) and that's why I was hoping that removing it might workaround the crash.
Issue resolved by deleting ~/.nuget/packages/dotnet-fsharplint/ 🤔
❯ rm -rf ~/.nuget/packages/dotnet-fsharplint/
❯ dotnet tool restore
❯ dotnet fsharplint lint Solution.slnx
========== Linting /home/peter/Projects/test/fsharplint-net10/src/obj/Debug/Console.AssemblyInfo.fs ==========
========== Finished: 0 warnings ==========
========== Linting /home/peter/Projects/test/fsharplint-net10/src/obj/Debug/.NETCoreApp,Version=v9.0.AssemblyAttributes.fs ==========
========== Finished: 0 warnings ==========
========== Linting /home/peter/Projects/test/fsharplint-net10/src/Program.fs ==========
========== Finished: 0 warnings ==========
========== Summary: 0 warnings ==========
Unfortunately now I can't diff the files. All I have is the previous file list:
❯ fd fsharplint
packages/dotnet-fsharplint/
packages/dotnet-fsharplint/0.21.3/dotnet-fsharplint.0.21.3.nupkg
packages/dotnet-fsharplint/0.21.3/dotnet-fsharplint.0.21.3.nupkg.sha512
packages/dotnet-fsharplint/0.21.3/tools/net5.0/any/fsharplint.json
packages/dotnet-fsharplint/0.21.3/tools/net5.0/any/dotnet-fsharplint.dll
packages/dotnet-fsharplint/0.21.3/tools/net5.0/any/FSharpLint.Core.dll
packages/dotnet-fsharplint/0.21.3/tools/net5.0/any/dotnet-fsharplint.deps.json
packages/dotnet-fsharplint/0.21.3/tools/net5.0/any/FSharpLint.Core.xml
packages/dotnet-fsharplint/0.21.3/dotnet-fsharplint.nuspec
packages/dotnet-fsharplint/0.26.8/dotnet-fsharplint.0.26.8.nupkg.sha512
packages/dotnet-fsharplint/0.26.8/dotnet-fsharplint.0.26.8.nupkg
packages/dotnet-fsharplint/0.26.8/dotnet-fsharplint.nupkg
packages/dotnet-fsharplint/0.21.3/tools/net5.0/any/dotnet-fsharplint.runtimeconfig.json
packages/dotnet-fsharplint/0.26.8/tools/net9.0/any/fsharplint.json
packages/dotnet-fsharplint/0.26.8/tools/net9.0/any/dotnet-fsharplint.dll
packages/dotnet-fsharplint/0.26.8/tools/net9.0/any/FSharpLint.Core.dll
packages/dotnet-fsharplint/0.26.8/tools/net9.0/any/dotnet-fsharplint.deps.json
packages/dotnet-fsharplint/0.26.8/tools/net9.0/any/dotnet-fsharplint.runtimeconfig.json
packages/dotnet-fsharplint/0.26.8/tools/net9.0/any/FSharpLint.Core.xml
packages/dotnet-fsharplint/0.26.8/tools/net8.0/any/fsharplint.json
packages/dotnet-fsharplint/0.26.8/tools/net8.0/any/dotnet-fsharplint.dll
packages/dotnet-fsharplint/0.26.8/tools/net8.0/any/FSharpLint.Core.dll
packages/dotnet-fsharplint/0.26.8/tools/net8.0/any/dotnet-fsharplint.deps.json
packages/dotnet-fsharplint/0.26.8/tools/net8.0/any/dotnet-fsharplint.runtimeconfig.json
packages/dotnet-fsharplint/0.26.8/tools/net8.0/any/FSharpLint.Core.xml
packages/dotnet-fsharplint/0.26.8/dotnet-fsharplint.nuspec
Unclear why this worked. Maybe the files were corrupted?