.NET 5 update progress

[Archomeda]

The update to .NET 5 has been a long journey so far. Development is mostly done in the feat/net5 branch.

• [x] Update TFM to net5.0
• [x] Update GitHub actions to build the .NET 5 version
• [x] Remove all Fody references from the repository (Fody is no longer needed as it's being replaced with single file publishing)
• [x] Use single file publishing
• [x] ~~Integrate DebugHelper code into the main Blish HUD project (and remove the separate executable build)~~ (done separately in #427)
• [x] Decide what to do with CSCore and if it's removed, update the code to no longer depend on it (CSCore doesn't have a .NET Standard/Core build, and while it technically should still work, it does still depend on .NET Framework, despite Blish HUD itself being fully .NET 5 instead)
• [ ] Check (and fix if necessary) what's causing the version to be included in the settings.json file, and causing the local VS build to throw an exception (and discard the settings) when it's loaded after using the CI build at least once (some settings.json overhaul is being done on the net5-settings branch, a.k.a. moving away from Newtonsoft.Json to System.Text.Json)
• [ ] Decide whether to use the portable build, or the self-contained build (and if trimming is an option, albeit still kinda experimental)
• [ ] Testing...
• [ ] Update module template to use .NET 5
• [ ] Maybe find a way to support modules made in .NET Framework 4.8 for backwards compatibility?
• [ ] Probably update to .NET 6

[dlamkins]

Do we want to try and backport some of these changes into the framework version in preparation? For example, embedding the debug hook stuff or including the setting changes?

[Archomeda]

I think that's possible, unless I did something very .NET 5 dependent that I can't remember at the moment. We can try to backport the DebugHelper, CSCore (once that's done, or before this) and the settings JSON. Do you have similar stuff in mind?

[eksime]

I had a look at swapping the CSCore-dependent code to use NAudio.Wasapi - It's a fairly painless swap as they expose basically the same APIs. The code is at https://github.com/eksime/Blish-HUD/tree/feat/naudio if it's any use for task 6.

[dlamkins]

Dang, that's pretty sweet! Would definitely be a great way to get this process moving again since it was originally going to mean ripping out quite a bit and that was a bit tiring to think about. 😅

[eksime]

I can submit a PR if wanted - I wasn't 100% sure on the AudioEndpointNotificationReceiver class, or whether it'd be better to implement IMMNotificationClient directly on the AudioIntegration service 🤔 I've also just seen that NAudio was removed a while back in favour of CSCore, was there a reason naudio wasn't suitable for other stuff?

[Archomeda]

If we can get this rolling, that would be awesome 😄

[dlamkins]

I can submit a PR if wanted - I wasn't 100% sure on the AudioEndpointNotificationReceiver class, or whether it'd be better to implement IMMNotificationClient directly on the AudioIntegration service 🤔 I've also just seen that NAudio was removed a while back in favour of CSCore, was there a reason naudio wasn't suitable for other stuff?

I like what you ended up doing. We only moved to CSCore as I was unfamiliar with naudio having what we needed at the time.

[KWottrich]

Am I correct in understanding that a successful migration to .NET 5 would mean support for running BlishHUD on Linux? I believe .NET 5 supports Linux, but I'm both overwhelmingly confused by the versioning conventions of .NET, and also unsure if there would be more work required beyond targeting .NET 5 to get Linux compatibility.

[dlamkins]

Am I correct in understanding that a successful migration to .NET 5 would mean support for running BlishHUD on Linux? I believe .NET 5 supports Linux, but I'm both overwhelmingly confused by the versioning conventions of .NET, and also unsure if there would be more work required beyond targeting .NET 5 to get Linux compatibility.

It's certainly a first step in native support without needing to rely on Wine, but the "overlay" aspect of Blish HUD that allows us to draw on a transparent window currently utilizes some WinApi crimes which would need adapted quite a bit before it'd be usable on Linux.

This is in fact the current problem when using Blish HUD via Wine. It should actually run just fine (when we've disabled the audio pipeline in custom builds) but the windows do not properly acknowledge the transparent window and so it is left opaque with a black background.

Ultimately, I believe we are a pretty long way away from truly supporting Linux, but this is a step in the direction of making that easier.

[dlamkins]

The latest releases do run on Linux, but are still opaque due to the issue I mentioned above. This guide below provides a way for those on Linux with certain configurations to now use Blish HUD without native support.

https://gist.github.com/martinlabate/c4e6f08880a009f88dc1edaa4c6cd87a

It does involve some jank, but for those that really want it, it's an option.

Running on Linux is likely not to be a direct goal of the core rewrite now as there are other difficulties running natively (such as dealing with mumble).

[ghtesting2020]

The latest releases do run on Linux, but are still opaque due to the issue I mentioned above. This guide below provides a way for those on Linux with certain configurations to now use Blish HUD without native support.

https://gist.github.com/martinlabate/c4e6f08880a009f88dc1edaa4c6cd87a

It does involve some jank, but for those that really want it, it's an option.

Running on Linux is likely not to be a direct goal of the core rewrite now as there are other difficulties running natively (such as dealing with mumble).

hi i tried following guide and it is no longer a black screen and i can use guild wars 2 behind it somewhat, mouse only no keyboard. problem is every second or so its as if blish-hud goes from minimize to full screen and takes away focus from guild wars 2 making it impossible to really do anything. i have the exact same kde window rules set as in the guide. can you help please?

[dlamkins]

There is a portion in the guide related to making Blish HUD not intercept mouse input.

In any case, we aren't really able to provide Linux assistance. You may be able to get help asking for help on the guide itself.

[fmazur]

The latest releases do run on Linux, but are still opaque due to the issue I mentioned above. This guide below provides a way for those on Linux with certain configurations to now use Blish HUD without native support.

https://gist.github.com/martinlabate/c4e6f08880a009f88dc1edaa4c6cd87a

It does involve some jank, but for those that really want it, it's an option.

Running on Linux is likely not to be a direct goal of the core rewrite now as there are other difficulties running natively (such as dealing with mumble).

Bare minimum support for Linux would allow many people to use this software. With .net5 migration I'd assume transparency would be properly handled on Linux with compositors(maybe specific backend?) with should be enough to play comfortably with the overlay always on. There are many utilities in Blish that make big difference in the enjoyment of the game. I've played a lot with Blish on steam deck and all addons I needed worked just fine. The issue was with properly setting it up so the controls don't get intercepted by Blish. This means core functionality works fine on Linux and the issue is with:

• overlay transparency not being handled properly by compositors( which can be partially solved by telling compositor to reduce opacity of specific window - Blish and then increase gamma ingame)
• focus being stolen by overlay ( this is the biggest issue preventing actually using the Blish )
• overlay not staying on top or not attaching to Guild Wars 2 window due to being a separate window(not an issue on tiling window manager like i3wm as Blish can "float" above Guild Wars 2 window)

The guide you referred to requires kwin(KDE compositor) rule to not accept any focus by Blish overlay and to keep Guild Wars 2 window always below the overlay which might but usually can't be accomplished by other compositors.

Maybe there is a possibility to include Blish setting to accept focus when key combination gets pressed? I've seen this behavior being useful in differentiating focus target here: https://github.com/SnosMe/electron-overlay-window . There is a demo included maybe worth looking into this to support Linux? Looking at implementation it seems to attach to a process by title without being a separate window which would solve issues with windows fighting who's on top.

As for dealing with mumble - as long as Blish runs on same prefix(pfx in case of steam) and wineserver version then it's fine with all communication. On steam deck guide for Blish the script starts Blish with the same prefix and wineserver version so mumble communication works. For it to work on PC there are few ways:

• create similar script to run alongside the game (annoying if we want to run game without the overlay as currently with overlay we need to adjust gamma due to translucent black tint overlay)
• run after Guild Wars 2 starts(wineserver hangs if its in reverse order). There is a guide on how to run application using same prefix and wineserver and wine/proton version on Burrito page https://burrito.orthogonalprojects.com . Guide is for lutris but it's easy to adjust it to work with steam once config gets generated for the guide that's why I mentioned pfx earlier. (better way as overlay can be run on demand)
• run with steamtinkerlaunch?

[dlamkins]

The latest releases do run on Linux, but are still opaque due to the issue I mentioned above. This guide below provides a way for those on Linux with certain configurations to now use Blish HUD without native support. https://gist.github.com/martinlabate/c4e6f08880a009f88dc1edaa4c6cd87a It does involve some jank, but for those that really want it, it's an option. Running on Linux is likely not to be a direct goal of the core rewrite now as there are other difficulties running natively (such as dealing with mumble).

Bare minimum support for Linux would allow many people to use this software. With .net5 migration I'd assume transparency would be properly handled on Linux with compositors(maybe specific backend?) with should be enough to play comfortably with the overlay always on. There are many utilities in Blish that make big difference in the enjoyment of the game. I've played a lot with Blish on steam deck and all addons I needed worked just fine. The issue was with properly setting it up so the controls don't get intercepted by Blish. This means core functionality works fine on Linux and the issue is with:

• overlay transparency not being handled properly by compositors( which can be partially solved by telling compositor to reduce opacity of specific window - Blish and then increase gamma ingame)
• focus being stolen by overlay ( this is the biggest issue preventing actually using the Blish )
• overlay not staying on top or not attaching to Guild Wars 2 window due to being a separate window(not an issue on tiling window manager like i3wm as Blish can "float" above Guild Wars 2 window)

The guide you referred to requires kwin(KDE compositor) rule to not accept any focus by Blish overlay and to keep Guild Wars 2 window always below the overlay which might but usually can't be accomplished by other compositors.

Maybe there is a possibility to include Blish setting to accept focus when key combination gets pressed? I've seen this behavior being useful in differentiating focus target here: https://github.com/SnosMe/electron-overlay-window . There is a demo included maybe worth looking into this to support Linux? Looking at implementation it seems to attach to a process by title without being a separate window which would solve issues with windows fighting who's on top.

As for dealing with mumble - as long as Blish runs on same prefix(pfx in case of steam) and wineserver version then it's fine with all communication. On steam deck guide for Blish the script starts Blish with the same prefix and wineserver version so mumble communication works. For it to work on PC there are few ways:

• create similar script to run alongside the game (annoying if we want to run game without the overlay as currently with overlay we need to adjust gamma due to translucent black tint overlay)
• run after Guild Wars 2 starts(wineserver hangs if its in reverse order). There is a guide on how to run application using same prefix and wineserver and wine/proton version on Burrito page https://burrito.orthogonalprojects.com . Guide is for lutris but it's easy to adjust it to work with steam once config gets generated for the guide that's why I mentioned pfx earlier. (better way as overlay can be run on demand)
• run with steamtinkerlaunch?

Please see the comments in this thread: https://github.com/blish-hud/Blish-HUD/discussions/873#discussioncomment-6298349

Running native on Linux is not the hard part nor is it the immediate solution, I'm afraid.