"netstandard not found or is invalid"

Question

"netstandard not found or is invalid"

dsyme opened this issue 6 years ago · 11 comments

dsyme commented 6 years ago

Description

"netstandard.dll not found or is invalid" is shown

Steps

On windows (or equivalent on linux)

docker run -v %cd%:/notebooks -p:8888:8888 fsprojects/ifsharp
open http://localhost:8888/notebooks/FSharp_Jupyter_Notebooks.ipynb

Expected: no errors

Answer 1 · 2019-03-26T21:06:46.000Z

Note there's some overlap with #206 and @rudihorn has an improve situation via #207

That looks like an error with the error highlighting, what platform are you on?

On Windows I get down to the parallel programming section:

Answer 2 · 2019-03-26T21:09:45.000Z

I'm then able to make a change and do this:

I guess in .NET Core we should be automatically referencing netstandard? I've not tried the experimental .NET Core setup on Windows - working on other things currently.

Answer 3 · 2019-03-26T21:45:35.000Z

Yeah I have noticed that with #207 it is only an Intellisense/highlighting issue but still works.

Answer 4 · 2019-03-27T17:25:21.000Z

A workaround this could be to have a similar workaround as is done to load System.Runtime.dll https://github.com/rudihorn/IfSharp/tree/netstandard. There should be a nicer way of doing this though.

Edit: Seems there are a few libraries which would need to be loaded this way.

Answer 5 · 2019-03-27T20:18:42.000Z

This is just another symptom of the larger problem we're working on solving for FSI on .NET Core. The problem ends up getting deep, as we need to read both facade and implementation assemblies in an interactive process. Implementation assemblies can and will change over time, so you need a separate resolver either in NuGet or the .NET SDK to tell you what implementation assemblies are correct for a given context. Until that is resolved, I wouldn't expect to get further than a hack here.

Answer 6 · 2019-03-27T21:07:37.000Z

@cartermp Might it be worth just determining the currently loaded assemblies and then using those? Thanks for the clarification though!

Answer 7 · 2019-03-28T17:39:46.000Z

Thanks for the caution @cartermp is there an issue we could track around this?

Answer 8 · 2019-03-28T17:48:34.000Z

This is just another symptom of the larger problem we're working on solving for FSI on .NET Core. The problem ends up getting deep, as we need to read both facade and implementation assemblies in an interactive process. Implementation assemblies can and will change over time, so you need a separate resolver either in NuGet or the .NET SDK to tell you what implementation assemblies are correct for a given context. Until that is resolved, I wouldn't expect to get further than a hack here.

We're getting this error on .NET Framework/Mono too, so I don't think it's related. More likely got to do with locating Facades on Mono.

Answer 9 · 2019-05-06T20:16:57.000Z

I think the original issue is resolved via fixes in #218 (which also enables XPlot.plotly and other Paket goodness). Give it a go and re-open if there are issues.

We now default reference netstandard on the netcore build as well. Is there any official guidance if that's the right fix? It seems pragmatically a good idea for compatibility but will silently referencing netstandard bite us later?

Answer 10 · 2019-12-15T02:11:48.000Z

Hi, thanks for this project, it's pretty awesome.

I'm running this the first time on Windows 10 via Docker, using the method referenced in the original issue, and still see this:

It looks like the same issue, not sure if this is a regression.

Answer 11 · 2019-12-24T08:47:18.000Z

@gusennan glad it's useful.

I think there's something not quite right on the code completion for Mono/.NET Core on non-Windows systems. It needs some digging into more deeply. On the plus side while it used to be a blocking error, at least for me it's a fake error which is annoying but can be ignored until someone gets a chance to look at it.