FSC not working with new msbuild based dotnet core
Banashek opened this issue · 50 comments
I know all these new dotnet core build-types (project.json, msbuild) are a pain, but I figured I would log the issue here for visibility.
In a new msbuild-based dotnet core project, the fsc component doesn't seem to be able to locate the restored nuget packages.
example fsproj:
<Project Sdk="FSharp.NET.Sdk;Microsoft.NET.Sdk" ToolsVersion="15.0">
<PropertyGroup>
<OutputType>Exe</OutputType>
<TargetFramework>netcoreapp1.1</TargetFramework>
<Version>1.0.0-alpha</Version>
<EnableDefaultCompileItems>false</EnableDefaultCompileItems>
</PropertyGroup>
<ItemGroup>
<Compile Include="App.fs" />
<EmbeddedResource Include="**\*.resx" />
</ItemGroup>
<ItemGroup>
<PackageReference Include="Suave" Version="2.0.0" />
<PackageReference Include="Microsoft.FSharp.Core.netcore" Version="1.0.0-alpha-161205" />
<PackageReference Include="FSharp.NET.Sdk" Version="1.0.0-beta-*">
<PrivateAssets>All</PrivateAssets>
</PackageReference>
</ItemGroup>
<ItemGroup>
<DotNetCliToolReference Include="dotnet-compile-fsc">
<Version>1.0.0-preview2-020000</Version>
</DotNetCliToolReference>
</ItemGroup>
</Project>
Example file with incorrect syntax errors:
open Suave
open Suave.Files
open Suave.Filters
open Suave.Logging
open Suave.Operators
open Suave.RequestErrors
open Suave.Successful
open System
open System.IO
open System.Net
let app =
choose [
path "/" >=> Files.browseFileHome "index.html"
path "/bundle.js" >=> Files.browseFileHome "bundle.js"
>=> Writers.setHeader "Cache-Control" "no-cache, no-store, must-revalidate"
>=> Writers.setHeader "Pragma" "no-cache"
>=> Writers.setHeader "Expires" "0"
NOT_FOUND "404 - Not found."
]
let serverConfig =
{ defaultConfig with
logger = Targets.create LogLevel.Debug [||]
homeFolder = Some (Path.GetFullPath "./public") }
[<EntryPoint>]
let main argv =
startWebServer serverConfig app
0
Error on line 0 (open Suave) The namespace or module 'Suave' is not defined.
For reference: it does work properly in ionide-vscode. Not sure if there is an FSC update that hasn't been applied or if there is more code involved.
I'll do some investigation today and update what I find here.
Although there is an open issue in FSAC ionide/FsAutoComplete#137 , somehow it's currently working in ionide-vscode. I asked in the channel how it works (maybe fsac updated for msbuild projects without mentioning it) in their gitter channel and am awaiting a response.
It hasn't quite forked, the changes come back to the main repo periodically, but some are in the form of features that the other editors haven't taken advantage of, or perhaps need to upgrade to a new release of FSAC to use, or perhaps I haven't released a new version of FSAC containing them.
New project support is already merged in main FSAC - https://github.com/fsharp/FsAutoComplete/blob/master/src/FsAutoComplete.Core/Commands.fs#L94-L148 - and it's just modification of command used previously... so it's just matter updating it here / releasing new version in fsharp/FSAC repo
Actually it looks like https://github.com/fsharp/FsAutoComplete/blob/master/RELEASE_NOTES.md has 30.10.2016 as the last update, and the change mentioned above was added after that https://github.com/fsharp/FsAutoComplete/blame/master/src/FsAutoComplete.Core/Commands.fs#L103 .
Thanks! I'll check tomorrow and pr the version bump after.
Awesome, thanks @rneatherway - we may need to make a further change here if the project filename is different in the brave new world.
Thanks @rneatherway
@kjnilsson The new core stuff still uses .fsproj, the format is just changed ( a lot cleaner )
Interestingly, with the new version of FSAC, it doesn't give any errors at all.
I thought it was working because the import errors went away and t seemed to behave properly if the correct modules were opened or not, but it seems it's just switched from errors on every open module to no errors for anything.
It's at least partially working, in that it's resolving the nuget libraries correctly now.
I'm assuming that by enabling logging you mean setting let g:fsharpbinding_debug = 1 and inspecting the output of those files. I don't seem to have any logfiles created however.
The odd thing is that autocompletion is actually working. Maybe I need to dig deeper into the code but I thought that completion was provided by FSAC.
Is there a way to test whether fsac is running or not other than the debugger outputting log files?
you can check if the mono (or .NET) process is running but if autocompletion is working and debugging is enabled there should be output.
Vim is definitely starting mono and autocompletion is working, but still no log files, even after making changes that should definitely cause errors.
I've checked /tmp/, ~/tmp/ and ./tmp/ just to be sure and none of them contain anything. I'll try reinstalling the plugin, making sure it works before the version bump, and then bumping the version again to see if the version bump is what's causing it, or if it's just my installation for some reason.
No output with fsac 0.30.0 either. Maybe the logging issue is a neovim incompatibility?
The logging is just file write from the python code so that sounds a bit weird. I will try to test your PR myself and dig around a bit.
Ok it seems the response data format changed in this version of fsac which I've fixed. The problem that remains is that it doesn't appear able to resolve my 3rd party nuget reference correctly when parsing the project so it complains about a missing reference even though the project itself builds ok. Any ideas @rneatherway @Krzysztof-Cieslak ?
We talk about normal fsproj or "new" (MsBuild 15) one ?
"new" ones I believe. created using the latest dotnet core rc thingee.
Enrico implemented this part in FSAC, so I'll ping him
CC: @enricosada
I've worked it out and linked a PR to FSharp.AutoComplete that should fix it for, hopefully, everyone.
FSAC should be initialize with the obj\dotnet-compile-fsc.rsp generated after dotnet build.
Atm that works for both project.json and msbuild15 based.
Watch that file for changes, if you want to reinitialize FSC when compile items, packages are added, so FSAC stay in sync (but is touched each build, so check content).
the code for ionide is there https://github.com/ionide/FsAutoComplete/blob/0aac468dabb0797ac3ae81d1cec75ba135e2c076/src/FsAutoComplete.Core/Commands.fs#L104-L152
Pratically the contentn of response file should be used to initialize the FSAC.
A note: to check if a fsproj is new (msbuild15) or old, just check if exists Sdk attribute, like <Project Sdk=
as a note, any issue with f#, please open an issue in https://github.com/dotnet/netcorecli-fsc
New release of FSAC is up: https://github.com/fsharp/FsAutoComplete/releases/tag/0.31.1
@Banashek I've merged your changes with a few updates. It works for me now. Can you check lastest master and confirm (you need to run make clean && make
thanks for the swift release @rneatherway !
Awesome! Thanks for the help all!
I am still having this exact issue, 'module is not defined', even though the project builds without error. I am using the latest dotnet core version with .fsproj-files.
I have tried updating fsautocomplete manually and running make clean && make and I have also removed and reinstalled vim-sharp from scratch.
Is there anything else I need to do for this fix to work?
yes me too - it seems to be due to some changes in the latest version of the tooling. @enricosada describes a workaround in ionide/FsAutoComplete#137 which may or not work. That issue is still active and it looks like an update to fsautocomplete is in the works.
I think 0.31.1 doesn't include support for latest version of sdk / project file, it's only supported in Ionide's fork but is still not super stable, so I'm waiting for the fix before we merge it to main.
Ok thanks for the update @Krzysztof-Cieslak - are there any issues/PRs we can link to this issue that we haven't already?
@enricosada's PR that added support to latest version is here - ionide/FsAutoComplete#55, some discussion about problems with it is also happening there.
@kjnilsson the work for support msbuild is done (some bugs, but are specific scenarios, and fix is wip or exists workaround). it's usable.
I described how to support new fsproj, and updated progress (now is done) in fsharp/fsharp-compiler-docs#705 (comment) (i know is wrong repo, my bad)
Pratically we need to merge ionide's fork in fsharp/FsAutocomplete and release a new version.
All the changes required are in FsAutocomplete (not FCS)
@viktorvan @Banashek if you install with make git now (until the next fsac release) it should work.
After running make git the plugin is broken form me. It does not detect syntax errors and sometimes crashes. For example when running the type-checking command:
Error detected while processing function fsharpbinding#python#TypeCheck:
line 14:
Traceback (most recent call last):
File "", line 2, in
File "/Users/viktorvan/.vim/plugged/vim-fsharp/ftplugin/fsharpvim.py", line 147, in parse
self.send("parse "%s"\n" % (fn))
File "/Users/viktorvan/.vim/plugged/vim-fsharp/ftplugin/fsharpvim.py", line 106, in send
self.p.stdin.write(txt)
IOError: [Errno 32] Broken pipe
Running make clean && make fixes the crashes for me, but then I am back to getting 'module is not defined'-errors.
I've released FSAC 0.32.0 today, which may help. At least it is a stable version now.
I am afraid the plugin still isn't working for me. For dotnet core projects with .fsproj-files I am still getting "module 'xxx' is not defined" errors.
Restoring and building did not help me with my current netcore project, but I created a fresh project using 'dotnet new' and the restored and built the project and then it works fine!
It will not work, though, if I scaffold a new dotnet core project using these yeoman aspnet-generators (https://github.com/OmniSharp/generator-aspnet).
But I can live with that.
@viktorvan yes, i just checked yo aspnet, and these templates are obsolete (global.json use an rc4 version of dotnet sdk). the f# tempaltes are of rc version too.
Afaik yo aspnet is now replaced by dotnet new scaffolding, but maybe is useful for someone.
@viktorvan do you have any interest in update these maybe?
Just using the same fsproj as dotnet new console -lang f# or dotnet new mvc -lang f# will do.
No, I don't really need the yeoman aspnet generators, dotnet new will work just fine for me.
Thank you for verifying that the issue was in the generators.
Ok I'm going to close this now as the original issue is addressed.