-
-
Notifications
You must be signed in to change notification settings - Fork 279
New issue
Have a question about this project? Sign up for a free GitHub account to open an issue and contact its maintainers and the community.
By clicking “Sign up for GitHub”, you agree to our terms of service and privacy statement. We’ll occasionally send you account related emails.
Already on GitHub? Sign in to your account
"Not in a F# project (Still loading...)", but the folder is a dotnet scaffolded .fsproj #1697
Comments
So I haven't looked into anything else, but as of Ionide 6, .net 6 is required. You'll want to make sure that you have that installed. .net 5 goes out of support in about 2 weeks. |
I built the extension from source, and this is the output I get when running it, with the same project as above:
|
I have the same issue when opening an F# project in WSL 2, using the most recent Ionide version. In my WSL, I am running Ubuntu 22.04 and .NET 6.0.5. |
Same for me, WSL2 ubuntu 20.04, dotnet 6.0.101. The first error I got was dotnet could not be found (altough it is in PATH) and then I set |
I encountered the same issue. Same story as jonaskello. |
I've had this bug for a long time and it turned out that I had a bug in my settings. The "FSharp: Dotnet Root" was set to |
@dbrattli I tried both. Pointing directly at the binary causes the |
I already have the path /usr/share/dotnet set, and the binary is /usr/share/dotnet/dotnet. Ionide still complains with the same error. I'm just using the "F# Language Server updated" extension now. Shame. |
sorry folks - things are languishing a bit due to personal circumstances. if anyone wants to build + run the extension locally and try to reproduce or get a stack trace that could help a lot in narrowing down the root cause. |
Hi @baronfel . Do you need more than this? #1697 (comment) |
@baronfel given some guidance, I'm happy to try and resolve this. It's a completely alien codebase though, and I'm not even all that knowledgeable when it comes to the dependencies. Give me some good directions though, and I'm probably capable of getting to the bottom of it. |
it looks like the root cause of the OP was not finding the |
Exact same issue for me. And stems from not finding the dotnet installation. Setting dotnet root to (base) jovyan@Mikael-Surface:~/work/FsAlgo/FsAlgoLib$ whereis dotnet
dotnet: /usr/bin/dotnet /usr/share/dotnet (base) jovyan@Mikael-Surface:~/work/FsAlgo/FsAlgoLib$ ls -la /usr/bin/dotnet
lrwxrwxrwx 1 root root 22 Jun 22 11:18 /usr/bin/dotnet -> ../share/dotnet/dotnet I'm using ubuntu:20.04 container on WSL2. |
interesting - I know we've had problems with WSL before, I wonder if that's causing any problems... the next release should do better all around though - FSAC should pick up the dotnet that it's spawned with, and Ionide itself has better/more detailed/more consistent error messages that guide the user to configuring the dotnet path. |
I was having this exact same issue on macOS, albeit not really sure if it was because the dotnet executable could not be loaded. In my case I was having the same message, but the solution loaded correctly, just with no items in any of the projects I have inside (dependencies seemed to load correctly) and I did not get any error messages anywhere. I was able to fix it by removing a bunch of versions of the SDK that I had lying around. This was the output of the dotnet uninstall list before removing (when it was not working): ~/dotnet-core-uninstall 4.2s λ ./dotnet-core-uninstall list
This tool cannot uninstall versions of the runtime or SDK that are installed using zip/scripts. The versions that can be uninstalled with this tool are:
.NET Core SDKs:
6.0.400-preview.22330.6 (arm64) [Used by Visual Studio for Mac. Specify individually or use —-force to remove]
6.0.203 (arm64)
6.0.201 (arm64)
3.1.421 (x64)
3.1.419 (x64)
.NET Core Runtimes:
6.0.6 (arm64) [Used by Visual Studio for Mac or SDKs. Specify individually or use —-force to remove]
6.0.6 (x64)
6.0.5 (arm64)
6.0.5 (x64)
6.0.3 (arm64)
6.0.3 (x64) And after removing the preview one + a bunch of older ones: ~/dotnet-core-uninstall λ ./dotnet-core-uninstall list
This tool cannot uninstall versions of the runtime or SDK that are installed using zip/scripts. The versions that can be uninstalled with this tool are:
.NET Core SDKs:
6.0.203 (arm64) [Used by Visual Studio for Mac. Specify individually or use —-force to remove]
.NET Core Runtimes:
6.0.6 (arm64) [Used by Visual Studio for Mac or SDKs. Specify individually or use —-force to remove]
6.0.6 (x64) And now it seems to work magically. Don't know if it's just a coincidence or if it was really caused by any of these versions, but it did happen 100% before uninstalling them. |
@sleepyfran did you try final |
It is definitely SDK 6.0.400 related issue. As soon as I removed it from the system and reverted to 6.0.302 ionide works like a charm again. Setup:
|
Yes, we've had numerous reports about the 6.0.4xx previews, as well as the 7.0.1xx previews. Just haven't had time to figure out what's going on. I'll add a pinned issue to this repo saying that we're having issues with them in the meantime, hopefully that will help folks save some troubleshooting time. |
@baronfel obviously 6.0.400-preview issues now became 6.0.400 official release issues. Hope you will sort it out soon. |
Thanks for the clarification! Any pointers on where to start looking if I were to compile the extension locally to investigate? Would love to help with the investigation 😄 |
Hitting the same problem with dev containers. The problem is with dev containers you can't pick a different SDK than 400 at the moment. |
Please resolve this issue. |
@ken-okabe what kinds of errors are you seeing? can your provide any logs from the |
Reading your comment, I have confirmed the existence of the F# output panel. In fact, I tried to identify the cause of this c issue myself, but it has been totally random. |
If you were using .net 8 previews and experiencing this issue, the newly-released 7.7.1 version of Ionide should resolve it. |
I have the error now. Ionide for F# v7.7.1 I manage .net version control with symlink.
The VSCode built-in terminal has the working dotnet path, just Ionide extension complains My request: I want this extension to make sure to use the identical context of the shell as the one the VSCode built-in terminal uses. Note: I am writing a book about functional programming using TypeScript and F#. For TypeScript, the environment is stable, and I could write How to start TypeScript in VSCode, however, for F#, since the Ionide setup has been pretty unstable, I always have trouble to write How to start F# in VSCode, and I feel sorry for the unstability of F# setup that would blocks the beginner to join F# world. |
@ken-okabe did you set the DOTNET_ROOT environment variable when setting up your custom execution environment? That's documented as required in the manual installation instructions for .Net, and we have logic to look for that value if set. |
Thanks, actually, I recognize that, but the point is I need .net version control. Multiple versions of .net SDK coexist side by side, and the global environment variables obviously does not fit the purpose. The document is for beginners not knowing what they are doing. For the purpose of running the local .net version, I do The point is, sometimes this method works in some F# project, but not always. If a user properly configured the global environment variables, The bottom line is this should not happen: The VSCode built-in terminal recognizes |
Your dotnet binary doesn't behave the way you think it does without that environment variable. The variable is used by a dotnet binary to locate the runtimes available for an installation, and without it you very likely are in a mixed configuration. If you DO want to continue using your custom install (which is pretty common!) you must set that variable. In general, what you're describing is an unsupported installation of the .NET tooling, and this extension isn't going to go out of its way to support it. It's just not worth it in terms of development time for us to do so, especially when the rest of the stack won't recognize your install. |
Thanks, then, now I have a question within the range officially supported installation of the .NET tooling. Select the .NET version to use
If a How Ionide behaves in this case? As long as I've read your comment for the design, the extension only reads the If I'm wrong, please correct. |
Ionide isn't unique in this approach, either - this was chosen specifically to align with how the rest of the world of .NET tooling works with regards to SDK location. |
I see. So far, I have not yet succeeded to work with the multiple .net version here, but I will study further. |
I have the same issue with
I have DOTNET_ROOT defined in my .bashrc |
@sharno I had a similar problem when running VSCode/Ionide inside of It looks like sometimes VSCode doesn't load the profile correctly of something. To work around this issue, I set the VSCode setting You can find the path by running |
@MangelMaxime didn't change anything, I added the path of my dotnet in that setting in VSCode and it still gives the same message: |
I will share my note that works. How to setup multiple dotnet versions
|
@ken-okabe Thank you. I had an old .NET 6 ghost in My .NET 7 and 8 installed with apt-get from Ubuntus repository is in |
You are welcome 😇 |
I would like to share what I've found. When <Project Sdk="Microsoft.NET.Sdk">
<PropertyGroup>
<OutputType>Exe</OutputType>
<TargetFramework>net8.0</TargetFramework>
</PropertyGroup>
<ItemGroup>
<Compile Include="./lib/*.fs" />
<Compile Include="Program.fs" />
</ItemGroup>
</Project>
I think simply it should watch new files addition and trigger again. The workaround for the current issue is obviously, re-launch the VSCode which I'm doing right now, which leads an impression the tool is unstable and unproductive. |
This problem is not as straightforward. ionide/FsAutoComplete#1155, but we be happy for someone to come up with ideas in this area. |
https://code.visualstudio.com/api/references/vscode-api#FileSystemWatcher should be able to handle this issue. ionide-vscode-fsharp obviously starts the initial process when the extension is activated, so using the FileSystemWatcher api, it can restart the initial process.
|
Describe the bug
I get a "Not in a F# project (Still loading...)" in status bar, but the folder is a dotnet scaffolded .fsproj
Steps to reproduce
Scaffolded a fs project. cd into the directory. Opened it in vscode.
I set up a global.json with net core 5 version installed in my host.
Set net core version 5 in .fsproj
Set the dotnet variable from settings
Set path env var ordered first to the dotnet core path
Expected behaviour
Ionide should recognize this fsproj
Screenshots
Machine info
Additional context
Full F# Output
The text was updated successfully, but these errors were encountered: