FSX in Visual Studio has design-time issues with netstandard

[0x53A]

Everything works at run-time (using fake as the host).

Repository here: https://github.com/0x53A/visualfsharp-issue-5216

1. "dotnet restore"
2. "dotnet fake run" (it won't do anything because the default target is empty, but is needed to restore all packages)
3. open build.fsx in Visual Studio

issues:

1. without referencing netstandard.dll manually, everything is red.

2. with referencing netstandard.dll manually, there are two errors:

#if !FAKE
#r @"C:\Users\rieluk\.nuget\packages\netstandard.library\2.0.3\build\netstandard2.0\ref\netstandard.dll"
#endif

Version:

[cartermp]

Not sure if it's related, but why is it using .csproj?

[0x53A]

that's just the bootstrapping part - you need to get the fake dotnet tool from somewhere, and using a dummy csproj is the easiest way to aquire it.

[matthid]

Btw this was reported to fake as well: fsprojects/FAKE#1938
@0x53A thanks for reporting it here, because I'm kind of lost on this. This is in fact a problem for paket as well (load script generation, which is basically what FAKE is using here).

Question is:

• Does paket need to detect if a package depends on netstandard and insert a framework reference to netstandard?
• Does paket need to reflect on assemblies and figure this out?
• Do packages need to use framework references?
• Should we just always add #r "netstandard" at this point?
• Does the IDE need to do something?
• Anything else?

I don't think it is in fact an IDE problem. But I'm thankful on any information about this, especially how you are supposed to properly reference netstandard as #r "netstandard" doesn't seem to be portable (on mono), see ionide/ionide-vscode-fsharp#839

[matthid]

Also don't get confused by the fact that fake can run the script. This is because we load all assemblies "by hand" and therefore all #r lines are in fact not required by fake at all.

[0x53A]

Does paket need to detect if a package depends on netstandard and insert a framework reference to netstandard?

I don't think so.

I had to wrap it in !FAKE, because unconditional reference would make it succeed in the idea, but fail at runtime.

I can try more things later, currently on mobile

[matthid]

I don't think it is in fact an IDE problem

Or to be more exact: I have no idea. Question is are you supposed to reference netstandard by hand? And if yes why is #r "netstandard" not working on mono for example. (Recently I had reports where it didn't work on windows either and we had to use the full path to the nuget package - though we couln't figure out the root cause yet).

@cartermp can you try to figure out an answer to that? How can we see netstandard? Should it be ootb available if the framework supports it or referenced manually (in the context of .fsx).

[cartermp]

What if you use #r "NETStandard.Library? At least that's the name of the package with all the references. Just a shot in the dark.

Since FSI has no concept of .NET Standard today, it wouldn't surprise me that you'd need to hand-reference everything it yourself. And there's no built-in editor support for understanding it for, e.g., a .fsx file sitting at the solution level. So it wouldn't surprise me that you need to reference the .dll yourself.

[matthid]

@cartermp Yes sadly if it would be a "proper" package it would already work ootb just fine, but for some reason they don't use regular nuget references for this particular package. In fact they use msbuild trickery:

This strongly suggests that everyone in the ecosystem needs to "special case" that reference (including tooling!). Therefore it would be neither a paket nor a fake bug (imho).

[cartermp]

What I think that this implies is that msbuild is the source of truth for interactive tooling that needs to understand this reference. Which puts the ball in our court for the FSI work.

The spec isn't written beyond a quick push of a summary so I don't lose my work. Details of what goes into each involves, among other things, ripping out direct dependencies on older MSBuild versions throughout the codebase. It's fuuuuunnnnn 🙄

[matthid]

@cartermp Just to be on the same page: This issue has nothing to do with fsi on netcore. In fact this hit regular tooling on full framework scripts.

Fake basically writes a script (via #if !FAKE) that should be compatible with the full framework and full framework tooling but apparently it is not because we are missing something.

Do you think it is a good idea if we workaround this by referencing netstandard.dll automatically in the file generated by fake or will that break once this issue is fixed? (or can you ping someone who can answer this)

[cartermp]

What I mentioned also affects desktop FSI - there is no understanding of .NET Standard and it needs to be built.

I think that netstandard.dll is a decent workaround, as I don't suspect that this packaging will change. Things may need to change for FAKE once the full FSI work is completed, though.

[matthid]

I thought about adding this to paket load script generation feature (as that is where this issue is basically rooted). But I guess this netstandard.dll is a reference assembly so I guess this will break runtime for regular scripts. So I guess I will have to add a hack to fake and wait for the fix for the general case.

But I'll probably do some testing before changing anything

[0x53A]

Please note that even adding netstandard.dll doesn't fix everything @cartermp

[cartermp]

I wouldn't expect it to. This is workaround territory until we complete the FSI work.

[0x53A]

I fixed the remaining design-time issues by:

1. building an unrelated net461 project referencing any ns2 component.
2. Taking the netstandard.dll from that build output and referencing it instead of C:\Users\rieluk\.nuget\packages\netstandard.library\2.0.3\build\netstandard2.0\ref\netstandard.dll.

The issue was that the \ref\ version I referenced first didn't contain the type-forwards and so didn't unify the types.

I don't think that version of netstandard.dll is published anywhere on nuget (at least I couldn't find it), so it may be best to bundle it with FAKE?

[matthid]

If it's not already part of it I'm probably not doing that

[auduchinok]

Probably adding a directive specifying target framework id would help.
Something like #target "netstandard2.0" could work.

[haf]

What's the solution to this on macOS @cartermp?

[cartermp]

@haf If you require scripting with a .NET Standard component today, you'll need to apply a hack. I'm not sure how to do it for Mono, but if you build a temporary F# project that ultimately references the binaries you want to reference in a script, you can reference the binaries from that build output.

Otherwise, you'll just have to wait until FSI fully supports referencing .NET Standard components.

[haf]

@cartermp I have many projects targeting netcoreapp2.1 and the like. However, even if I do, their publish/ folders don't seem to contain anything that makes it better to ref. Also, directly referencing #r "netstandard" doesn't change the squigglies in Rider.

[cartermp]

I think there are two issues at play here, then:

1. Lack of proper .NET Core support, so it's not clear what should be referenced (nothing should actually be referenced in a script, just like "normal" scripting on .NET Framework and Mono)
2. Lack of editor support for referencing NETStandard.Library at design-time.

The latter can't feasibly be done without also having the proper FSI package support, since making a given editor scrounge for magical .dlls isn't really a tenable solution.

I would think that referencing a project that references the correct binaries should work through transitive references, though.

[cartermp]

We've now concluded what we feel are the major blockers towards "as-is" support for FSI on .NET Core. A version should be available in the .NET Core 3.0 Preview 5 release - though @KevinRansom can confirm this more concretely.

I think the overall issue has subsided significantly:

• FSI in VS 2019 targetst net472, which natively understands/supports .NET Standard 2.0 and components that target .NET Standard 2.0
• dotnet fsi via the .NET Core 3.0 SDK calculates the correct default set of references and no longer has issues with finding correct referenced dependent assemblies (see FSI packaged with 3.0.100-preview3-010431 throws "Could not load file or assembly" exception while executing Hopac job.  #6337)

However, there are two remaining pieces to finish up:

• Package management such that packages are the artifact being referenced from a user's and tool author's perspective
• VS editor hookups to let you do things like use .NET Core-only types such as Span<'T>

The latter is probably best to work on once the former is finished. It's kind of moot to track it at this point since we won't be working on that until FSI proper is fully fleshed out and ready for us to cut it as a supported release.

[cartermp]

Another update to this - package references are in. The only remaining hurdle is allowing for .NET Core-based scripting within VS.

[cartermp]

So far, yes

[yamen]

Is anything tracking the related issue of red lines etc in the file editor for FSX files? Scripts work fine in the net core scripting FSI window, but broken in editor.

[dsyme]

Use 16.9 preview and turn on .NET Core script editing in F# options

[yamen]

I did do that, FSI itself works fine but not the FSX display. I had to make the file a .fs file and that cleared the issues. So I’m just doing that and marking it as non compiled.

[cartermp]

@dsyme I think this is related to the isssue you fixed a little while back. That will not be in the 16.9 release, it will have to wait until 16.10.