.NET Framework vs .NET

[Dean Anderson]

As most of you probably know, a year or two ago (*checks calendar* Oh my God it was 2018. That was four years ago!) I ported Cthangband over from C to C#.

At the time I used the .NET Framework 4.5.2.

This was fine, and it was a big improvement to the code. However, it did come with a couple of drawbacks - the big one being that the .NET Framework was (and still is) Windows only, so none of the versions of Cthangband since then have been ported (or even portable) to other platforms. The other major drawback was that for a .NET Framework application to run you need to have the correct version of the .NET Framework installed on your machine, and that makes installation and running of Cthangband more awkward.

However, since then Microsoft have done various things with their language platform. Around the time I was porting Cthangband to use the .NET Framework, Microsoft branched the platform into two - the .NET Framework, which was full-featured but Windows only; and .NET Core, which was cut-down but more platform independent.

Fast forward to now, and those two branches have re-merged. Instead of the .NET Framework and .NET Core being two separate platforms, we just have the single .NET 5 (and in the last couple of months, the new .NET 6) platform which has (almost) all the functionality of the .NET Framework - except for a few Windows-specific bits - and is even more portable than .NET Core.

So I'm thinking of migrating Cthangband from .NET Framework 4.5.2 to .NET 6.

As far as I can tell from some preliminary work, the big pros and cons of that are:

Pros

• I can compile for Windows, MacOS and Linux from the same source and IDE (I think I can anyway, since I don't have MacOS or Linux I've not been able to test the results). This means that Cthangband can be multiplatform again.
• .NET 6 allows you to statically link the .NET libraries into your executable, meaning that you can provide a simple .exe (or equivalent for other platforms) that just runs without people needing to download and install the .NET Framework separately.

Cons

• Cthangband is object oriented, and the whole game state is stored as an object tree with quite a few circular references. In the .NET Framework, I can save the entire game state in a half-dozen lines of code by using Binary Serialization. Unfortunately for me, Binary Serialization has been deprecated and is not included in .NET 6. There are perfectly good security reasons why Binary Serialization was removed, but those reasons don't really apply to Cthangband using it for save-games. If I move to .NET 6 I'm going to have to save the entire object tree by hand into a save file, and that is going to be a lot of effort to write and is going to introduce a lot of scope for bugs and errors.
• The Cthangband documentation is in HTML format, and is viewed from a within-game web browser. You guessed it - the web browser control is deprecated and isn't included in .NET 6. Again, this is for security reasons (the browser control was IE6 based). If I'm porting to .NET 6 I'm going to have to find a replacement.
• Cthangband currently used a third-party dll for playing sound and music called irrKlang. I don't yet know whether that is .NET 6 compatible or whether I'll have to change to something different.

So, there are a bunch of developers here - many of who have C# experience. Does anyone know of any other big problems I might face porting from .NET Framework 4.5.2 to .NET Core 6? And does anyone have any suggestions for alternatives for serializing an object tree and displaying the manual? Any other comments or observations about .NET 6 and portability?

[AnonymousHero]

Regarding the seralization. Is there no reflection-based serialization that would do the trick? I know almost nothing about .NET, but I do know that there are quite a few in JVM-land and it would surprise me if there weren't in .NET land.

[Dean Anderson]

There is JSON based serialization, and XML based serialization, but as far as I can see they both have limitations when it comes to things like collections and generic types - or at least they did in .NET 5. It looks like the JSON serialization at least has been improved in .NET 6; but I've not had chance to investigate yet.

[AnonymousHero]

There is JSON based serialization, and XML based serialization, but as far as I can see they both have limitations when it comes to things like collections and generic types - or at least they did in .NET 5. It looks like the JSON serialization at least has been improved in .NET 6; but I've not had chance to investigate yet.

I see. I'd bet that JSON serialization + e.g. zstd compression should do the trick nicely. (Circular references in data structures can be tricky tho, but I'm guessing there's some way to handle that.)

[Pete Mack]

It sounds like a great idea. Are there after-market serializers available?

[Dean Anderson]

So, I've done some more research, and as is so often the case with Microsoft the initial claims seem to be more marketing fluff than reality.

In practise, you can write fully portable code in .NET 6, but only if you stick to simple console apps with no UI.

If you want to write apps with a UI, you have basically three choices...

1) Windows Forms or Windows Presentation Framework (WPF). These are the standard UI options for the older .NET Framework, and they are what Cthangband currently uses. Specifically, Cthangband uses WPF, because (unlike Windows Forms, which is very old and only kept going for backwards compatibility) WPF takes advantage of hardware acceleration. While you can still write Windows Forms apps or WPF apps in .NET 6, they are Windows-only, so if you use them in your application it stops being portable.

2) Multi-platform Application User Interface (MAUI). This is the new UI library for .NET 6, and is an expansion of the older third party Xamarin. It is portable, but designed for mobile rather than desktop, so the choice of platform is Android, iOS, or Windows. It doesn't support MacOS or Linux (although I think you can use Mac Catalyst to run the iOS apps it creates on MacOS).

3) Blazor. I didn't look into this too deeply, but it seems to be Microsoft's new attempt at a web UI. It strikes me as probably having the lifespan and take-up of Silverlight, so I ignored it.

This is all rather disappointing, because none of the above give me a UI that can be used on Windows, MacOS, and Linux.

[Kinematics]

Another option is Australis, a 3rd party WPF-like UI framework that should give you Windows/Linux/MacOS capabilities. I've used it in a personal project, and while it's a little limited in what it has implemented, it seems to mostly work OK.