Compiling FSharp.Core for netstandard1.3

[ncave]

@dsyme Following on the netstandard2.0 discussion, would it be feasible or advisable to make an effort to compile FSharp.Core to lower targets like netstandard1.3 or even netstandard1.0? Just looking for options for low-profile portable FSharp.Core for projects like this.

[cartermp]

IIRC the lowest we can go is netstandard1.5 due to our dependency on System.Reflection.BindingFlags. Unfortunately, there isn't much to gain in terms of targets between 1.5 and 1.6.

[ncave]

@cartermp There is FX_NO_SYSTEM_BINDINGFLAGS for that, if that's the only reason (just for that target).

[cartermp]

Ah, we also require Exit() which is also only in 1.5 and up. This would also have to be factored out. I think the factoring needed for that FX_NO_SYSTEM_BINDINGFLAGS is also work which we don't see as that high priority, though I can't see why we wouldn't take a PR for it.

[ncave]

There is FX_NO_EXIT for that, but the real problem seems to be System.Linq.Queryable. Oh well.

[KevinRansom]

@ncave.

This has come up several times, yes it would be nice if we could ship an FSharp.Core for netstandard 1.3. However, we can't for reasons, you and phillip have reiterated. We don't want to be in the position where we ship a plethora of FSharp.Core dll's.

We determined that a netstandard1.6 and a net45 build of fsharp.core would give us the best reach. Developers can then use nuget to select between the two based on target build. The dotnet sdk makes targeting and building multiple dll's using nuget quite easy. I believe Steffan has done a bunch of work to make a paket alternative feasible.

The main issue is what to do with FSI. FSI has always struggled with assembly resolution, Steffen and friends have been working on paket integration for FSI. It is a great approach and I am fully in favor of integrating it into FSI, but priorities have delayed me from following up on it. But it is firmly on the list of things to do.

We have a point in time problem right now. I am reluctant for us to build in hacks that do not support the goal of good paket management.

Kevin

[ncave]

Thanks @cartermp @KevinRansom. Closing.