Is --standalone compiler switch a good answer to F# dependency complaints?

[Ben Taylor]

Hi All,

On occasion people complain about having an "FSharp dependency".  Here is a recent example.  I think this phrase is used to mean one of the following:

• We don't like FSharp.Core in the bin (and don't know about ILMerge or do know about ILMerge but don't want the hassle).
• We don't want to work with a project that is written in F#, because we don't know the language so making changes will be difficult.
  

The second will change over time, but isn't the answer to the first the --standalone compiler option?  The documentation says:

Specifies to produce an assembly that contains all of its dependencies so that it runs by itself without the need for additional assemblies, such as the F# library.

I've only played with this option and have had no need to use it far and wide, therefore am hesitant about recommending it.  I never see it mentioned, so wonder whether there are gotchas I'm not aware of.  Is it the good answer it seems or have I missed something?

Ben

[Robert Jeppesen]

In my experience, you should never use --standalone for a library. Effectively, all the types you depend on are duplicated, *and are not comparable* to the same types when not compiled with --standalone. So, if you're compiling an exe then that is fine if it makes your deployment easier (though I probably wouldn't). If you're compiling a library, --standalone is not an option.

You'll get funky runtime errors.

[Kevin Ransom (MSFT)]

Ben,

it is not clear to me why having a dependency on fsharp.core is widely considered by developers to be a bad thing.  I can see that distributing a single file app might be considered easier and it is true that fsharp.core is not deployed with the .net framework.  However, that is actually a good thing for us, because it makes it easier for us to evolve the F# core libraries.  Although there is one negative to it not being in the framework and that is our portable library story is more cumbersome than it is for VB and C#.

The open source community seems to have moved to a packaged library model already with tools like nuget popularizing a componentized model based around libraries.  So it seems as if having functionality in libraries is a thing that the development community have already decided is a good thing..

As for the learning curve, that is true of every language.  Believe it or not in the early 80's when Basic and Pascal were very popular PC development languages, people struggled to make justifications to move to C, and then the move to C++ was what everyone struggled with.  I would say that if the language is good, useful and well maintained it will become easier over to time to gain adoption.  I believe the strike against F# a few years ago was the public perception of insufficient Microsoft support.  That is now fixed, F# is back where it belongs in the Managed Languages team, it is staffed at a justifiable and sustainable level, and it is open source and fully collaborative.  There is a lot of energy around F# right now which I expect to help in adoption discussions.

Kevin

[Ben Taylor]

Thanks for the response Robert.  Apologies, I should have actually looked at the specifics of how the dependencies were included before posting! 

[Ben Taylor]

Kevin, thanks for the detailed response.  Personally, I agree with your thoughts and happily use F#.  I was just wondering if there were any other options when people raise this as an "issue".  Obviously, I hadn't really thought it through!

[m...@60hz.org]

On Tuesday, November 25, 2014 4:20:27 AM UTC+9, Kevin Ransom (MSFT) wrote:

it is not clear to me why having a dependency on fsharp.core is widely considered by developers to be a bad thing.  I can see that distributing a single file app might be considered easier and it is true that fsharp.core is not deployed with the .net framework.  However, that is actually a good thing for us, because it makes it easier for us to evolve the F# core libraries.  Although there is one negative to it not being in the framework and that is our portable library story is more cumbersome than it is for VB and C#

I've actually run into a corner case recently where the FSharp.Core dependency has caused some trouble. I was modifying the F# CodeDom library to include a built-in installer that adds the necessary compiler entry to machine.config. The library requires F# 3.0 at minimum, but works fine with F# 3.1. It builds fine against 3.0 (i.e. <TargetFSharpCoreVersion>4.3.0.0</TargetFSharpCoreVersion> in the fsproj), but after you install it to the GAC and try to run the installer with installutil.exe, an exception gets thrown because it tries to find FSharp.Core 4.3.0.0 and fails. The only workaround I've found is to use --standalone (are there any other solutions?). This is just one case, but it's a real example of how FSharp.Core can be nuisance.

The single-file app thing is also a legitimate argument, though what I do for this case is to build with --standalone and then run monolinker on the result, which practically eliminates FSharp.Core from the assembly and gives you a nice small file.

Mark Laws