Was there a resolution for this issue? We are experiencing the same problem.
Thanks,
Tom.
Was there a resolution for this issue? We are experiencing the same problem.
Thanks,
Tom.
We’ve created stub DLL’s (for Stores.dll and UnityEngine.Purchasing.dll) that we only have enabled for console platforms + we’ve disabled the official Stores.dll on those same platforms and this seems to workaround the issue for now.
We are still looking into the issue. Your approach is correct, but you would need to be careful to replace the Dll’s after an IAP upgrade.
Chiming in that we have a similar problem.
Editing the link.xml file in the script folder of the plugin can fix the linker issue by allowing it to ignore missing dlls. Add the ignoreIfMissing=“1” attribute to the assembly nodes. I’ve attached our link.xml.
It looks like if the linker fails to find the dll the entire chain is removed as I can’t find any trace of the purchasing dlls in our target platform’s build.
3554155–286001–link.zip (336 Bytes)
Same error here. Unable to set any flag for the Facebook dlls, making the project uncompilable on Nintendo Switch.
The work around from engineering has stated the following, although I am unable to test directly. All the steps might not be necessary in your tests, but might be good to walk through them first with the suggested empty project:
I finally managed to exclude FacebookStore.dll from unsupported platform. Basically, go into bin\Facebook and click on FacebookStore. Make sure it’s excluded and press Apply. If a dialog prompts you to apply again HIT REVERT. Select some other object that has an inspector to get the inspector off FacebookStore. Clicking a folder WILL NOT WORK. Click something like a material.
Then go into bin\Facebook\live and click FacebookStore. Make sure it’s excluded and press Apply. If the dialog prompts you again, HIT REVERT. Now, get the inspector off of the FacebookStore by selecting something else that has an inspector (I sometimes create an empty material in the “live” folder just so I can get the inspector off the FacebookStore.)
Now, go back to both FacebookStore.dll and make sure they are still excluded from your platform. They may magically be included for your platform again… turn them off again (maybe do the empty material trick.)
Amazing 3 years later this bug still exists. I believe there is some code that is actively monitoring FacebookStore.dll and when it detects changes it changes them back to some default or tries to link the live and non-live DLLs for some reason. But luckily it appears to be doing these modifications through the Inspector and the Inspector prompts if you want to take the changes.
Unity: 2019.3.0f6
EDIT: Sigh. My co-worker kicked off a build and FacebookStore.dll is back. Something added it back to the build even though it was working and checked in! This is more than frustrating. However, one trick that does work consistently for us is to rename the entire UnityPurchasing folder (assuming you don’t want any UnityPurchasing) to “Editor” before running a build, building, then naming the folder back to “UnityPurchasing”. This is clearly sub-optimal but…
@JeffDUnity3D is there a workaround that works for other platform types? Specifically, I want to exclude UnityPurchasing from WebGL builds (but have it enabled on Android and iOS.) But WebGL builds for some reason keep pulling in FacebookStore.dll even though it’s excluded for WebGL.
Thanks!
The current work around is to use separate projects, granted not ideal. We are hoping to improve this later this year.
That is not workaround at all! I Get this right guys!
Agreed! We just discussed this yesterday as a priority issue for an upcoming release, later this year.
Saying later this year in January is a bit frightening. Is there a trackable bug somewhere?
No public trackable issue that I’m aware of. But more specifically, in the April/May time frame.