Balzor Related Wiki Page

[EzioTheDeadPoet]

Wabbajack has a code problem, mainly that most of the libraries require net5.0-windows instead of net5.0. In addition, most of our libraries are Windows specific to a very low level. This is a general plan/braindump of how to restructure the app to be more cross platform.

• Refactor out Absolute and Relative Paths into their own library. - Wabbajack.Paths
  • Should contain Absolute, Relative and FullPaths
  • Make this library cross platform via enabling/disabling IO routines depending on the compile target
  • Most basic version should be able to do path manipulation but no IO (no OpenFile, ReadFile, etc.)
  • Should support both Linux and Windows formats
  • Ditch AlphaFS?
  • Use a segmented path, so we can easily translate from one path format to another
  • What's the cannonical storage format? \ or /?
• Refactor out hashing, and HashRelativePath into their own library - Wabbajack.Hashing
  • Disable IO code on non-IO platforms, leverage Wabbajack.Paths for all IO
  • Should support xxHash64, all the SHAs and CRCs
• Refactor out JSON serialization - Wabbajack.Serialization.Json
  • Must still load old JSON names, must somehow load .dlls that are not loaded
  • This means it will need to ignore the assembly part of the encoded type, relying only on JsonName.
  • Data emitted by this library need not be readable by other apps/versions of WJ
• Refactor out all DTOs - Wabbajack.DTOs
  • Must rely on .net5.0 be 100% cross platform
• Move Compression.BSA to Wabbajack.Compression.BSA
  • Remove WJ specific IO code
• Delete Wabbajack.Common.CSP - we don't need it

[EzioTheDeadPoet]

Since I don't know if this has still any relevance I moved it form the wiki into an issue that can be closed.

This is so that I can also add the wiki to the main repository, mainly because it is easier to find for most people if the wiki is located there.

[erri120]

You can ditch netX.0-windows by using the [SupportedOSPlatform]("windows") attribute on classes/methods that are OS specific or RuntimeInformation.IsOSPlatform(OSPlatform.Windows) in functions to provide different behaviors.

This is what I've done with GameFinder and now every GameFinder package targets net6.0/net7.0. Instead of directly accessing the Windows registry I created an interface IRegistry and guarded the Windows specific implementation behind an [SupportedOSPlatform("windows")]: https://github.com/erri120/GameFinder/blob/2c39db4ca3c1eca255774f53db2dd9b75ffa95f6/GameFinder.RegistryUtils/WindowsRegistry.cs

This also made testing easier since I can now create an In-Memory registry without any issues.

I used RuntimeInformation.IsOSPlatform for the Steam package since Steam official supports Linux:
https://github.com/erri120/GameFinder/blob/2c39db4ca3c1eca255774f53db2dd9b75ffa95f6/GameFinder.StoreHandlers.Steam/SteamHandler.cs#L171-L189

More infos here: https://learn.microsoft.com/en-us/dotnet/standard/analyzers/platform-compat-analyzer