Enable WebSharper for .NET Core

[Tarmil]

Compile the WebSharper libraries for .NET Standard 2.0 (is it worth targeting lower?) and the compilers for both .NET Framework and .NET Core. A lot of work is already in progress at https://github.com/tarmil/websharper/tree/netcore, I'll PR it here soon.

Some challenges:

• We still need a separate .NET 4 version of the libraries that use System.Web (WebSharper.Core.*, WebSharper.Compiler.*, WebSharper.Web and WebSharper.Sitelets), and replacements for these in the .NET Standard libraries:
  • UI.WebResourceAttribute: on netstandard, create a new attribute with the same name in System.Web.
  • UI.HtmlTextWriter: on netstandard, create a class with the minimal useful functionality from it.
  • HttpModules for RPC and Sitelets: just make them net4-exclusive.
  • Web controls that inherit from UI.Control: on netstandard, don't make them inherit from anything.
  • HttpContext.Current.IsDebuggingEnabled: find a way to pass a debug boolean down from the host instead of retrieving it from the ResourceContext creation.
  • HttpCookieCollection: use a NameValueCollection instead.
  • HttpPostedFileBase: use a custom interface instead.
• FSharp.Core reference: netstandard libraries will require FSharp.Core 4.1. Will this cause issues for VS2015 users? If it does, we might have to have a net4 version of every library that references an older FSharp.Core.
• Hosting: the only way to host WebSharper on .NET Core will be with Owin. Should we merge the websharper.owin repository into this one? (while still keeping the nuget package separate of course) If not, we can't run the tests here because there is no host to run them.

[Tarmil]

Let's discuss the above issues here, and implementation progress on the PR #791.

• FSharp.Core reference: netstandard libraries will require FSharp.Core 4.1. Will this cause issues for VS2015 users? If it does, we might have to have a net4 version of every library that references an older FSharp.Core.

After testing, no this does not cause any problems, we can happily reference the latest FSharp.Core nuget and have (almost) all our libraries be pure netstandard.

[Tarmil]

It turns out there are some pretty big issues for running the compiler itself on .NET Core:

• Mono.Cecil has a bunch of missing functionality on netstandard, ranging from no assembly signing to no default assembly resolver and metadata resolver.
• The F# compiler can only manage type providers if it is running on net4 (and TPs are pretty important in WebSharper, for UI.Next templating).

I believe we should keep the compiler running only on net4, at least for now, and concentrate on generating proper netstandard assemblies. We can reevaluate this when the above issues are fixed upstream.

[Tarmil]

I started working on an ASP.NET Core here. The basics are working, both sitelets and remoting, although it is still missing some bits.

• Authentication simply wraps ASP.NET Core's own authentication module, which is configured externally, so users will have to do this configuration; luckily, a minimal setup is just four lines of code, as can be seen here.
• Parsing POST parameters and files for sitelets is still todo.
• I am not quite sure how to handle configuration. Sitelets use System.Configuration in one place outside of the ASP.NET 4 handler, and also get the debug flag from HttpContext, but the former is non-idiomatic and the latter simply not available in .NET Core. So we need to abstract away configuration retrieval so that it can be implemented with the proper layer on each platform.