Repository navigation
GameInput dll version via interface #105
Description
Hello,
Due to various amount of issues that can be found between lib versions, it would be really nice to have access to exact version of library/IGameInput object loaded upon CreateGameInput call.
It can benefit us (devs) in a way, so that we can ask end user to update library to avoid some issues, or notify our codev teams about potential issues, during development.
For example, release 2.1 contains issue background input handling, so in mine case for example our Editor can't handle inputs from controller, due to how composition of simulation window and editor works (basically simulation for lib looks like background process). Luckily issue been fixed in 2.2 release of GameInput lib.
However, as of right now there is no way, code can identify which version of dll was loaded (other than hacks), so my department has constant false positive issues about controller not working. It's nice that redist can be loaded with newer lib implementation with backward support, but at the same time it's a curse XD
I've seen that in latest nuget 2.2(https://nuget.info/packages/Microsoft.GameInput/2.2.26100.6110) at "native/lib/x64/GameInput.cpp" there was some example of hack, which allows to determine which lib version was loaded. But I'm not keen in a slightest to do that manually on our end, when it's basically already available on Lib side.
So is it possible to add this as a feature in next release?
Activity
AlexYatskov commentedon Sep 23, 2025
Hi tristam92 , is there a reason why you don't want to run the MSI installer as part of your application distribution? It would upgrade the existing installation of GameInput to what your application expects and do nothing if there is already something newer installed on the customer's PC.
tristam92 commentedon Sep 25, 2025
Hi, we don't have issue with running installer as part of game installation, since it can be part of distribution scripts.
However, during development phase, we don't always have such luxury, especially when we testing things in very limited environments. I've added where it was possible in our pipeline install steps, but still sometimes we need to know from logs what lib version was loaded.
Even simple case, let's assume, that we have issue on retail. We getting some logs/telemetry with issue, but we can't quickly and directly determine which version of lib was loaded. If, as you say, newer version can be loaded, with older code, than newer version can contain issue, that we can't even predict, without really trying every version. Users not always willing to share what they have, or even can be reached.
But direct runtime value can be easily sent via telemetry/logs and ease debugging.