reference System.Runtime in scripts

[dsyme]

This fixes #381

When referencing a PCL assembly that has an ExtensionAttribute (or auto-opens namespaces that reveal methods with this attribute), we need to be able to resolve the assembly System.Runtime, which needs to be in the reference set. If it's not, a serious error happens internally.

Adding System.Runtime to the default assembly references is safe because we assume at least .NET 4.5 when running this toolchain, which has this DLL available.

I'm doing some manual testing on this and will now explore whether we can add an automatable test.

[dsyme]

@latkin Let me know what you think about this fix and if you might be able to try it out. I haven't tried it yet in the actual IDE.

Here's a repro - just open a.fsx in /~https://github.com/dsyme/bucket/blob/master/repro.zip. If intellisense appears for "map" then it's fixed.

You have to build Visual F# Tools to test it. For an automated test we would need to add a PCL portable DLL to the LanguageService unittests. The repro above just uses a already compiled DLL. If the fix appears to work we could go ahead with adding an automated test.

[latkin]

Makes sense, I agree it should be safe to add this as FSI will always be running on high enough .NET version. I can add a quick test before merging this.

Can this have a meaningful perf impact, particularly for fsc.exe? It looks like System.Runtime is just a bunch of type forwarders, but it worries me to increase the space of referenced-by-default stuff that needs to be considered.

Are there other assemblies from the portable menagerie where we're likely to bump into the same problem? System.Runtime seems like the most fundamental guy to add first.

[dsyme]

There should be no significant perf impact - this only affects the default reference environment for scripts and "out of project" files. For fsc.exe from Visual Studio "--noframework" is always used - in many cases like Portable the (large) set of framework references is added by default by MSBuild.

I think the problem of disappearing intellisense only occurs for "load-critical" attributes like Extension and other type-dereferences that happen when "cracking" an assembly. I'm not certain but I suppose these attributes are mostly in System.Runtime inn the .NETCore programming model.

BTW the underlying structural problem in the VFT code code is that the BackgroundChecker object constructor fails in these circumstances and that failure leaves things horked. This problem was fixed in FCS so that the exception is remembered and replayed when files in that project are checked, which would surface the exception (if FCS were being used by the Visual F# Tools).

[latkin]

Maybe our tests will be the only party affected, as we spawn thousands of compiles without --noframework 😆

I'll try to test this out and get it merged soon.

[latkin]

@dsyme I tried your repro script/DLL in the IDE, it works fine now

[latkin]

Why does this only affect the IDE stack? I see that consuming extension members from script works OK already when running from the command line, it's only intellisense that falls down.

[latkin]

Gahh, sorry @dsyme I forgot to patch the git author on this

[dsyme]

IIRC it's because fsi.exe resolves from the GAC or loaded assemblies as a last resort

[dsyme]

Hi @latkin

Could we check a scenario w.r.t. this fix please? In particular I've been using the .NET Bio library, which is a PCL library, specifically nuget package NETBioCore.PCL 2.0.141118. I was using it from VS2013 like this:

let bacteriaTemplate = "ftp://ftp.ncbi.nlm.nih.gov/genomes/Bacteria/{0}/{1}.gbk"
let accession = "NC_002182"
let folder = "Chlamydia_muridarum_Nigg_uid57785";
let url = String.Format( bacteriaTemplate, folder, accession )

let downloader = new WebClient()

let  stream = downloader.OpenRead( url )
let reader = new StreamReader( stream )
let parser = new GenBankParser()
let sequence = parser.Parse(stream) |> Seq.head

On the last line it asked me to add a reference to System.Runtime. I did this by adding

#r "System.Runtime"

To my surprise this came back with a GAC resolution to a 4.0.0.0 assembly:

--> Referenced 'C:\windows\Microsoft.Net\assembly\GAC_MSIL\System.Runtime\v4.0_4.0.0.0__b03f5f7f11d50a3a\System.Runtime.dll'

However what was even more disturbing was that it then asked me to add a reference to the PCL facade assemblies System.IO, and later System.Collections:

#r "System.Runtime"
#r "System.IO"

and these were also resolved to GAC-installed 4.0.0.0 assemblies.

Two things concern me here

• Is our fix here only partial, i.e. do we need to be adding System.IO, System.Collections and all the other façade assemblies to the automatically-referenced set? (the fix we made does correct the basic problem of intellisense just dying without an error, it's just that additional somewhat surprising references need to be added)

• Is VS2015 resolving the System.Runtime reference from the GAC? (i.e. the reference we've added in this bug fix, and perhaps other façade assemblies too)?

  If so, are there any risks in resolving this assembly from the GAC? Should we seek to instead add the path to the canonical PCL profile assemblies to the set of resolution path used in ReferenceResolution.fs? What would that path be, e.g. is it C:\Program Files (x86)\Reference Assemblies\Microsoft\Framework\.NETFramework\v4.5.2\Facades?

Cheers
don