search

fsprojects / IfSharp

F# for Jupyter Notebooks
Other
440 stars 71 forks source link

"netstandard not found or is invalid" #213

Closed dsyme closed 5 years ago

dsyme commented 5 years ago

Description

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

image

Steps

On windows (or equivalent on linux)

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

Expected: no errors

cgravill commented 5 years ago

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:

image

cgravill commented 5 years ago

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

image

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.

rudihorn commented 5 years ago

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

rudihorn commented 5 years ago

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.

cartermp commented 5 years ago

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.

rudihorn commented 5 years ago

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

cgravill commented 5 years ago

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

dsyme commented 5 years ago

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.

cgravill commented 5 years ago

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?

gusennan commented 4 years ago

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:

image

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

cgravill commented 4 years ago

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