sdk
sdk copied to clipboard
dotnet
[dotnet watch] Cannot open project Lib.fsproj because extension fsproj is not associated with a language
Build Information
Build: https://dev.azure.com/dnceng-public/public/_build/results?buildId=932408 Build error leg or test failing: dotnet-sdk-public-ci
Error Message
{
"ErrorMessage" : "because the file extension '.fsproj' is not associated with a language",
"BuildRetry" : false,
"ExcludeConsoleLog" : false
}
- PR: https://github.com/dotnet/sdk/pull/46255
- Queue: FullFramework: windows (x64)
- Job result: https://dev.azure.com/dnceng-public/public/_build/results?buildId=932408&view=logs&j=2709a726-7db6-5829-ca7b-958b9d664f9e&t=9c6bf218-1bed-58a8-ccb2-7aefc7e3994e
- Log file: https://helixr1107v0xdeko0k025g8.blob.core.windows.net/dotnet-sdk-refs-pull-46255-merge-f03a79adaa674a1187/dotnet-watch.Tests.dll.1/1/console.1a860fa0.log?helixlogtype=result
- Output:
dotnet watch ⚠ msbuild: [Failure] Cannot open project
'C:\h\w\B34E099A\t\dotnetSdkTests\geksol2n.pb2\RenameSourceF---5F6BBE1E\FSharp\Lib.fsproj'
because the file extension '.fsproj' is not associated with a language.
Known issue validation
Build: :mag_right: https://dev.azure.com/dnceng-public/public/_build/results?buildId=932408
Error message validated: [because the file extension '.fsproj' is not associated with a language]
Result validation: :white_check_mark: Known issue matched with the provided build.
Validation performed at: 1/28/2025 10:53:09 PM UTC
Report
| Build | Definition | Step Name | Console log | Pull Request |
|---|---|---|---|---|
| 2732227 | dotnet-sdk | Run dotnet-format on dotnet/aspnetcore AspNetCore.sln | Log | #50989 |
Summary
| 24-Hour Hit Count | 7-Day Hit Count | 1-Month Count |
|---|---|---|
| 1 | 12 | 111 |
I thought @tmat already fixed this with a servicing fix to the 9.0.1xx releases? It should be in 102 or 103?
This commit hasn't been integrated to main yet: https://github.com/dotnet/sdk/commit/3cd7c654c9052b5e08be0927d7dea9b01ac3b8c3
@tmat, just hit this issue in https://github.com/dotnet/sdk/pull/45419, which is targeting release/9.0.3xx. I don't think this worked.
@Forgind You can ignore Mac ARM64 failures. The machines are slow and the tests time out.
@Forgind You can ignore Mac ARM64 failures. The machines are slow and the tests time out.
Can you explain that a bit further? @marcpopMSFT told me that those machines should actually be faster than the x64 machines. That said, we've also had a lot of timeouts and are actively working on figuring out why (without success as of yet, hence the PR I linked). It may be that we've just misunderstood where the issue is on that leg, and we should just increase the timeout across the board.
@Forgind Not sure what the status is right now, but the Mac ARM64 CI leg has been optional for a while.
It's optional right now because it's been timing out, but we've been trying to figure out why it keeps timing out so we can turn it back on. I don't know that it's just automatically slow.
Oh, I see. So in this specific case the logs show that dotnet build is taking very long time. Not sure where it gets stuck:
Microsoft.DotNet.Watch.UnitTests.ApplyDeltaTests.AddSourceFile [OUTPUT] dotnet watch 🚀 Launched '/private/tmp/helix/working/B2910953/p/d/dotnet' with arguments 'build /private/tmp/helix/working/B2910953/w/A696090A/e/testExecutionDirectory/AddSourceFile---E93D266F/AppWithDeps/App.WithDeps.csproj -consoleLoggerParameters:NoSummary;Verbosity=minimal': process id 96065
Seems like memory dumps were saved but I don't see them in the artifact list.
To clarify, forgind was trying to get context on your comment that the arm64 machines are slow. Ever since we added that leg, it has been fairly consistently timing out. When I asked the codeflow chat, they indicated that arm64 should be faster than x64 so it wasn't a machine issue and we should dig further. That's when we made them optional, later turned them off, and have been trying to find out why they are timing out ever since. Do you have a reason to believe the mac arm64 machines are slower than the x64 ones?
Do you have a reason to believe the mac arm64 machines are slower than the x64 ones?
No specific reason. I didn't know forgind is trying to figure out why. Just stating that we have been skipping the CI leg because it's been timing out.
@tmat, hit this again in https://github.com/dotnet/sdk/pull/47110
Please fix this.
This fixes a potential race condition: https://github.com/dotnet/sdk/pull/47117 It looks like this race is hit by https://github.com/dotnet/sdk/pull/47110 based on the test logs.
@Forgind I don't see dotnet-watch failure in that PR.
Found this though:
xUnit.net 00:00:31.22] System.TypeLoadException : Could not load type 'FluentAssertions.Execution.Execute' from assembly 'FluentAssertions, Version=8.0.2.0, Culture=neutral, PublicKeyToken=33f2691a05b67b6a'.
projecttoolscommandresolver: invalid commandResolverArguments
[xUnit.net 00:00:31.22] Stack Trace:
[xUnit.net 00:00:31.22] at Microsoft.NET.TestFramework.Assertions.CommandResultAssertions.Pass()
[xUnit.net 00:00:31.22] at Microsoft.NET.TestFramework.Assertions.CommandResultAssertions.Pass()
[xUnit.net 00:00:31.22] /_/test/Microsoft.NET.TestFramework/TestAsset.cs(268,0): at Microsoft.NET.TestFramework.TestAsset.Restore(ITestOutputHelper log, String relativePath, String[] args)
[xUnit.net 00:00:31.22] D:\a\_work\1\s\test\Microsoft.DotNet.CommandFactory.Tests\GivenAProjectToolsCommandResolver.cs(170,0): at Microsoft.DotNet.Tests.GivenAProjectToolsCommandResolver.ItReturnsACommandSpecWithArgsContainingCommandPathWhenReturningACommandSpecAndCommandArgumentsAreNull()
[xUnit.net 00:00:31.22] at System.RuntimeMethodHandle.InvokeMethod(ObjectHandleOnStack target, Void** arguments, ObjectHandleOnStack sig, BOOL isConstructor, ObjectHandleOnStack result)
[xUnit.net 00:00:31.22] at System.Reflection.MethodBaseInvoker.InterpretedInvoke_Method(Object obj, IntPtr* args)
[xUnit.net 00:00:31.22] at System.Reflection.RuntimeMethodInfo.Invoke(Object obj, BindingFlags invokeAttr, Binder binder, Object[] parameters, CultureInfo culture)