Full FSI support on .NET Core 2.0

[dbettin]

From #2400

Properly handle the model for how .dlls are laid out on disk with .NET Core, thus fixing #r
Establish a good working model for how to do the above
Prompt to re-load an FSI session when #r’ing an assembly that targets a higher target than what FSI was launched with?
Error message asking user to re-load FSI manually?
Try to re-target and re-reference everything on the fly?

[KevinRansom]

@dbettin it's like you are channeling my nightmares today. Assembly reference and loading in a coreclr world requires a lot of thought too. FSI was and to a lesser extent the desktop FSC were very helpful in finding and resolving assemblies ... at the price of a lot of determinism.

It's a goal we need to fix by the time .NetStandard 2.0 is released. The details however, are not yet available.

[dsyme]

My comment from the fsharp-opensource mailing list:

There’s been progress – we’ve had variations on this working – but there’s a strong feeling that we need to get “#r on a nuget package” designed, implemented and finalized before the experience will be correct and stable for both .NET Core and .NET Framework. See also #2483

[KevinRansom]

Support for FSI on dotnet core.

Yes it will happen absolutely. That it hasn't yet, is extremely embarrassing to me. The reason is technical, rather than priorities or anything else. Well priorities have been impactful ... but they are not the main reason.

The issue is this: we test fsi.exe on coreclr and have done for a long ... long time, and it works well. Unfortunately ... (and this is the embarrassing bit) it relies on a bug in the coreclr to work ... in AssemblyLoadContext. If we fix the code to what we need it to be now that the bug is fixed in the coreclr, the entire way we test the coreclr build needs changing. This is the exact same reason why we still rely on project.json in our build.

I fully understand the irony of what I just said above ... if we fix the bug we can't test it ... if we don't fix the bug we can't ship it. I hate myself for this ... and if you want to expose me to the universe for the full idiocy of the position I just expressed I know how insane it is.

We must fix our build ... we must fix the testing ... I promise it will happen ...

I actually prefer Don's explanation, because coreclr FSI without built-in package management is definitely going to require external packagement to make scripts that reference libraries reliable.

However, in reality releasing fsi is not gated on adding packagemanagement it is gated on us digging out of a historic build/test mess that I created for us.

I am truly sorry about that.

Kevin

[forki]

What annoys me personally is that we bundle both things. We could already have a nice package management story in classic fsi and could make HUGE progress on FAKE 5. But we wait for netcore.... Am 01.09.2017 9:52 nachm. schrieb "Kevin Ransom (msft)" < notifications@github.com>:

…

Support for FSI on dotnet core. Yes it will happen absolutely. That it hasn't yet, is extremely embarrassing to me. The reason is technical, rather than priorities or anything else. Well priorities have been impactful ... but they are not the main reason. The issue is this: we test fsi.exe on coreclr and have done for a long ... long time, and it works well. Unfortunately ... (and this is the embarrassing bit) it relies on a bug in the coreclr to work ... in AssemblyLoadContext. If we fix the code to what we need it to be now that the bug is fixed in the coreclr, the entire way we test the coreclr build needs changing. This is the exact same reason why we still rely on project.json in our build. I fully understand the irony of what I just said above ... if we fix the bug we can't test it ... if we don't fix the bug we can't ship it. I hate myself for this ... and if you want to expose me to the universe for the full idiocy of the position I just expressed I know how insane it is. We must fix our build ... we must fix the testing ... I promise it will happen ... I actually prefer Don's explanation, because coreclr FSI without built-in package management is definitely going to require external packagement to make scripts that reference libraries reliable. However, in reality releasing fsi is not gated on adding packagemanagement it is gated on us digging out of a historic build/test mess that I created for us. I am truly sorry about that. Kevin — You are receiving this because you are subscribed to this thread. Reply to this email directly, view it on GitHub <#2407 (comment)>, or mute the thread <https://github.com/notifications/unsubscribe-auth/AADgNE-0l8H-ykoQUvECZk7xge5hYyzaks5seGCagaJpZM4L90AM> .

[KevinRansom]

I haven’t bundled both things. I’m saying, and I think quite clearly, that my stupidity on the build and test is what is blocking this. Fixing the build and test will enable FSI. Good Package management in FSI will make the world pretty groovy. Kevin KCR: Edited to remove email quote.

[matthid]

@KevinRansom I just really wanted to write that I appreciate and value your response. While I can see that this is embarrassing it feels like honesty is really a good way forward for this repository.

Too often (and maybe even only for historical reasons) we feel like there is some hidden agenda or political reasons behind stuff. So this really helps a lot. Thank you.

About what @forki said: I think a response on the other issue regarding the latest suggestions from the community might help.

[dsyme]

Unfortunately .it relies on a bug in the coreclr to work ... in AssemblyLoadContext.

I wasn't aware of this. Do you have a link to the bug for this? Thanks. Also a link to the place in the F# code where we are relying on this. Full transparency please :)

[KevinRansom]

The bug is in how you implement load contexts. What we do in FSI results in a stack overflow on bug fixed coreclr’s. The fix looks like this: https://github.com/Microsoft/visualfsharp/pull/3140/files#diff-3229c72e3fbd323c1dde9692aceedd65L322 It was part of PR to basically enable FSI on netstandard 2.0. However, work you and I have done superseded this PR, apart from this little bit.

[matthid]

Just to add: The runtime people suggested to me to use my own assembly load context (as I was hitting some similar issues with FAKE at the time), since I have done that the code and the loading logic feel a lot "cleaner".

Technically, this also fixes a lot of outstanding problems in FAKE like that you cannot use a different fcs version in your script code (for example when using fsf).

So maybe this should be something to consider. But yeah especially for fcs this might be breaking as existing users might depend on having the same set of assemblies available in the script code as in the host code.