Target .NET 8

[xPaw]

Target for next major SteamKit version (3.0.0). This drops support for .NET framework.

[JustArchi]

Did you just kill .NET Framework my bro?!

[JustArchi]

Since @xPaw asked for statistics:

Based on latest ASF stable release, which was released 11 days ago:

• generic-netf, 197 downloads
• generic, 274 downloads
• linux-arm, 243 downloads
• linux-arm64, 1275 downloads
• linux-x64, 13791 downloads
• osx-arm64, 88 downloads
• osx-x64, 114 downloads
• win-arm64, 169 downloads
• win-x64, 13451 downloads

This makes .NET Framework ASF users around 0.66% of whole population. This doesn't take into account how many people actually run specified versions (and didn't just download them accidentally), but this is the stats I have.

Supportive statistics: I record user agent in ASF STM listing (ASF backend), out of 537 registered ASF instances there, 0 users run generic-netf, making it 0% of ASF STM bots population.

Worthy use cases for .NET Framework, to the best of my knowledge, include:

• Raspberry Pi 0 & 1, which are based on ARMv6 architecture, for which there is no .NET Core runtime/SDK released. Those platforms can't run .NET Core apps.
• Linux x86, for which Microsoft didn't release .NET runtime/SDK either.
• Exotic architectures and setups otherwise supported by Mono, which supports .NET Framework apps, but can't run modern .NET (Core) ones.

If SK2 team decides supporting .NET Framework, I recommend to take a look into my madness project which I use in ASF, that takes away major headache from ifdefs in the code and other crap, and allows rather seemingly to support targetting both modern .NET (Core) and .NET Framework at the same time.

My view: it should be determined by project maintainers how much headache they have from supporting .NET Framework. I won't cry if we kill it once and for good, considering it's deprecated and everybody who cares should have a setup capable of running .NET Core by now, but you need to realize that everybody running SK2 or SK2-based projects on e.g. Raspberry Pi 0 & 1, as well as Linux x86, will no longer be able to do that - so it's a decision to make, rather than acting like nobody uses it.

[JustArchi]

In other words: let's just kill net framework and standard and save our sanity.

[yaakov-h]

It’s been four years since https://devblogs.microsoft.com/dotnet/net-core-is-the-future-of-net/

Unless we have some exotic enterprise customer, .NET 8 LTS seems like a great time to make the jump.

Many other frameworks like asp.net core and powershell dropped Framework support years ago…

[yaakov-h]

Tentative approval for a v3.0.0 release after .NET 8 lands in 2 weeks time. We should probably bump the version in this PR too.

We should deal with the new Analyzer warnings as well. From discussions on dotnet/csharplang, I think the lowercase identifiers warning is one we should fix rather than suppress.

[xPaw]

I think the lowercase identifiers warning is one we should fix rather than suppress.

One of the warnings comes from generate proto.

Attribute parameter 'SizeConst' must be specified.

And I don't really know what to specify there.

[yaakov-h]

we control the proto generation, so we can tweak it as neccesary.

and yeah, I'm not sure what's with SizeConst either, I'd have to read up on it

[xPaw]

It's defined as DISK_EXTENT Extents[ANYSIZE_ARRAY];, ANYSIZE_ARRAY is 1.

https://devblogs.microsoft.com/oldnewthing/20040826-00/?p=38043

[xPaw]

we control the proto generation, so we can tweak it as neccesary.

So protobuf-net already has escaping code for all known language identifiers, If I modify that escape function to capitalize if the identifier is all lowercase, it will capitalize all fields. If I remove names=original option, that will also capitalize everything.

Created protobuf-net/protobuf-net#1106 to see what they think.

[yaakov-h]

Since it’s a C compiler shortcut into memory after the struct, I’m not so source that 1 is valid for marshalling.

[xPaw]

AdditionalParameters in the next struct defined it as 1 too, and its BYTE AdditionalParameters[1];, there's also a check for extents.NumberOfDiskExtents != 1

[voided]

LGTM. Agree with @yaakov-h on waiting for .NET 8 GA.

I posed this question on the SteamDB discord, but do we want to take this major version bump opportunity to make more sweeping changes? Like any wishlisted tech debt cleanup, project structure reorg, etc.

[xPaw]

We first need to release 2.5.0 anyway, so it will be a while before 3.0 releases (certainly after GA).

take this major version bump opportunity to make more sweeping changes?

You can if there's anything that needs doing, make issues for these? I have PR open to remove obsoletes. Yaakov was looking at switching to google protobufs for AOT stuff.

[yaakov-h]

Yep, as far as I can tell Google Protobuf is already trimmable and AOT-ready, and it has better support within the .NET ecosystem than protobuf-net does.

(protobuf-net has been blocking us with protobuf-net/protobuf-net#817 on not being trimmable for over two years, and I believe we could need to generate our own serialisation code to support AOT)

I'm not making any commitment to switching, but it's something I'm vaguely interested in and would also make sense for a v3.0 bump.

Potentially something else we could do is replace the KeyValue class with the VRF lib? 🙂

[xPaw]

Potentially something else we could do is replace the KeyValue class with the VRF lib? 🙂

That indeed would be good, but ValveResourceFormat/ValveKeyValue#30 needs solving first, ideally somehow making KeyValue a non-breaking change for consumers.

[xPaw]

NET8 is GA, rip framework.