rlabrecque
Making Steamworks.NET more AOT compliant
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.
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.
I've pushed #692 to discuss the backward compatibility. Happy to adjust and finish it if need be.
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 ...
@JamesMcGhee some people want to use the library without Unity. :) just doing some research, been awhile since I did steam stuffs.
@JamesMcGhee some people want to use the library without Unity. :) just doing some research, been awhile since I did steam stuffs.
Yes, my remark was that there is no reason to worry about older versions of Unity for this request because older versions of Unity are outside LTS and no longer supported by Unity the company ...
I was not suggesting that Unity should restrict anything ... quite the opposite ... I was suggesting Unity should NOT restrict this. We support Steamworks across multiple engines, including MonoDevelop and wholly bespoke works, so we are not promoting a Unity-centric POV.
I need to move #692 forward, but it's mostly about fixing warnings. Steamworks.NET works just fine with any .NET version, including PublishAot (we've been using it for ages this way). There will just be a "Steamworks.NET generated AOT warnings" message during compilation, but they are likely to be inconsequential.