Less invasive Any CPU implementation inspired by @Chicken-Bones #738
Conversation
Acheived by register a dll resolve hook to default Assembly Load Context. Changes are seperated into a different folder to keep old version unchanged.
|
|
|
Please let me know when I can find this on your mainstream NuGet :) |
|
I'd like to make correct steam binaries being distributed by Any CPU NuGet package, 1 PR within 10 lines estimated. |
|
Any update on this one? |
Steam native binaries are packed into |
|
If you want know when package Steamworks.NET will merge this, honestly I don't know. Neither me or Riley have push access to it. But Steamworks.NET.AnyCPU is own by me. That is, you can call me for merging upstream.
…---Original---
From: ***@***.***>
Date: Fri, Aug 29, 2025 07:45 AM
To: ***@***.***>;
Cc: ***@***.******@***.***>;
Subject: Re: [rlabrecque/Steamworks.NET] Less invasive Any CPU implementationinspired by @Chicken-Bones (PR #738)
Chicken-Bones left a comment (rlabrecque/Steamworks.NET#738)
Any update on this one?
—
Reply to this email directly, view it on GitHub, or unsubscribe.
You are receiving this because you authored the thread.Message ID: ***@***.***>
|
|
Thanks, I will fix this later.
…---Original---
From: ***@***.***>
Date: Fri, Sep 19, 2025 09:27 AM
To: ***@***.***>;
Cc: ***@***.******@***.***>;
Subject: Re: [rlabrecque/Steamworks.NET] Less invasive Any CPU implementationinspired by @Chicken-Bones (PR #738)
@Chicken-Bones commented on this pull request.
In com.rlabrecque.steamworks.net/Runtime/Steam.cs:
> @@ -56,6 +56,9 @@ public static class SteamAPI { // Returns true on success public static ESteamAPIInitResult InitEx(out string OutSteamErrMsg) { +#if STEAMWORKS_ANYCPU + BeAnyCPUCompatible();
You also need to install the hook in RestartAppIfNecessary since docs say to call this before ``SteamAPI.Init`
—
Reply to this email directly, view it on GitHub, or unsubscribe.
You are receiving this because you authored the thread.Message ID: ***@***.***>
|
Reasons are explained detailly inside comments. A debug message will also generate if confliction happens.
|
I'm not sure if there's a way to ship two different dlls based on OS via nuget. Such a pain... 
|
|
This is a known issue. I made a suggestion to remove this const in previous Any CPU implementation.
…---Original---
From: ***@***.***>
Date: Thu, Oct 2, 2025 11:08 AM
To: ***@***.***>;
Cc: ***@***.******@***.***>;
Subject: Re: [rlabrecque/Steamworks.NET] Less invasive Any CPU implementationinspired by @Chicken-Bones (PR #738)
Chicken-Bones left a comment (rlabrecque/Steamworks.NET#738)
#747
Packsize.value is being compiled as 4.
image.png (view on web)
—
Reply to this email directly, view it on GitHub, or unsubscribe.
You are receiving this because you authored the thread.Message ID: ***@***.***>
|
|
Sinply removing it probably won't work, because it's required to be 4 on osx and linux, despite the default abi for x64 and arm64 on those platforms being 8 |
|
That's an unfortunate message. How about generate custom marshaller by our codegen?
…---Original---
From: ***@***.***>
Date: Thu, Oct 2, 2025 21:19 PM
To: ***@***.***>;
Cc: ***@***.******@***.***>;
Subject: Re: [rlabrecque/Steamworks.NET] Less invasive Any CPU implementationinspired by @Chicken-Bones (PR #738)
Chicken-Bones left a comment (rlabrecque/Steamworks.NET#738)
Sinply removing it probably won't work, because it's required to be 4 on osx and linux, despite the default abi for x64 and arm64 on those platforms being 8
—
Reply to this email directly, view it on GitHub, or unsubscribe.
You are receiving this because you authored the thread.Message ID: ***@***.***>
|
|
Sounds like a viable approach. Shouldn't be too hard. Will make for the smallest package. Only easier way would be if you know how to ship different managed assemblies for windows and non-windows in a nuget package... |
|
I have managed to deploy a workaround where I replace the |
In my design, generated custom marshaller will remain both alignment at runtime, but only one will be chosen. By keeping them all we can still building single unified assembly. But... we still went to this place: make big changes to codegen and add massive amount of custom marshalling code. It is huge I think, after all this is related to all callback structs(even some parameters maybe). |
|
For callbacks, replacing Based on https://learn.microsoft.com/en-us/nuget/create-packages/native-files-in-net-packages it should be possible to make NuGet package structure like: Where |
If we want to ship different assemblies for different platform, it's possible, and we already achieved this goal, But we have to manually write MSBuild script and NuGet specification file, then execute them by some long and complex commands, which is not easy to type correct in once. This hard way is probably how they build package Return to our subject, when I created this any CPU variant, I decided to simplify packaging workflow into one command: To achieve this goal, we must discard manually written But I have to say, through we can inherit old NuGet workflow from Standalone2.0, this is a chance to embrace revolution. Please let me know which path should we continue. React Anymore, |
|
Regrettably, I vote for custom marshalling. Maybe with clever sourcegen we can produce pack=4 variants of the structures only when pack size actually makes a difference to the layout. Then all native methods which rely on these will need 2 definitions, and a wrapper to type convert depending on platform |
|
I've try to fix by wrapper struct, but I met some problems. Callback retrieval is mostly fixed I think, but those struct directly passed into a interface parameter is still a problem, I can't intercept it's marshal process. We may still have to go old way: ship different assemblies. Here is the fix proposal Akarinnnn#1 . |
…or 'prod' environment
…CPU (#2) Adds a simple workflow for packing the Steamworks.NET.AnyCPU nuget package and publishing it to nuget.org. Currently only run on manual run of the workflow. The workflow uses nuget.org's newer [trusted publishing ](https://learn.microsoft.com/en-us/nuget/nuget-org/trusted-publishing) so there is a step for the owner of the nuget package on nuget.org to do as well as the action variable of NUGET_USER. Its not a secret but this allows another to use the action without it hard coded. Ideally, we get to be able to publish a beta branch through the workflow to make sure it works.
Merge changes from upstream to keep us up to date. It's here because #3 merged into a legacy branch master.
3 participants
Originally posted in #699. Achieved by register a dll resolve hook to default Assembly Load Context.
Dependencies to
AssemblyLoadContextmakes this change is not meaningful to any runtimes other than .NET(Core). So these changes are separated into a different folder to keep old version unchanged like .NET Framework 4.0 does.