FSharp.Core.md

Comments on https://github.com/fsharp/fslang-design/blob/master/RFCs/FS-1034-fsharp-core-package.md#today

Supposed reasons for split

• The package is not signed

So sign it?

• The package is now relatively large (68MB on disk unzipped) due to the large number of variations, and may get bigger (E.g. embedded PDBs)

Not an issue, the compiler should do the optimisations needed.

• The package was prepared and pushed in an adhoc way

Set up a CI-environment.

• The package contains some delay-signed DLLs (the Xamarin variations are delay-signed)

Not an issue if you don't build for those platforms, again the compiler is the point where you need suppleness here.

• The package is not pre-installed with tooling (preventing some offline development scenarios)

So either add some version of the package to the tooling, or download it when the tooling initialises. After all, nuget.org is a public source of packages and you'll have your signature on the package.

• The package is not easily buildable from a source-tarball (a requirement in some settings)

Solve by setting up a CI server.

Conclusion

NuGet package already include enough split-points, such as the different target folders inside lib, to let the compiler and infrastructure and paket make the necessary choices about which DLL to reference.

Don't mess up the eco-system with a package split.

/Henrik, author of Expecto, Logary, Suave, Logibit.Hawk and a large number of other F# libraries.

Added fsharp/fslang-design#201 to discsuss about file size.
afaik (with some data, more to come), the 86MB is not the size add to MS Sdk.

At most, Sdk will add:

• bundled fsc compiler (another discussion the 1034 is for fsharp.core, that's 1033, there too can be from nupkg (and execute from cache as FDD) or bundled as SCD)
• a FSharp.Core nupkg (so compressed). that's 7MB

but about size can we discuss with data in fsharp/fslang-design#201