How is IntelliSense supposed to work in FAKE v5?

[inosik]

Description

IntelliSense is not available in FAKE 5 scripts anymore.

Repro steps

• Create a build.fsx file, pretty much as seen in the guides:

  (* -- Fake Dependencies paket.dependencies
  file ./paket.dependencies
  group netcorebuild
  -- Fake Dependencies -- *)
  
  #load ".fake/Fakefile.fsx/loadDependencies.fsx"
  
  open Fake.Core
  open Fake.Core.TargetOperators
  
  Target.Create "Clean" (fun _ -> printfn "Cleaning ...")
  Target.Create "Build" (fun _ -> printfn "Building ...")
  Target.Create "Deploy" (fun _ -> printfn "Deploying ...")
  
  "Clean" ==> "Build" ==> "Deploy"
  
  Target.RunOrDefault "Deploy"

• Create a paket.dependencies file:

  group netcorebuild
  source https://nuget.org/api/v2
  
  nuget Fake.Core.Targets prerelease
  

• Run paket install

• Run fake run build.fsx

• Open build.fsx with any editor that provides F# support

Expected behavior

loadDependencies.fsx contains #rs for all the assemblies FAKE is going to use, and that would enable IntelliSense in the editor.

Actual behavior

loadDependencies.fsx contains nothing but printfn "loading dependencies... ". My script never references any assemblies and the editor of my choice complains about stuff not being defined.

Is this the world we're going to live in now?

Known workarounds

None.

Related information

• FAKE 5.0.0-alpha-10

[matthid]

loadDependencies.fsx contains #rs for all the assemblies FAKE is going to use, and that would enable IntelliSense in the editor.

Yep this is what we will have eventually, it is just not done jet :)

[inosik]

I guess I overlooked this comment in the docs: Use this for IDE support. Not required by FAKE 5. Change "build.fsx" to the name of your script. 😄

Then I have a couple of questions:

• Does it make sense to rename this file to something like intellisense.fsx or idesupport.fsx?
• Will we need to run FAKE once after installing modules, to regenerate this file?

[matthid]

Does it make sense to rename this file to something like intellisense.fsx or idesupport.fsx?

Totally, good idea

Will we need to run FAKE once after installing modules, to regenerate this file?

Obviously as I don't know how else it could work?

[inosik]

Should I make a PR for the rename?

how else it could work?

FAKE could offer an add-module command, which would add modules to paket.dependenciesor the header section, download them and regenerate the import script.

But I hate to bring this up. I like my tools having a single purpose, without tons of layers of redirection, so that nobody knows what the f**k is going to happen when you type a seemingly simple command into the terminal. Looking at dotnet restore.

[matthid]

Should I make a PR for the rename?

Sure :)

FAKE could offer an add-module command, which would add modules to paket.dependencies or the header section, download them and regenerate the import script.

But I hate to bring this up. I like my tools having a single purpose, without tons of layers of redirection, so that nobody knows what the f**k is going to happen when you type a seemingly simple command into the terminal. Looking at dotnet restore.

I know that's why I haven't decided anything yet. I did not come up with any convincing idea. Deep and loose paket integration have both pros and cons. For some technical reasons a deep (via paket.core api) integration was a lot simpler to start with. Sorry, I don't have a better answer for now.

[inosik]

PR at #1594.

[quezlatch]

Hi,

I have a question, which i think is connected with this. The start of my Fake file is this:

(* -- Fake Dependencies paket-inline
source https://nuget.org/api/v2

nuget Fake.Core.Targets prerelease
nuget Fake.Core.Tasks prerelease
nuget Fake.Core.Tracing prerelease
nuget Fake.Core.Globbing 
nuget Fake.IO.FileSystem
nuget Fake.DotNet.MsBuild
nuget Fake.DotNet.NuGet
nuget Fake.DotNet.Testing.NUnit
nuget NUnit.ConsoleRunner
-- Fake Dependencies -- *)

#load "./.fake/build.fsx/intellisense.fsx"

//manually add references
#r @".\.fake\build.fsx\packages\Fake.Core.Targets\lib\netstandard1.6\Fake.Core.Targets.dll"
#r @".\.fake\build.fsx\packages\Fake.Core.Tracing\lib\netstandard1.6\Fake.Core.Tracing.dll"
#r @".\.fake\build.fsx\packages\Fake.Core.Globbing\lib\netstandard1.6\Fake.Core.Globbing.dll"
#r @".\.fake\build.fsx\packages\Fake.IO.FileSystem\lib\netstandard1.6\Fake.IO.FileSystem.dll"
#r @".\.fake\build.fsx\packages\Fake.DotNet.MsBuild\lib\netstandard1.6\Fake.DotNet.MsBuild.dll"
#r @".\.fake\build.fsx\packages\Fake.DotNet.NuGet\lib\netstandard1.6\Fake.DotNet.NuGet.dll"
#r @".\.fake\build.fsx\packages\Fake.DotNet.Testing.NUnit\lib\netstandard1.6\Fake.DotNet.Testing.NUnit.dll"

am i correct in thinking this is currently required, as intellisense.fsx is currently hardcoded?

[inosik]

intellisense.fsx should already contain all these references, so I think you don't need those #rs in your script.

[quezlatch]

that's what i thought would happen originally, but the contents of my intellisense.fsx is:

// This file is needed for IDE support
printfn "loading dependencies ..."

also, fake run needs the #r section as well

[matthid]

no fake run doesn't need it (at least it shouldn't)

[inosik]

When I did #1594, I added a comment to the docs that this file currently does nothing. But somehow I can't find the page on the website right now.

[matthid]

intellisense will contain the "#r" lines eventually. It's just work to do. And yes the file is basically only required for intellisense

[matthid]

About the note. sorry I might have removed it because I'm positive that this will be fixed somehow before the actual release. I just haven't figured out the details or have found the time to just do it... So I don't want to accidentally release with the note

[inosik]

@matthid It's still there, in help/markdown/fake-fake5-modules.md.

[quezlatch]

@matthid definitely see compile errors when I fake run without it. I installed via chocolatey if that helps...

[matthid]

Related ionide/ionide-vscode-fsharp#558

[matthid]

The script is now called intellisense.fsx but basically this should soon work with beta011 (#1763). While the related issue is not solved we emit the references required for the full framework (and get intellisense this way). Technically this is not completely correct as we execute the script in a netcoreapp2.0 environment. But it is better than nothing.