[Solved] Why every store base implementation is included in Stores.dll?

[MHM90]

Hi,

I was wondering if someone wants to build its game only for a platform (for example iOS) why should he include all the dlls for other platforms (Tizen, WinRT, Android, etc) from package import!
When I removed extra platforms store’s dll, I ran into this:
ArgumentException: The Assembly winrt is referenced by Stores (... Stores.dll)
I was looking in “Stores.dll” and I found out that every platform has a base implementation on it in addition to separate dlls for each specific one. I think it is easily possible to make every platform module register itself to core logic in “Stores.dll” instead of adding each module base in “Stores.dll”. User can activate his target platform with a simple #if directive on initialization process (for example create specific platform store handler impl from platform specific dll and register it using ConfigurationBuilder). I mean why Stores.dll should depend on other platform dlls. It must provide the required interfaces and the implementation should be in other store dll files.
Also, I wanted to know if there is anyway to remove all the plugin in specific app build without deleting the whole plugin and just by not referencing to any of these dlls in my scripts using some #if directive?

Thanks

[JeffDUnity3D]

The other platform dlls that Stores.dll references are only stub dlls, and very small with no actual code. This is to keep the number of changes needed at build time to a minimum.

[MHM90]

@JeffDUnity3D

The other platform dlls that Stores.dll references are only stub dlls, and very small with no actual code. This is to keep the number of changes needed at build time to a minimum.

OK. I don’t know your build workflow, but, is it possible to include this stubs in Stores.dll itself?
And, what about my second question:

@MHM90

wanted to know if there is anyway to remove all the plugin in specific app build without deleting the whole plugin and just by not referencing to any of these dlls in my scripts using some #if directive?

It is just when I remove every reference to UnityPurchasing Api in my scripts and try to build a version without in-app purchase, it includes the full libs in the build.

[maxthecat]

We have a similar issue with needing to remove IAP for some builds and keep for others.

The solution we use is based on the following link

Where is the Unity IAP package located?

Look for the code in deleteAndDisableAIP()

We also delete the UnityChannel folder

FileUtil.DeleteFileOrDirectory( "Assets/Plugins/UnityPurchasing" );
FileUtil.DeleteFileOrDirectory( "Assets/Plugins/UnityChannel" );

// disable Unity IAP...
UnityEditor.Purchasing.PurchasingSettings.enabled = false;

[JeffDUnity3D]

@maxthecat I believe a safer solution rather than deleting files in code would be a proper #if directive. I’ll check with the IAP team here. I’m not sure how line 6 would execute reliably if you had already deleted the Plugins directory, unless the Purchasing object was already in memory.

[MHM90]

@JeffDUnity3D

I believe a safer solution rather than deleting files in code would be a proper #if directive.

What do you mean by #if directive? How could I make unity to avoid adding purchasing libs at build time by #if directive? I’ve already avoid referencing unity purchasing API in my scripts using #if directive if you mean it.

[JeffDUnity3D]

Yes, I meant I will check with the IAP team here to see if there is a way to properly use an #if directive or use another approach. Sorry for the confusion.

[maxthecat]

@JeffDUnity3D

@maxthecat I believe a safer solution rather than deleting files in code would be a proper #if directive. I’ll check with the IAP team here. I’m not sure how line 6 would execute reliably if you had already deleted the Plugins directory, unless the Purchasing object was already in memory.

Good point. I should move it to before deleting the folders.

I think line 6 is used to turn the Unity services off, and the code seems to be in UnityEditor.dll

Lines 2 & 3 are to ensure we don’t include unnecessary dll files. Using just a #define wasn’t satisfactory.

[JeffDUnity3D]

Can you elaborate regarding the need to not include the dll files? They are quite small.

[maxthecat]

@JeffDUnity3D

Can you elaborate regarding the need to not include the dll files? They are quite small.

Agreed, but anything to help make the final build size smaller helps.

[ap-unity]

@maxthecat

@maxthecat

Agreed, but anything to help make the final build size smaller helps.

This was brought up with the IAP team and having a more modular system is in their backlog, but I can’t say for sure when it would be available.

If you have any particular use case where this would be necessary (aside from reducing the build size and removing unused code, which are important reasons in and of themselves), it would be helpful for the team to understand your need.

[MHM90]

@ap-unity

If you have any particular use case where this would be necessary (aside from reducing the build size and removing unused code, which are important reasons in and of themselves), it would be helpful for the team to understand your need.

We work with specific publisher which has this rule not to include any in app purchase system in your code. They know we are not using it in any place of our game, but the code is included in the build.

[maxthecat]

@MHM90

We work with specific publisher which has this rule not to include any in app purchase system in your code. They know we are not using it in any place of our game, but the code is included in the build.

We have the same rule.

[JeffDUnity3D]

Which publisher is enforcing this rule? I checked with the IAP team, and the consensus is that such a change would be too risky unless we have strong evidence to support this need. In the meantime, you could consider separate projects or separate builds.