EVEMon 4.0.20 - ESI Edition

EVE Technology and Research Center Third Party Developers
598

Priority imo would be to remove Http.sys to get it working, that’s what the proxy listener would do, a small simple listener and forwarder, http.sys is still there in .Net 6 for Windows HttpListener (at least from my initial glance at the source here runtime/HttpListener.Windows.cs at main · dotnet/runtime · GitHub) so if it runs in Wine, it’s still breaking. With a proxy listener, it can run in Wine and you can do the UI update anytime.

What I was thinking is something like the following,

User initiates SSO → Start proxy listener (that doesnt need Http.sys) and TCP socket → accept OAuth2 redirect → forward to EveMon via TCP socket → user SSO ended → shutdown proxy listener and close TCP socket

  1. (fixes blocking issue) Remove Http.sys dependency by using proxy listener (allows running in Wine on Linux/MacOS)
  2. (any time) Migrate to .Net 6 (updates runtime, no Http.sys issue now due to proxy used and can still run in Wine on Linux/MacOS)
  3. (any time) Update UI (now finally native runnable without Wine on Linux/MacOS with cross platform UI)
  4. (optional) remove proxy listener and use native .Net listener or continue with stable proxy listener to save code churn.

It’s your repository, it’s your app, I am just giving reasonable and constructive suggestions on solutions from what I have observed of the issue. It potentially solves this issue with the least effort and time then leaves any larger changes more managable to later.

Jumping straight into .Net 6 and hoping for it to run in Wine on Linux isn’t going to work from what I’ve seen (see source code for HttpListener in the dotnet repository), you will need to fix that blocking issue first.

A simple mininum working example to test a listener would confirm it. That is what the proxy would have done, replaced that listener, not the full app to remove Http.sys dependency.

The reason for using a proxy process is to save coding effort on reimplementing a new listener, just consume one already working from another language library and why I suggested Go as it’s small and working but you can use anything you are familiar with as long as it does not use Http.sys. All it has to do is listen for the redirect and forward it and let EveMon handle it.

You can find the source to the Go listener here https://cs.opensource.google/go/go/+/master:src/net/http/server.go the proxy is just the host for it, EveMon stays the same (except the SSO handling).

599

You might want to keep an eye on this issue ticket Deprecate HttpListener · Issue #63941 · dotnet/runtime · GitHub.

Looks like they prefer people move to ASP .Net Core (Kestrel) which would be a heavier dependency even with a “minimal” deployment (trimmable self-contained deployment with ASP .Net Core won’t arrive until .Net 7), so you will possibly face this issue again post .Net 7+ until that HttpListener is replaced.

You could add to this issue ticket, to show more people are using it for OAuth2 redirect handling for light short lived deployments (application authorizations). Not many are pushing back on there for that use case.

They really want to depreciate HttpListener, they already consider it obsolete and in maintenance mode years ago, see some archived history on it here Deprecate HttpListener · Issue #88 · dotnet/platform-compat · GitHub they will pull the plug imo as they don’t want duplication of effort and cost.

Though the future of authorization won’t be OAuth2 redirects (IETF GNAP is upcoming), CCP could enable a device grant flow (HTTP polling) to remove this issue also.

It’s like CCP just want web hosted apps.

600

Here is the roadmap for ASP .Net Core on .Net 7 ASP.NET Core Roadmap for .NET 7 · Issue #39504 · dotnet/aspnetcore · GitHub

Here is the issue tracking the ASP .Net Core deployment trimming Developers can safely trim ASP.NET apps to reduce their deployment payloads · Issue #27384 · dotnet/aspnetcore · GitHub

You might want to watch these issues if you are choosing to go down the ASP .Net Core path. This may be the way you will have to go if there is no alternative managed replacement suitable and ready for your liking. Proxying in another language’s server is not to your liking.

601

Here is a comparisson on UI frameworks for .Net. Avalonia and Uno. It is a bit subjective and dated though. It might help you decide on UI toolkits. I suggest taking a look at Avalonia.

