Hi, I’ve been updating EVEMon lately, and I don’t really come to the forums that much, but I just saw this thread and a number of you are still having issues with 4.0.20 – please update to 4.1.3, which contains the needed fixes for your issues.
You can find the downloads here: https://github.com/mgoeppner/evemon/releases/tag/4.1.3
If you find EVEMon useful and want to support its continued development, ISK donations can be sent to IGN InfinitasX
Is there a convenient way to install and run EveMon on a Mac or in Linux?
(If there’s no convenient way, I would also accept an “inconvenient” way if the instructions are clear enough!)
Windows 10 VM in KVM or VirtualBox or something in a seamless integration mode.
EveMon isn’t runable on Wine Mono currently. .net is a failure of not being runable everywhere, the very thing .Net was sold as and EveMon developers (EveMon always keeps getting abandoned by developers who fork it) only care about Windows which doesn’t help either. Opening non Windows bugs on it just gets blackholed.
A Go port with Qt or wxWidget bindings would be nice.
Write once, compile everywhere always beats compile once, run everywhere.
One of the root causes is the usage of HttpListener, which is dependent on HTTP.sys, which wine doesn’t implement fully. There have been some ideas for how to approach removing HttpListener, but its a fairly large amount of effort, which is why it hasn’t been tackled. PRs to fix linux support are welcome.
Ideally I’d like to make EVEMon run outside of wine using .net natively, but there are only so many hours in a day, and I like to play the game too 
That’s the problem, Microsoft promised compile once run everywhere and only supported the Windows runtime for anything useful and their renewed focus on .net core for Linux is basiclly for Azure so I wouldn’t expect any fancy desktop support there either, just basic server support. As for Java, that’s being killed pretty well by Oracle themselves (Android moved to Kotlin more).
It doesn’t (shouldn’t) need Wine, just a Mono runtime to run (Wine installs Mono).
Battling to get .Net stuff working on Linux is not a priority for me as Linux developer when now we have better offerings that work cross platform better. If you want to be stuck in Windowsland, then sure .Net is great, to go further than that, it’s a problem.
I would prefer to cleanroom this in something like Go and Qt if I was to have it native, I prefer write once compile everywhere. Sure it’s a bigger effort, but in the long game, it’s worth it. And to boot, you will gain far better concurreny scaling and implementation via goroutines (based on C.A.R Hoare’s CSP). It also just got Parametric Polymorphism (generics) added in release 1.18.
Is this the relevent Wine bug ticket for HTTP.sys? → WineHQ Bugzilla – Bug 49819 – Multiple .NET 4.x/5.x apps need 'httpapi.HttpSetUrlGroupProperty' to support 'HttpServerTimeoutsProperty' property (EveMon 4.0.18.4979, ASP.NET Core apps)
To eliminate the HttpListener problem, CCP would need to offer an alternative to OAuth2 redirect flows, they could adopt GNAP (alongside OAuth2) or alternatively allow an API key or device authorization mode perhaps for OAuth2 (that uses HTTP polling rather than redirect listening).
See my post on that here ESI authorization for apps and services with no browser access or UI and ESI authorization for apps and services with no browser access or UI - #17 by Emotional_Support_Clown
There is a managed version of HttpListener, but that requires .net 6.0. There has been some work done on this front, but there is still quite a bit to do, especially with regards to some of the older libaries used for various features.
Yes, that would be the relevant wine issue.
As I said, the HttpListener problem can also be dealt with by using a something written in fully managed code instead of requiring a call to the native http.sys library. One in theory could use a TcpListener instead, but there then needs to be some boilerplate written to parse the HTTP stuff involved.
Porting to another language and ui toolkit is not something thats going to happen overnight simply by virtue of the amount of stuff that would need to be ported. I’d prefer to focus the conversation around what we can do to make things work on linux in the near term rather than something extremely long term like porting.
Remove the HttpListener
Use the device code grant on the device flow on OAuth2
See OAuth 2.0 Device Code Grant and Token Request - OAuth 2.0 Simplified
Problem solved. No more “not implemented” HttpListener as there is no more redirects to listen for. You can poll HTTP.
OAuth2 supports a non-redirect flow for devices.
There’s your fix.
This would require the SSO api to support that, which I don’t believe it does. This is the ESI documentation on how to do SSO for native applications – OAuth 2.0 for Mobile or Desktop Applications | esi-docs. Pyfa (written in python) also uses this same flow with a listener to receive the authorization – the difference is python’s http code does not require windows native code to run
There currently is a feature request open for this grant flow here Request to implentment OAuth 2.0 Device Flow · Issue #65 · ccpgames/sso-issues · GitHub
An alternative option could be to write up a little proxy server in a language such as Go that you could talk to from EveMon, and let the proxy server proxy the OAuth2 redirect via a socket. That would be simplier and quicker than reimplementing a full HttpListener. You just launch the proxy when doing a character SSO then shut it down after completion. That way you can use the existing OAuth2 application grant flow.
[EveMon] ← socket → {Go proxy listener} ← OAuth2 → [CCP SSO]
More moving parts, but doing it in something like Go should keep it small and simple.
Now you have three possible solutions
I would seriously consider option 2 as a stop gap before the migration to .Net 6+ and other larger gutting (UI framework for example). That way you will have it up and running on Linux and Mac. You could do that proxy either for all platforms or just for Linux and Mac as experimental. It looks like a major refactoring of the app is necessary anyway for future proofing. This proxy solution would still continue to work with a .Net 6 migration so it can last longer if need be.
.Net Framework is dead.
Thank you for Bringing EVE Mon back!
$ git clone https://github.com/mgoeppner/evemon.git
Always have a local copy.
Microsoft are now retiring the target framework used by EveMon.
See Windows message center | Microsoft Docs and .NET Framework 4.5.2, 4.6, and 4.6.1 will reach End of Support on Apr 26, 2022 - .NET Blog
EveMon has the following runtime target in evemon/EVEMon.csproj at main · mgoeppner/evemon · GitHub
<TargetFrameworkVersion>v4.6.1</TargetFrameworkVersion>
The end of .Net Framework is near (thankfully).
While I understand you may not like .NET, the reality of the situation is that it is what EVEMon is built upon, and constantly complaining about it is not constructive. You also are also welcome to help contribute with pull requests to improve Linux support.
I am aware of the 4.6.1 deprecation, and it is one of the reasons why I have been working on .net 6 support. As a stopgap, EVEMon will likely be upgraded next week to 4.6.2 which remains in support.
I was suggesting solutions and just stating that people should update their runtime as SHA-1 is depreciated. You have three solutions, good luck chasing MAUI, it’s not the "proper linux support* as per your Github ticket tracking you claim it is here (Crash on Wine due to unimplemented native HTTPListener · Issue #9 · mgoeppner/evemon · GitHub) .Net Framework is reaching end of life. .Net 6 is not. .Net 6 is based on Mono for Linux. Pretty sure I have been constructive, see here EVEMon 4.0.20 - ESI Edition - #586 by Emotional_Support_Clown option 2. You may not like what I say, that’s fine.
“.Net Framework is dead.” and " The end of .Net Framework is near (thankfully)." are not constructive comments when discussing a nearly decade old tool written on that platform, nor is bringing up Go.
If you want to help, make pull requests – There is plenty of stuff to do.
Pretty sure a small Go proxy listener can be up in a day. It will forward the OAuth2 response to the EveMon (my suggestion for option 2). You can do it in any language, not just Go, it would get Http.sys out of the picture and it working on Linux / MacOS in no time.
You even claim MAUI is “proper Linux support” when Microsoft state VERY clearly they have no intention to support Linux on MAUI.
See here Crash on Wine due to unimplemented native HTTPListener · Issue #9 · mgoeppner/evemon · GitHub
Not sure what you’ve read but it wasn’t Microsoft’s own page on it.
I look forward to seeing your pull requests then.
MAUI from a dotnet PM (Project Manager)
No Linux there either, see What is .NET MAUI? - .NET MAUI | Microsoft Docs , “Linux” text search results in zero occurrances.
Supported platforms Supported platforms for .NET MAUI apps - .NET MAUI | Microsoft Docs again, no Linux.
Not sure how you see “proper Linux support” from all that. I certinally would be interested to read about it because everybody else is using Avalonia or Uno to get Linux support on .Net.
WinForms is a continual headache for running natively on multiple platforms, which is why MAUI came up in that discussion at all. I’m happy to be wrong about it though, but a new UI toolkit would be needed, which is not really something I am interested in tackling in the near term. Let’s take the technical discussions to github – its a better platform for this sort of stuff.
