Question Addressables prebuilt data during development

I'm sure some of you saw the recent video from the Unity youtube channel:

In short, they are using prebuild asset bundles during development with only a few team members actually having the source assets of those bundles in the project.

I've managed to replicate some of the functionality using Addressables:

• Got configurable symlinks that activate/deactivate an "asset package"
• Got those "asset packages" to automatically create their own Addressable groups
• Hacked together a way to only import some of the project and get working

Now I've been having some issues with the whole process and there are a few kinks that could make this setup very good!

Issue #1 (the worst): Addressables is hardcoded to Library/com.unity.addressables if I want to make it somewhat seamless. For very obvious reasons, the Library folder is not versioned on source control. If I want to share prebuilt bundles with the rest of the team, then I need to somehow take them out of the "Library" folder. I can configure said groups to be outputted in a different folder with some messing around with the group location variables, but some of the data remains within the Library folder regardless.
Solution: Create a symlink from Library/com.unity.addressables to AssetPacks. This is not ideal since the symlink needs to be there when I reimport a project before the addressables system is imported. Otherwise it won't let me set PlayMode Script to "Use Existing" because "I need to build the assets first" even tho the assets are already there and symlinked properly.

Issue #2: "Removing" the source assets of those assetgroups also removes them from the asset groups. It would be nice to still have the list there so you can lookup paths for certain assets and have them show up in red, or with "missing reference" instead of completely clearing the entries.
Solution: Haven't found one so far. I guess I could copy the entire groups structure to my own asset for lookup purposes. If the addressables system even works in the editor, then I could probably extend that to a browser for prebuilt bundles, but that seems like a lot of work.

Issue #3: Some settings are not kept when deleting Library (or importing a fresh copy of the project). For example Play Mode Script is not set to "Use Existing" and Addressables settings loses the "Group using dashes" setting. I am not sure where those are saved, but I assume somewhere in "Library" that is outside the addressables folder
Solution: Manually turn those settings back on after importing a projects, which is bound to cause issues for designers which might forget about those things.

Another issue not entirely related to addressables would be that shaders from assetbundles are precompiled for the target platform and won't work on windows in the editor. The current solution is to go through all the renderers and replace shaders but that's not exactly elegant. It would be nice to have a better way to get the editor-compatible shaders by default when running from the editor.

 

@jimanjr Hi, your solution really called my attention, I'm trying to achieve a similar result. My goal is to have a pure asset project, to make the experience of editing files seamless to project configuration.

I managed to have an external project with all of my addressable assets in it and using symlinks the main project is capable of seeing what it needs to make configurations and build the game in the editor.

But I stumbled on another issue: our CI system. We use Jenkins to have continuous integration and I can't figure the best way to build the final project without having to commit the asset bundles within the repo. Did you cross any issue like that?