# Distributing Fmod with a wrapper library
**URL:** https://qa.fmod.com/t/distributing-fmod-with-a-wrapper-library/16776
**Category:** Other
**Created:** [February 18, 2021, 6:30am UTC](https://qa.fmod.com/t/distributing-fmod-with-a-wrapper-library/16776 "2021-02-18T06:30:53Z")
**Posts on this page:** 5
**Page:** 1
### Author:  [@Sunkin351](https://qa.fmod.com/u/Sunkin351)
#### Post date: [February 18, 2021, 6:30am UTC](https://qa.fmod.com/t/distributing-fmod-with-a-wrapper-library/16776/1 "2021-02-18T06:30:53Z")
Continuing the discussion from [Nugget Package for FMOD low level binaries](https://qa.fmod.com/t/nugget-package-for-fmod-low-level-binaries/14772/3):
Sodanakin sums up my need pretty nicely. Its a bit of a hassle if Fmod API changes that are reflected in a wrapper library break because the user has an outdated version of the Fmod binary.
I would like to distribute the Core API binary with the wrapper. This would simplify the situation of the end user and create a much more hassle free experience.
To quote sodanakin:
> [@Nugget Package for FMOD low level binaries](https://qa.fmod.com/t/nugget-package-for-fmod-low-level-binaries/14772/3):
>
> I think if a disclaimer were to be added to the Nuget package / Github Repository regarding which version of Fmod the end user is dealing with and that Fmod is not responsible for any bugs, broken features etc, no extra support nor updating should be required as this is fully up to Sunkin to manage the repo and Update the dll with new releases.
I was wondering what I would need to do in order to get your guys’ approval on this. The wrapper itself is free and open source for anyone to use.
---
### Author:  [@brett](https://qa.fmod.com/u/brett)
#### Post date: [February 23, 2021, 12:06am UTC](https://qa.fmod.com/t/distributing-fmod-with-a-wrapper-library/16776/2 "2021-02-23T00:06:04Z")
> [@Sunkin351](#):
>
> Its a bit of a hassle if Fmod API changes that are reflected in a wrapper library break because the user has an outdated version of the Fmod binary.
This will never happen if the version used sticks to the major version number, as well as the users. An example is 2.01.xx (all xx changes are forwards and backwards compatible).
For the larger overall topic we are still deliberating, we not keen on unofficial distribution of the API for liability purposes. FMOD is not just a header and a binary, it is support, documentation, examples and more.
---
### Author:  [@Sunkin351](https://qa.fmod.com/u/Sunkin351)
#### Post date: [February 23, 2021, 6:38pm UTC](https://qa.fmod.com/t/distributing-fmod-with-a-wrapper-library/16776/3 "2021-02-23T18:38:41Z")
The biggest problem is that I’m not currently lazily loading symbols from the library here. This Causes it to not quite be able to target previous versions with ABI differences.
Also, another matter. Why is Fmod version checking tied to having an instance of FMOD\_System up and running? Shouldn’t version checking helpers be `static` methods?
---
### Author:  [@brett](https://qa.fmod.com/u/brett)
#### Post date: [February 24, 2021, 1:03am UTC](https://qa.fmod.com/t/distributing-fmod-with-a-wrapper-library/16776/4 "2021-02-24T01:03:05Z")
> [@Sunkin351](#):
>
> Why is Fmod version checking tied to having an instance of FMOD\_System up and running? Shouldn’t version checking helpers be `static` methods?
There are no ABI differences in a major version with all of its minor versions.
For static vs dynamic, it is theoretically possible that different versions of the library can coexist, ie through dynamic loading of the dll. This is more historical than anything else.
---
### Author:  [@Sunkin351](https://qa.fmod.com/u/Sunkin351)
#### Post date: [February 26, 2021, 6:03pm UTC](https://qa.fmod.com/t/distributing-fmod-with-a-wrapper-library/16776/5 "2021-02-26T18:03:16Z")
I’m switching up my loading scheme to be backwards compatible then, while still exposing new functions. Thanks for the replies!