Making Steamworks.NET more AOT compliant

[ThomasFOG]

Hello there,

Currently when using Steamworks.NET as a standalone lib for non-Unity projects on recent runtimes, there is a few AOT-related warnings.

These warnings are mostly on the usage of Marshal.SizeOf(typeof(SomeType)) and Marshal.PtrToStructure(), which can break in AOT'd or trimmed scenarios.

When it comes to Steamworks.NET itself, this is a non-issue because everywhere those marshalling methods are used, they are safe because the types marshalled are all visible by the compiler and never trimmed. So those warnings can be ignored.

But this will be misleading to anyone using Steamworks.NET on a modern runtime, because the compiler will tell users that Steamworks.NET generated IL warnings and may crash at runtime when PublishAot is used (although it won't, it sends the message to users that it might). To check those warnings, it is possible to add EnableAotAnalyzer to the .csproj, which will make the compiler to spit IL warnings even though PublisAot isn't used.

To fix those IL warnings, it is required to use generic versions of SizeOf and PtrToStructure, like Marshal.SizeOf<SomeType>(). Once every IL warnings are fixed, it could be possible to flag the library with IsAotCompatible in the .csproj to indicate to users that the library is safe for PublishAot (and likely also safer for Unity's IL2CPP).

Alternatively, but not recommended, it is possible to silence those warnings (with a pragma silencing IL3050) since they are some sort of false-positives.

I'd be happy to contribute that but the question is: how would you like to handle backward-compatibility?

Marshal.SizeOf<SomeType>() is available since .NET 4.5.1, which is totally fine for the standalone netstandard2.1, but will be a problem for Unity versions older than 5.6 (2017). A workaround would be to use preprocessing directives and duplicate those calls.

There are 17 warnings to fix, only a couple of them are in autogen/types.

Anyway, it's an easy fix, just thought asking before opening a PR.

[rlabrecque]

Only just skimming this quick; but it /may/ be the case that we've dropped support for pre-2017 Unity by now. Will have to double check. If that's the case then this makes a lot of sense.

[ThomasFOG]

I've pushed #692 to discuss the backward compatibility. Happy to adjust and finish it if need be.

[JamesMcGhee]

Only just skimming this, but it /may/ be the case that we've dropped support for pre-2017 Unity by now. Will have to double-check. If that's the case, then this makes a lot of sense.

Unity's oldest LTS (Long Term Support) is 2021.3.45f1
And it should be falling out of LTS soon, leaving the new oldest supported version as 2022.3.61f1

In short, by all means this should be no issue ...