standalone F# compiler and interactive, in windows store or standalone.

[smoothdeveloper]

In Windows Server Administration context, or Windows Home context, there is value in having Python in Windows Store, for Microsoft.

I face situation where deploying the F# Interactive which runs the best, all libraries (especially Type Providers), on Windows, is still fsianycpu.exe.

I can install latest python with a 1 click in Windows Store.

I could install F# toolkit with 1 "click next till click finish" but only for an older F# version.

I can't do this with recent F#, I can't get type providers and some libraries that works on .net framework only to work with dotnet sdk.

My feature request is to have either F# standalone toolkit, or a 1 click windows store install of F# toolkit that works the same as Python.

Microsoft still has incentive to keep Windows Server and Windows Home running, and to have their most robust and simple, language, with pythonic feel but none of the dynamic typing by default issues, that is F#, running the best on Windows Server to Home.

Please carry this to Satya if needed, I am just trying to help with stuff at my workplace, where F# scripting, on Windows, fits a better role than Python and Powershell, when things start from a bit of scripting, and ends into big systems.

This will also establish F# as a better VBScript for the generations to come (and thankful it wasn't reason for F#, because such reason failed SVN/CVS and C#/Java).

Thank you Microsoft, for all the innovation.

[vzarytovskii]

It's probably a question for the SDK, since right now the compiler and interactive both depend on SDK and runtime, and will only make sense to distribute them together.

[baronfel]

The SDK should be available on Winget, so installation should be a one liner!

Some more details can be found at this announcement, but I haven't tried myself since this announcement.

[smoothdeveloper]

@vzarytovskii thanks for the feedback!

Right now, my work around, but I can't do more than do it where I am stuck, is to extract subset of VS install, until F# works, due to the things you mention, this kind of reverse engineering enforced on all people who keep Windows and .net framework things running rather than rumbling, is not doing best service to Microsoft, IMHO.

@baronfel thanks! can you confirm it is .net framework and not dotnet sdk, version of F#?

F# historically has been better to keep .net framework support with language updates, etc. than C# and VB.NET, I wish Microsoft could keep this going, because I'm sure the SDK part that is in Visual Studio can deterministically come as standalone.

We are still far from Visual Studio running solely on dotnet sdk, right?

[baronfel]

I'm speaking specifically about the .NET SDK, so not .Net Framework.

[KevinRansom]

FSI and FSC depend on the sdk for references. So a stand alone version of either is not going to work great. The desktop compiler is going to be going away eventually, stripping it out of VS and copying it around the machine is not a supported or tested scenario. It may work now, it may not work in the future, and to be clear ... I don't believe they are licenced as redistributable components.

[KevinRansom]

The tool for installing visual studio compilers without all of vs is to use the Visual Studio BuildTools sku, that installs, the necessary compilers, libraries and sdks to ensure that everything works the way it is expected and tested to work.

[smoothdeveloper]

@KevinRansom thanks, I am not sure this gives the leanest deployment (compared to the standalone version of older F# version) but thanks, I think this fits the bill and confirmation.

It is a bit sad it isn't in Windows Store like Python :)

Closing, and thanks everyone for the attention and help.

[smoothdeveloper]

Adding a comment here, at my workplace we have a .NET API for clients using our product, this API allows to perform task programatically such as updating data, running a simulation, extracting reports, etc.

Right now, giving support to end users (who are not software engineers), in context of Visual Studio tooling, with things like setting up a C# or VB.NET project, pick the right target platform, having them update their project configuration files on each release due to binding redirects, adjusting with .net versions, is something hurting the adoption of our API into more places (where there are no software engineers).

I do feel improving the end user story in terms of deploying F# interactive for those use case has tremendous value to the customers using the API, but also for F# adoption in business setting relying on Windows (sole platform where our product runs).

I've showcased internally, that things can work easily for simple usage, with F# scripts, referencing assembly and having it all bind nicely when updating the software and API.

I have not found something in the dotnet ecosystem that yields this kind of advantage, potentially to end users that for most, have a bit of VBScript and/or python background and are not endeavoured to learn and practice the greater dotnet itself.

And somehow, many are asking for python support, that we can't provide.

I think a "F# standalone compiler and FSI" in Windows Store still makes ton of sense.

cc: @satyanadella