v4

[geoperez]

Hey @rdeago, what is the idea to bring v4 to life?

[rdeago]

Hey @geoperez, thanks a lot for enabling discussions on the repo!

I apologize in advance because I'm writing in an awful hurry. I'm busy with personal stuff (not programming-related) this week but I didn't want to leave your post unanswered.

Here's my current status, mostly copypasted from #546.

Completed:

• Backport of PR with fixes of some issues #534
• Both standard .NET analyzers and StyleCop analyzers enabled; diligently configured so as to not conflict with one another, with Visual Studio, or with ReSharper.
• Code style enforced via both analyzers and .editorconfig.
• ALL warnings either fixed (nearly all of them) or suppressed with explanatory comments
• Refactor WebSockets support #547
• Create a general-purpose "service" class with lifetime management with a better, more async-friendly implementation of lifecycle methods (issue with details coming soon)
• Make WebServerBase derive from the generic service class
• Separate general-purpose utility types into their own library / package #550
• New utility classes for argument validation #551

To do:

Here things get a bit complicated.

In #549 (comment) @michael-hawker opened my eyes to some negative consequences of switching to .NET 6.0 exclusively. He definitely has a point: we should target both .NET Standard 2.0 and .NET Standard 2.1 in addition to .NET 6.0. This requires a few polyfills. (More on that later.)

I also saw that v4 needs to dispense with at least some HttpListener madness. I had already done some work on that in an ugly mega-commit (on the main branch) I didn't even finish in 2020 🙈 because of an awful lot of things happening. (Long story.) I started backporting stuff from my local main but then...

I also had to go forward with some actual (as in "paying the bills") work projects, which incidentally need some of the very same types I had already put in the shiny new EmbedIO.Utilities, and had the same polyfilling needs too. What could I do? I had no hope of completing EmbedIO v4 in time to use EmbedIO.Utilities. I had to copypaste the most general-purpose types from EmbedIO.Utilities in another library, which is going open-source shortly and also include a few more general-purpose stuff copied from my closed-source libraries, so I can finally get rid of the 20+ tiny libraries I've always wanted to open-source but never got to.

Should I keep the same types in two libraries, instead of adding a dependency to my library? I don't want to trade a SWAN for a... whatever, insert favorite animal here, you get the point. On the other side, my new library (going online shortly) is a lot narrower in scope than SWAN (no logging, no tons of extensions to System.Object and IEnumerable) so the number of issues we'd have to redirect to it is bound to be close to zero.