GitHub - robloo/PublicDocs and PublicDocs/XAMLFrameworkComparison.md at master · robloo/PublicDocs · GitHub.

You may also want to track this issue ticket for cross platform publishing on a single build server here Support Nano Server and non-Windows OSes for apphost customization · Issue #9963 · dotnet/sdk · GitHub and Use cross-platform code to update apphost win32 resources, open apphost only once for writing · Issue #3828 · dotnet/runtime · GitHub, might be fixed in .Net 7+.

602

An architectural overhaul suggestion might be to separate EveMon as a daemon service and have the client UI access the service then you can have any UI you want on top of the service.

The advantage of this architecture would be, the daemon can run 24/7 collecting character data, even run on a separate instance on the network, and the UI can be anything and light. It would also perhaps make it easier to upgrade in the future as the framework changes or something better comes along, and also means different people can work easier on different parts of it (choice of UI’s too). It is also a polygot system where different languages can be used. You could use gRPC between the UI and daemon. See https://grpc.io/.

𓀠 [EveMon UI] ← RPC → [EveMon daemon] ← REST → [ESI API]

image
image704×271 5.62 KB

Figure 1: Top level architecture

You could have the Evemon daemon run native on Linux/MacOS after porting to .Net 6+ and have the UI run in Wine (until that’s ported). HttpListener / ASP .Net Core Listener on Kestrel in the daemon can run managed native on .Net 6+. RPC is the glue.

A quick fix is to use RPC to just the HttpListener in .Net that works natively (managed without Http.sys on Linux/MacOS outside of Wine), longer term, core functionality of Evemon moved into the daemon.

𓀠 [EveMon Wine] ← RPC → [EveMon HttpListener native outside Wine] ← OAuth2 redirect → [ESI SSO]

image
image724×296 6.8 KB

Figure 2: Fix for cross-platform OAuth2

For a single machine installation, the daemon can be started on the UI start and shut down after closing the UI. For just the HttpListener RPC, start up daemon for just SSO. Autostart should be configurable so we can run it manually or via other daemon managers in configurations such as Wine/Native boundary crossing or distributed.

It’s a little more effort, keeps the code managed but future proofs EveMon and makes it more versatile and modular.

This gives the following benefits

  1. Removes dependency on Http.sys for Linux/MacOS
  2. Allows piecemeal migrating to .Net 6+ for core data functionality whilst still keeping major UI work on .Net Framework, makes managing developer effort easier and smoother
  3. Allows distributed and continious running setup, even cloud instance hostable
  4. Allows straddling Wine/Native environments
  5. Opens up Evemon to other developers via RPC interfacing as a polygot system
  6. Separates out presentation from data collecting, UI can be replaced any time

If this suggestion doesn’t excite you then I don’t know what will.

603

EveMon does not take up more CPU than absolutely necessary, when minimized to tray or even simply off screen. I’ve made sure of that.
And due to the way .Net programs work, it is mostly unloaded into swap space at these times. So, there’s no reason to make it harder for yourself and split the head off the shoulders. What to the API, EVE-o itself is one.

604

Not sure what you’re referring to. It’s not about CPU usage, it’s about getting it to work on multiple platforms and .Net Framework isn’t the way nor is WinForms or MAUI, nor is http.sys. It’s also about architecting it to be doable with managable chunks of effort and long term future.

The only alternative is to rewrite it in one big effort, good luck. An “upgrade wizard/assistant” won’t fix it for you.

605

I’ve upgraded EVEMon to .net 4.8 today, and the datafiles are up to date again. Given that and some other fixes and features which were in the pipeline, v4.2.0 has been released: Release Evemon 4.2.0 · mgoeppner/evemon · GitHub

@Emotional_Support_Clown, I have no plans to rearchitect EVEMon right now – I have enough things on my plate right now, but thank you for the input. In the future please open technical disscussions as issues in the repository.

