Skip to content
New issue

Have a question about this project? Sign up for a free GitHub account to open an issue and contact its maintainers and the community.

By clicking “Sign up for GitHub”, you agree to our terms of service and privacy statement. We’ll occasionally send you account related emails.

Already on GitHub? Sign in to your account

Add support for .Net Core scripting #466

Merged
merged 11 commits into from
Oct 6, 2019
Merged

Conversation

Krzysztof-Cieslak
Copy link
Member

This is work by me @baronfel to get back good scripting experience in FSAC.

We need to support following case:

  • .Net Framework FSAC - support fsi.exe and use net462 references
  • .Net Core FSAC - support fsi.exe (net462 references) and dotnet fsi (netcoreapp3.0 references). User can choose which one they want to target with UseSdkScripts settings.

Currently some logic around resolving correct set of references is in this PR rather than FCS - dotnet/fsharp#7701

Discussion about FSI support in FSAC - #465

using a set of valid min versions we now look for the highest version that matches a particular version bound we set. Default to 3.0.100 for the SDK and 3.0.0 for the runtime
@baronfel
Copy link
Contributor

baronfel commented Oct 6, 2019

With the latest changes we should be ready to go. To summarize:

  • if the user opts-in to netcore scripts, we:
    • assume a default install location for the sdk (could be easily configured)
    • detect the most up-to-date SDK at least version 3.0.100
    • detect the most up-to-date runtime at least version 3.0.0
    • assume netcoreapp3.0 TFM
    • yield assembly references from the FSharp SDK always
    • yield assembly references from the matching pack directory for that runtime version + TFM

This should be reasonably future-proof while ensuring a minimum standard of support.

I also threaded through the netfx/netcore flag into the background processing/parsing of files, which required a data contract change and looks invasive, but otherwise was pretty mechanical.

This works great for me on OSX, should work similarly on any windows/unix machines so long as the documentation about default install locations is correct. Next steps would be to review/merge, then in Ionide use the user's UseSdkScripts setting to decide if we launch fsi/fsharpi like we do currently, or dotnet fsi.

@Krzysztof-Cieslak Krzysztof-Cieslak marked this pull request as ready for review October 6, 2019 18:59
@Krzysztof-Cieslak Krzysztof-Cieslak merged commit 72a19d2 into master Oct 6, 2019
@Krzysztof-Cieslak Krzysztof-Cieslak deleted the attempt-to-fix-scripts branch October 8, 2019 16:39
Sign up for free to join this conversation on GitHub. Already have an account? Sign in to comment
Labels
None yet
Projects
None yet
Development

Successfully merging this pull request may close these issues.

2 participants