Intellisense stops working in .fsx script (due to issue loading list of assembly references correctly?)

[smoothdeveloper]

Repro steps

1. clone https://github.com/smoothdeveloper/fsharp.playground
2. checkout commit 1aae8afd63cf0fa048a1074a95290484a26eb877
3. run build.bat (restores all nugets)
4. open smoothdev.Utils.sln
5. open smoothdev.Utils\src\smoothdev.Utils.Azure\Script.fsx file in VS
6. type . and CTRL+SPACE after open Microsoft.Azure

Expected behavior

Autocomplete works

Actual behavior

Autocomplete doesn't work

Known workarounds

I haven't found one

Related information

• Windows 7 x64
• VS 2015 Update 1
• .NET 4.5

[dsyme]

The workaround is to add

#r "System.Threading.Tasks"

to your script.

[dsyme]

Thanks for this repo. This is actually a really important bug to fix since the workaround is basically impossible to determine without the fix.

[smoothdeveloper]

@dsyme thanks, could you describe (if possible) how you figured out that "impossible to determine" fix?

I haven't had chance to look at how this reference / assembly loading from script is all working in F# tooling / FSI, I think first measure would be error reporting with the name of missing reference.

The include scripts are generated by paket and there might be some holes in the logic or missing metadata in nuget packages which lead to that missing System.Threading.Tasks assembly, I'll try to see if there is a bug to report in any of the nuget package to mention that assembly.

In the context of developing that paket feature, we had to put hardcoded workarounds for FSharp.Core (should never load it, even if using the nuget one) and mscorlib (if it is `#r "mscorlib" more than once, FSI complains with an error).

It would be great to throw together few notes (with knowledge of implementation details the visualfsharp team has) about all those concerns related to assembly/reference loading in FSI and tooling.

[isaacabraham]

Is this the one that is due to the Tasks BCL / extension assembly?

[dsyme]

@smoothdeveloper I ran

devenv /debugexe devenv.exe

and looked at the exception when openeing your solution.

I'd debugged this once before, and we've already added a default reference to the DLL mentioned above. However we hadn't fixed the error reporting in the general case so that people would know that they needed to add this

@isaacabraham Yes, more or less. I believe the silent error happens with Visual Studio 2015 whenever an F# script references an F# profile 7, 78, 259 or ,NET Standard 1.x component.

[kflu]

@dsyme Thanks. That works! It puzzled me for quite a while! Where's the documentation for #r? I didn't know you can directly reference the assembly name without the .dll or .exe extension name. I don't see it mentioned here

[smoothdeveloper]

@kflu I think the behaviour is the same as when you give a --reference or what you give in project files, those place can also mention (GAC registered) assemblies just by name.