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

Activity

1. dsyme commented on Jul 4, 2016

   

   dsyme

   on Jul 4, 2016

   Contributor

   More actions

   The workaround is to add

   #r "System.Threading.Tasks"
   

   to your script.
2. dsyme

   added

   Bug

   Impact-High(Internal MS Team use only) Describes an issue with extreme impact on existing code.(Internal MS Team use only) Describes an issue with extreme impact on existing code.

   Area-Debugstepping, debug points, stacks and morestepping, debug points, stacks and more

   on Jul 4, 2016
3. dsyme commented on Jul 4, 2016

   

   dsyme

   on Jul 4, 2016

   Contributor

   More actions

   Thanks for this repo. This is actually a really important bug to fix since the workaround is basically impossible to determine without the fix.
4. smoothdeveloper commented on Jul 4, 2016

   

   smoothdeveloper

   on Jul 4, 2016

   ContributorAuthor

   More actions

   @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.
5. isaacabraham commented on Jul 4, 2016

   

   isaacabraham

   on Jul 4, 2016

   Contributor

   More actions

   Is this the one that is due to the Tasks BCL / extension assembly?
6. dsyme commented on Jul 4, 2016

   

   dsyme

   on Jul 4, 2016

   Last edited by dsyme

   Contributor

   More actions

   @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.

   👍React with 👍1Reacted by Isaac Abraham
7. dsyme

   added

   Ready

   on Jul 5, 2016
8. dsyme

   closed this as completedon Jul 21, 2016
9. kflu commented on Aug 27, 2016

   

   kflu

   on Aug 27, 2016

   More actions

   @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
10. smoothdeveloper commented on Aug 28, 2016

    

    smoothdeveloper

    on Aug 28, 2016

    ContributorAuthor

    More actions

    @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.