When building applications or plug-in components which use FSharp.Compiler.Service.dll, you will normally also include a copy of FSharp.Core.dll as part of your application.
For example, if you build a
HostedCompiler.exe, you will normally place an FSharp.Core.dll (say 22.214.171.124) alongside
If doing dynamic compilation and execution you may also need to include an FSharp.Core.optdata and FSharp.Core.sigdata, see below for guidance.
The FSharp.Compiler.Service.dll component depends on FSharp.Core 126.96.36.199. Normally your application will target
a later version of FSharp.Core, and you will need a binding redirect to ensure
that FSharp.Core 188.8.131.52 forwards to which the final version of FSharp.Core.dll your application uses.
Binding redirect files are normally generated automatically by build tools. If not, you can use one like this
(if your tool is called
HostedCompiler.exe, the binding redirect file is called
1: 2: 3: 4: 5: 6: 7: 8: 9: 10: 11:
The FSharp.Compiler.Service component can be used to do more or less any sort of F# compilation. In particular you can reference an explicit FSharp.Core and/or framework assemblies in the command line arguments (different to the FSharp.Core and a .NET Framework being used to run your tool).
To target a specific FSharp.Core and/or .NET Framework assemblies, use the
and the appropriate command-line arguments:
1: 2: 3: 4: 5: 6: 7: 8: 9: 10:
You will need to determine the location of these assemblies. The easiest way to locate these DLLs in a cross-platform way and
convert them to command-line arguments is to crack an F# project file.
Alternatively you can compute SDK paths yourself, and some helpers to do this are in the tests for FSharp.Compiler.Service.dll.
If you do not explicitly reference an FSharp.Core.dll from an SDK location, or if you are processing a script
GetCheckOptionsFromScriptRoot, then an implicit reference to FSharp.Core will be made
by the following choice:
The version of FSharp.Core.dll statically referenced by the host assembly returned by
If there is no static reference to FSharp.Core in the host assembly, then
- For FSharp.Compiler.Service 0.x series, a reference to FSharp.Core version 184.108.40.206 is added
- For FSharp.Compiler.Service 1.3.1.x (F# 3.1 series), a reference to FSharp.Core version 220.127.116.11 is added
- For FSharp.Compiler.Service 1.4.0.x (F# 4.0 series), a reference to FSharp.Core version 18.104.22.168 is added
If your compilation arguments explicitly reference an FSharp.Core.dll from an SDK location, then FSharp.Core.sigdata and FSharp.Core.optdata should be alongside the DLL (if these files are not installed, then that's a bug in the F# SDK installation). If your compilation arguments are always making an explicit reference, then you should not include FSharp.Core.optdata and FSharp.Core.sigdata as part of your application.
If you are relying on an implicit reference (e.g. for script processing, see above), this means your tool may reference the FSharp.Core.dll
that is part of your application. In this case, you may either get an error that FSharp.Core.optdata and FSharp.Core.sigdata are not
found alongside FSharp.Core.dll. If you want to implicitly reference the FSharp.Core.dll you are including in your application,
then also add FSharp.Core.sigdata and FSharp.Core.optdata as two additional files to your application. When using
CompileToDynamicAssembly, this problem
can also manifest itself as a stack overflow during assembly resolution.
Tools that dynamically compile and execute code (e.g. a
HostedExecution.exe) often make an implicit
reference to FSharp.Core.dll, which means they normally also include FSharp.Core.optdata and FSharp.Core.sigdata.
In this design note we have discussed three things:
- which FSharp.Core.dll is used to run your compilation tools
- how to configure binding redirects for the FSharp.Core.dll used to run your compilation tools
- which FSharp.Core.dll and/or framework assemblies are referenced during the checking and compilations performed by your tools.