There are some fixes for running under mono (make sure you use the mono-complete package on ubuntu, otherwise you need to chase a thousand and one other packages down) here: Native linux fixes by mgoeppner · Pull Request #41 · mgoeppner/evemon · GitHub – there are a bunch of threading issues since mono doesn’t fully implement System.Windows.Threading.Dispatcher – but in most cases that can be replaced with Tasks which are supported sensibly.

The HttpListener under mono works decently, as long as you strip out the timeouts, which are unimplemented under mono and trigger a crash.

There’s still more to do around this of course, but this is solid progress to fixing some linux issues.

1 Like
606

If you are targetting 4.8 .Net Framework runtime, Mono runtime compatibility states Compatibility | Mono up to 4.7. Is the mono compatibility page stale or just not an issue encountered in practice?

Last commit a year ago on the page image

.Net Framework 4.8 release notes here dotnet/dotnet48-changes.md at master · microsoft/dotnet · GitHub

607

In theory, yes it could matter if we suddenly injected a truckload of 4.8 specific features (but 4.8 fixed more bugs than anything else).

In reality, since EVEMon isn’t doing that, and the framework is generally backwards compatible, it shouldn’t be a big problem.

608

You could consider an AppImage package for Linux systems https://appimage.org/ and bundle in Mono, alternatively you can also do self-contained bundles with Creating self-contained applications with MKBundle | Mono but AppImage is probably more adopted and has a portable mode.

609

trying this new version, but am getting header error when trying to add characters

## Bad Request - Request Too Long

HTTP Error 400. The size of the request headers is too long.
610

Have you tried adding a smaller/shorter character? :clown_face:

611

Can you provide a bit more detail please? OS in particular.

612

WInX, Chrome. it worked for a few, then this error started and will not go away. Tried removing a couple to see if it was some sort of character limit, still errored, and now can not get the ones removed back in (same error)

613

If you clear evemon’s cache does the problem go away?

614

Perhaps a slimmed down version of Evemon without all the bloated features and just have a minimal build of character monitoring and no cloud storage sync, skill planning etc? Perhaps as a separate branch build.

Would make porting easier to .Net 6 perhaps (less code warning noise), and break those out to either plugins or separate apps. Makes concurrent and separate development easier.

615

first thing I tried, and again with each step. never made any difference
also tried guest mode in chrome - failed

616

I like the idea of a bloat-less fork for monitoring only, but the main app has too many useful functions to be abandoned. Given the time and effort involved, may as well hope for a take over of EVE-Skillplan and pair it with EVE-Orchestra…

617

The idea is to cut it down to the mininum, then port to .Net, then build upon that again better modularly or separately. There is no future under Mono outside of niche unsupported architectures by .Net/.Net Framework or legacy. Nobody breaks new ground on .Net Framework. Typically it goes into maintenance mode only, as it is, and no new features. Just being able to track your character without logging in is better than nothing on Linux for many.

I think EveMon can be greatly simplified just from looking at the bloat in the code.

Logitech G15 keyboard support, that was released over 15 years ago. I would cut that to start with. Cloud storage, cut that too. Market prices from services outside of ESI, cut. Anything dependent upon non ESI API, cut it. Fitting/loadouts, cut it. Calendaring/Scheduling, cut it.

Those things can be added as a plugin. With that kind of mechanism, you can get more contributions from other developers and more isolated development without pull requests having to be managed for added features if the plugin interface is good enough. See Create a .NET Core application with plugins - .NET | Microsoft Docs.

image
Figure 1: Plugin interface

However, if they want to access the ESI API via the plugin, CCP put a hurdle that access is controlled by a private key, so each plugin would need a key, otherwise, ride on top of the app key (provided by the user in this case ideally). CCP don’t really want desktop apps, they want web hosted apps. That is clear by their choice of OAuth2 redirects and private devkey for authorization.

EVE-Skillplan is a hosted app and not open and same with EVE-Orchestra. I won’t hope for either of them for me, I am not interested in closed source hosted services. If you can host those yourself, then you have your solution.