Can I use FSharp.Core, which comes with Visual Studio on Mono / Linux

Question

I would appreciate help, as I feel embarrassed.

If I believe this page, the best way to deploy the FSharp kernel with my application is to copy the FSharp.Core.dll file along with the application 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 corresponding FSharp.Core file as part of your application.

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

The standard F # tool installations on Linux and Mac on Mono also install the latest version of FSharp.Core in the GAC. They also add redirects for the entire component for the entire component. This means that for these machines the last installed FSharp.Core will be used by applications

what are the hints that you don’t have to deploy a copy of the FSharp kernel with the application, and the correct version of the FSharp kernel will be taken from the Mono GAC. I take two questions:

• This leads to two deployment scenarios for Windows and Linux;
• In Mono, this could potentially lead to the use of older FSharp code than the one available in the latest version of Visual Studio.

Perhaps all the problems could be solved by always creating the FSharp kernel from GitHub sources with the application, but this does not seem like an elegant solution. So I'm wondering what is the right way to always use the latest FSharp kernel regardless of platform (if at all possible)?

Answer 1

I understand that if you enable FSharp.Core with an application on any platform that, at least for Framework dependencies, the local bin directory is examined and used before searching the GAC. There are probably many other subtleties here, but at least from how I understand your locally copied version of FSharp.Core will be the one used by your application.

By the way, this should be relatively easy to verify using some reflection to look at the loaded type that comes from FSharp.Core and see which build it comes from. In addition, from the fact that I can recall AppDomain.AssemblyResolve , or a similar event, it can allow you to look a little into the resolving processes and even set it up a bit.

It should be mentioned that the GAC story has most likely changed a bit for the .NET Core and the accessibility of reflection technologies that I mentioned above.

Connected:

• Dll in both bin and gac, which is used?
• Is there any GAC equivalent for .NET Core?