Dependencies seem to be "Editor-based" and therefore misleading

[JashanChittesh]

TL;DR: It seems that the dependency-tree used by AssetBundles-Browser is based on "editor-mode" resulting in plenty of misleading dependencies being reported by the tool because those dependencies would never exist in an actual build because they are "editor-only".

I'm kind of new to using AssetBundles so I may be missing something but I tried to use this tool to cleanup our AssetBundles and noticed something that seems to make the tool unusable for its standard use case:

We had some ScriptableObjects defining meta-data for scenes and had editor-only properties (using conditional compilation based on UNITY_EDITOR) referencing the SceneAssets for convenience (we then store those references by name as strings to be used during runtime). As the references are editor-only, the actual scenes should never be included in a build. However, it very much seemed as if AssetBundles-Browser included those references, basically resulting in everything from those scenes being auto-included in bundles that actually only had the ScriptableObjects included. For now I have commented those properties out as a workaround.

However, when trying to do a build, Unity complained about LightingData.asset being included in several AssetBundles as an editor-only file. The only reason it was included was because AssetBundles-Browser shows these files as being auto-included and giving me warnings because it would include them in multiple bundles (even though those actually would never really be included in an AssetBundle-build because they are editor-only files).

Finally, the tool also has some scenes "auto-included" in other bundles, resulting in scenes and assets being mixed in my "all-shared"-bundle that I use for assets that the tool tells me are included in many other bundles.

I haven't quite figured out why that specific scene was included; it might be that Unity still had the reference from the ScriptableObject even after I had commented the actual code out.

[alffanclub]

Hi @JashanChittesh, thanks for trying out the tool. You cover a few things here, so let me comment...

• As to the dependencies shown in the tool, I had never tested editor-only dependencies, but I am not surprised that they'd show up in the dependency list. The only way I could think to avoid that would be to re-compile the scripts repeatedly while you were editing things. That would be very costly to the performance of your editor, and I'm not even confident the appropriate interfaces are exposed for me to do it. Which means you'll either need to not have editor-only dependencies in your code, or just accept that some things will show up in the browser that don't reflect reality.
• Which brings me to the next item: the dependencies listed in the browser in no way affect the dependencies pulled in during build. The browser dependency listing is merely a "preview". There is a "build" tab, but it is a very bare-bones build that relies on Unity internal dependency calculations. You are welcome to use the provided build, or your own, but in neither case will the browser's dependency data drive the result. The browser allows you to set/alter/whatever the explicit bundle assignment, and then it takes it's best guess at dependencies, based on those assignments. So your LightingData.asset will not ever be included "because AssetBundles-Browser shows these files". The browser shows the files because it thinks they will be included. It could definitely be wrong, but it never causes itself to be right. If those files are included, then it just means the browser happened to be correct in its prediction. Either the LightingData is explicitly included in a bundle, or Unity has somehow determined that it is a needed dependency for the player.

So all in all, it sounds like you have two different problems. One is that you are including editor-only dependencies and the browser doesn't handle that well. The other is that you are getting some dependencies built into your bundles that you were not expecting. The first problem is one we're somewhat stuck with, but it should not affect build results. The second problem is one that hopefully the browser can help you debug, but may require you to use your own build code. Keep in mind, you can use the "Configure" tab of the browser without ever using the "Build" tab should you want to. Thanks again for trying the tool out. Hopefully this explanation will help make the tool more useful to you. -Bill

[JashanChittesh]

Hi Bill, thank you for the explanation, that does clarify things!

Maybe I really misunderstood the purpose of the tool. When using the tool without being aware of its limitations, a very obvious (and in theory really great) workflow is: You set up a few AssetBundles, have the tool show which files are automatically included in multiple AssetBundles and create new, shared AssetBundles from that list so that it's all clean and tidy.

Unfortunately, with the given limitations you cannot do this without manually checking more or less every single asset. Otherwise, you can easily end up in a situation like me, where you explicitly add a LightingAsset to a bundle (to prevent the warning from the AssetBundle-browser). Or, you might explicitly include plenty of assets that the game actually doesn't even need during runtime. And worse: If you don't, you get warnings telling you something is wrong, while actually, everything is just perfectly right.

At the moment, it very much looks like there is no way for me to get AssetBundles without warnings because the warnings really are misleading (the tool tells me I have LightingAsset and plenty of other assets included in multiple bundles, while those assets really would never be included in first place).

To give another example: I have one bundle that just includes a few of said meta-files (which no longer have any actual scene references but that's possible something that could be fixed by deleting the library and letting Unity re-import everything). The actual built bundle has 14MB. It is compressed, so that's not the actual size ... but ... AssetBundle-browser tells me this thing has 3.58 GB due to the automatically included assets, plus it has a dependency on almost every other bundle in my project (I'd say about 30 bundles). Fortunately, the assets are not really included (otherwise the built bundle would be much larger) but for some mysterious reason, Unity does add a lot of bundle dependencies, even after I have deleted and re-imported the library (hoping to remove any cached dependencies that actually are no longer really there).

In the documentation, these issues are not really made explicit and to be honest, I think this would even deserve some "warnings" in the UI because of how severely misleading the preview can be. In other words, have a red warning text right on top of that Window that says "What you see here is a best effort preview from within the editor that may or may not match what an actual build may look like. Use with caution!"

Maybe a better approach would be primarily using the actual built asset bundles, as described here: https://support.unity3d.com/hc/en-us/articles/115000355246-Which-Assets-are-included-in-an-Asset-bundle- ... and a more detailed description of why a specific bundle is included, like here: https://github.com/dantreble/AssetBundleEditor (as far as I can tell, AssetBundleEditor also uses the editor dependencies but at least it tells me the exact path due to which any given asset is included in a bundle).

[cfoulston]

I'm getting this as well. I have editor icons for some classes and those icons are being flagged as included in multiple bundles :(

I understand the limitations, and yes the assets are not actually included in any bundles. But is there a way to check if a certain asset resides within an "Editor" folder, or a child of an "Editor" folder and ignore it? Basically every bundle shows me a warning, and it's a bit of a pain to filter out these false positives

For now I'm just creating an "editor" bundle and moving all editor stuff in there. Then I just remove from the main manifest and delete the bundle manually. No idea if this creates an issue with the CRC. So far It works, but not ideal.