Then (or better, at the same time) there is the issue of polyfills. Commonly-used polyfilling libraries like Nullable and IndexRange have shortcomings that I will not discuss at length here (I'm preparing a document about that anyway); other libraries have their own problems, and I couldn't find a a polyfill library that satisfied all my requirements, so I'm rolling my own. It's not NIH syndrome at work here. I won't say I'm completely immune from it, but over the years I've learned to not reinvent the wheel... unless I need a new kind of wheel, so to say.

At first, polyfills were part of my new library, but soon that proved to be a terrible idea: they have to be a library on its own. In the same repo, as part of the same "reusable stuff" project, so I dont' have to prepare one more README (not to mention find one more decent name) etc.

With the two new libraries almost ready for release, I've had some problems with the build system I use for all my projects. This in turn had me ditch some in-house code in favor of ThisAssembly, which in turn needed some work before it could replace my code completely.

So my plan for the upcoming days is as follows:

• finish this PR on ThisAssembly (by the end of this week);
• update the build system and publish the two new libraries (3 days max);
• resume work on EmbedIO v4 in parallel to personal work projects.

Interlude: branching madness

I confess I've made a bit of a mess with the main branch two years ago: I had to abruptly suspend work on the then-to-be v4, then months passed, and now my local main is an awful pile of half-finished stuff. The PR I'm preparing is based on V3.X: not good for the commit history, but I had no real choice.

@geoperez do I have write permission on the repo so I can fix things myself? If not, there are a couple things to do:

• create a new branch v4-old, same HEAD as main (just for backup);
• force-reset main to the HEAD of V3.x.

Then I will rebase my local PR branch from V3.X to main and open a draft PR. I'll push commits to the PR branch as I progress, so my work will be more visible.

Next items of work

• Remove SWAN as a dependency #548 - meet our new mutual friend Microsoft.Extensions.Logging 😁. Of course the example project will be scaffolded (probably with Serilog) so as to make a starting point for newcomers, without them having to make a dozen architectural choices before even starting to try out EmbedIO.
• Immutable configuration will go dodo. The main issue with it is that it is too cumbersome and verbose to implement. Init-only properties are a simpler solution to the same problem.
• Fluent initialization methods are getting the death kiss too. Simply too much overhead. Object initialization syntax is just as terse (and more easily debuggable) without requiring extra code.
• Get rid of URL prefixes #464 - this one, at least, is easy
• New response object (resuming some of the "old v4" work). No more "sending" a response body: you'll instead set a callback that sends it. The HttpListenerResponse will not even be touched until EmbedIO is ready to send the response. This way, exception handlers will be able to actually replace the response, because headers will not be already sent.
• As a direct consequence of the new response implementation, support for partial / range GET requests could be moved from FileModule to EmbedIO itself - so every module would automatically get it.
• Client-side routing support in FileModule #490

Then it's v4.0-preview.1 at last!!

Further discussion items

• As soon as my new library is out, I'll ask for feedback as to whether it is fine to have it as a dependency. The alternative is duplicating part of it in EmbedIO.Utilities. I'm personally for the dependency, because bugs in duplicated code have the bad habit of being fixed in just one place: programmers are human beings after all.
• Is the solution proposed in Client-side routing support in FileModule #490 the right one? Or does it look more like a band-aid? Do we need something "nearer to the core" instead of a fix to FileModule? (Replies to this are better posted in the issue.)
• Can someone clarify what is the best platform to target for Xamarin applications? (Or MAUI, or how it's called this week. 😬)
• Is anyone willing to take up some work on v4? I have to know so I can split work in a way that can be done in parallel.

[geoperez]

LOL, I know. Can you try again?

[rdeago]

👍 It worked. Thanks!

[michael-hawker]

MAUI is the evolution of Xamarin, but they're still different underlying architectures. MAUI is built directly on top of .NET 6 for instance.

If you still plan to multi-target .NS 2.0, .NS 2.1, and .NET 6, then as far as I'm aware that should cover you for both existing Xamarin users and new MAUI folks. Adding @brminnick as a MAUI expert to keep me straight here. 🙂

[brminnick]

Yup, .NET MAUI is a breaking change from Xamarin.Forms.

Xamarin.Forms is currently in maintenance mode (bug fixes only, no new features) until November 2024, at which point it will be deprecated.

Looking at the EmbedIO NuGet Package, it targets only .NET Standard 2.0 which will work in .NET MAUI apps, since .NET 6.0 is compatible with .NET Standard 2.0:

I recommend keeping the EmbedIO.Forms.Sample until Xamarin.Forms is deprecated, and adding a new .NET MAUI Sample to the repo.

[rdeago]

@michael-hawker @brminnick thanks for chiming in!

[rdeago]

Thanks to the .NET Standard compatibility table linked by @brminnick (thanks again!), I think I can confirm that the platforms to support are:

• .NET 6.0 (latest features and optimizations; also support for MAUI, latest WinForms / WPF, Avalonia, UNO Platform, etc.)
• .NET Standard 2.1 (Xamarin.Forms, Unity, Mono)
• .NET Standard 2.0 (.NET Framework)

[michael-hawker]

.NET Standard 2.0 would be able to support UWP as well. And .NET 6 supports the WinUI 3 / WinAppSDK from those tech stacks (both of course which Uno Platform overlaps with).

[geoperez]

@rdeago I updated AppVeyor settings to VS2022

[geoperez]

@rdeago sorry for the really really long delay, here the RC1 for EmbedIO v4 https://www.nuget.org/packages/EmbedIO/4.0.0-rc1

Let me know if I should push the final version.

[rdeago]

@geoperez sorry but there must have been a misunderstanding. Version 4 is not ready yet, I didn't expect the master branch to even build.

What we need now is a package of version 3.5.0, built from the v3.x branch. See #565.

I'm sorry for the inconvenience. Maybe we should find a more direct way to communicate.

[geoperez]

My fault totally. It can remain as RC1, and I can publish the 3.5.

[geoperez]

Ok, I unlisted RC1 and now I published 3.5 (https://www.nuget.org/packages/EmbedIO/3.5.0)

I hope everything is fine now 👍🏿

[rdeago]

It definitely is! You just made quite a few people happy. Thanks a lot! 😃

[geoperez]

So what is the plan now? Did you release your library?

[rdeago]

Of course! It's going online in a few days
- myself, on May 25th (#561 (reply in thread)) 🤦‍♂️

So what is the plan now? Did you release your library?
_- @geoperez, 2 minutes ago (#561 (reply in thread))

Yes I did, at last! I'm happy to announce the birth of not one, but two libraries, which I humbly propose as dependencies to EmbedIO version 4:

• L.o.U.I.S. is the general-purpose library I had originally set out to write;
• PolyKit is a complete and hassle-free polyfill library. It is already incorporated in L.o.U.I.S. so technically we don't need both.

They both support all necessary target frameworks (and more, going back to net462). You can take a look at what's provided with the help of the wonderful FuGet.

The libraries are both still in a preview phase, but I'm already using them in my current business projects. As a matter of fact, it's all either code I had sitting here in some internal-use libraries, or code I'd have written anyway, but it felt wrong to me to declare them "stable" just because they work for me. (Besides, I'm still refining some details in L.o.U.I.S. and there could still be breaking changes for a while.)

[geoperez]

Nice, I'll take a look. Why Louis btw?

[rdeago]

It's in the README. 😉

[geoperez]

I just read it, "Lots of Useful & Interesting Stuff". OMG you are such a SWAN fanboy xD

[rdeago]

When writing the README for L.o.U.I.S., I stopped just short of adding that SWAN was already taken. 🤣

[TomCJones]

I am switching a project of mine from .net 3.1 to .net 6 and want to continue to include embedio. As i understand this thread i should be using embedio 3.5 at least for the short term? Does anyone have any real-world experience with .net maui?

[dos-ise]

Hi,

since we used Embedio in our Xamarin App and have now migrated to MAUI.

I have created an example repo using Embdeio in a MAUI app.

Combing this and the new multi window support of MAUI is a really amazing combination for our iPad App.

https://github.com/dos-ise/EmbedioMultiWindowMauiApp

[Scobie]

Hello

First - my thanks for creating EmbedIO, which we have been using to successfully host a web server on our embedded Android 7.1.2 equipment for a couple of years now, using code developed using Xamarin Forms 5.0.x & .NET Standard 2.0.3

We have been asked to improve our security for clients connecting to the equipment & I did some investigation around HTTPS/SSL with EmbedIO & I now appreciate that EmbedIO only supports HTTPS/SSL when hosted on Windows OS & not Android & have read various different discussions on your GitHub pages.

Due to the embedded nature of our product we will not easily be able to change the OS type or version. Do you guys have any plans to integrate support for HTTPS/SSL in EmbedIO on an Android OS in v4?

Thanks for your time

[bufferUnderrun]

Better late than never,

i've been ping in #546 with some folks @mariodivece @geoperez @k3zo
@madnik7 @rocketraman @maarlo @GF-Huang
@AbeniMatteo @gabriele-ricci-kyklos @tiziano-morgia @ghiboz @SaricVr @miquik

I'm very thankful for this project as the v2 has been part of many of my own for 3 years.
But i was not convinced by the rewrite v3, too verbose particularly FluentAPI, too many split class overly abstract, legacy HTTPListener...

I'm moving to another promising project, SimpleW.
EmbedIO does not seem to be active anymore (last commit 2y+), so i encourage people to give it a try or share another proposal

[dos-ise]

I hoped WiseJ.NET would revitalize EmbedIO.
dotnet/maui#19198

@bufferUnderrun Does SimpleW work on MAUI?