search

dotnet-websharper / owin

Wrappers for hosting WebSharper sitelets and remoting components in OWIN projects
Apache License 2.0
10 stars 9 forks source link

dotnet core support #21

Open juselius opened 6 years ago

juselius commented 6 years ago

Are there any plans for porting WebSharper.Owin to ASP.NET Core and netstandard2.0? If yes, what is the estimated timeframe? WebSharper.Owin, and consequently WebSharper.Suave, are currently incompatible with dotnet core due to an indirect dependency on System.Web through Owin 1.0.

granicz commented 6 years ago

Yes, this needs to be further investigated - @Tarmil any idea what it would take to refactor around Microsoft.AspNetCore.Owin?

juselius commented 6 years ago

I'd be glad to help. I already started investigating a bit, but there have been some quite substantial changes in ASP.NET Core.

Tarmil commented 6 years ago

Given your initial message, I assume your use case would be on Suave? To be honest, I'm not sure how much use there is for a .NET Core WS.Owin outside of Suave. How often do people use Owin hosts on .NET Core that are neither ASP.NET Core nor Suave? Depending on this, we have two courses of action:

  1. Convert WebSharper.Owin to use the plain IDictionary<string, obj>-based OWIN API rather than Katana, to be .NET Standard compatible. This would be a pretty thorough rewrite.

    Advantages:

    • Supports any Owin host both on .NET Framework and .NET Core.
    • Some work has beet started a long time ago by Ryan Riley on the raw-owin branch, although I'm not quite sure how much of it is usable considering how old this work is. @panesofglass What's the status of Arachne? I see the last commit was 2 years ago.

  2. Leave WebSharper.Owin as it is, and instead rewrite WebSharper.Suave to directly interface with Suave's own API.

    Advantages:

    • better performance on Suave, thanks to one less layer of conversion.

  3. Of course we could also do both, given enough hands on deck 😄

I don't really have a strong preference either way, so I'm open to suggestions.

panesofglass commented 6 years ago

@Tarmil Arachne was merged back into https://github.com/xyncro/freya-types. I may have enough time to help update my old PR. Even the Arachne/Freya.Types stuff is not necessary; it was just a convenient way to get the implementation in there. IIRC, raw-owin was close-but-not-quite? Or did we get it working and just not merge b/c there was no real need?

panesofglass commented 6 years ago

@Tarmil the Freya.Types package is licensed as Apache 2.0. Would that be a problem?

juselius commented 6 years ago

@Tarmil I'd be perfectly happy with solution number 2. I get pretty much everything I need from Suave, and it's a lot easier to reason about.

panesofglass commented 6 years ago

@Tarmil I'm not sure this would work completely, but it's another possibility for retaining OWIN support: https://www.nuget.org/packages/KatanaNetStandard/