5

I'd appreciate some help as I feel confused.

If I am to believe this page, the best way to deploy FSharp core with my application is to copy the FSharp.Core.dll along with the app binaries ("xcopy deployment").

In compiled applications, you should never assume that FSharp.Core is in the GAC ("Global Assembly Cache"). Instead, you should deploy the appropriate FSharp.Core as part of your application.

So far so good, I feel totally comfortable with that ... on Windows. However, regarding Mono, the same page reads:

Standard installations of F# tools on Linux and Mac on Mono also install the latest FSharp.Core into the GAC. They also add machine-wide binding redirects for that component. That means that, for those machines, the latest installed FSharp.Core will be used by applications

which kind of hints that one should not deploy a copy of FSharp core with an application and the correct version of FSharp core will be picked up from the Mono GAC. I take two issues with this:

  1. This forces to have two different deployment scenarios for Windows and Linux;
  2. On Mono, this potentially forces usage of an older FSharp code than one that is available in the latest Visual Studio.

Both issues could have probably been addressed by always building FSharp core from GitHub sources along with the app but this does not look like an elegant solution either. So I am wondering what's the right way to always use the latest FSharp core regardless of the platform (if that's at all possible)?

DmytroL
  • 586
  • 1
  • 3
  • 16
  • 2
    `--standalone` might be your best bet here – John Palmer Nov 27 '15 at 12:00
  • Windows requires usually an MSI while Linux expects a deb or rpm, so anyway they are different. – Lex Li Nov 27 '15 at 13:58
  • @LexLi I had xcopy deployment in mind, which is actually more common for Web apps than an .msi or a .deb/.rpm – DmytroL Nov 29 '15 at 19:26
  • @JohnPalmer I am not actually sure what could that mean... googling for such command-line option in Mono does not reveal anything meaningful at the first glance – DmytroL Nov 29 '15 at 19:28
  • @DmytroL - It is a F# compiler option to bundle every reference into the exe - https://msdn.microsoft.com/en-us/library/dd233171.aspx – John Palmer Nov 29 '15 at 20:42
  • you could create a pull request on github.com/fsharp/fsharp to stop deploying FSharp.Core into the gac, to align both platforms – knocte Dec 04 '15 at 03:15

1 Answers1

0

My understanding is that if you include FSharp.Core with an application to any platform that at least for Framework Dependent Deployments the local bin directory is probed and used first before looking in the GAC. There are probably many other subtleties here but at least from how I understand it your locally copied version of FSharp.Core would be the one that gets used by your app.

By the way, it should be relatively easy to test by using some reflection to look at a loaded type that originates from FSharp.Core and see which assembly it is coming from. Additionally from what I can recall AppDomain.AssemblyResolve or a similar event may allow you to peek a bit more into the resolving processes and even customize it a bit.

It should be mentioned to that the story as far as the GAC is concerned has likely changed quite a bit for .NET Core along with the availability of the reflection related techniques I pointed out above.

Related:

Community
  • 1
  • 1
jpierson
  • 16,435
  • 14
  • 105
  • 149