[Case 113800][Case 1131047][0.6.7] Fails to build bundles because of Exception

What is the actual purpose of packed separately? I first thought it would generate one bundle per addressable asset but actually it still generates a single bundle.

Is this bugged or am I missing something? The tooltip sounds like it should do exactly what I want it to.

 

@rachelgarza We can provide a project. Please see the bug report in Case 1138008. In short: The AAS 0.6.7 fails with a exception because some path is wrong. This means we can neither create the player data successfully nor delete the AAS cache. I assume this is the reason why the pack separately fails. It likely does not even delete the bundle created earlier and never creates new ones.

Code (CSharp):

1. [Exception] FileNotFoundException: Library/BuildCache/17/9c65772f0dc2f81c94c8ec335c985829/prefabs_assets_assets/addressableassets/prefabs/furniture/tische/buffettischrechteckiginkl.skirting(tischrechteckig76x76x76)/gomi_tisch_rechteckig_183x100x76.prefab.bundle does not exist
2. File.Copy()    <d7ac571ca2d04b2f981d0d886fa067cf>:0
3.  
4. ArchiveAndCompressBundles.SetOutputInformation()    Library/PackageCache/com.unity.scriptablebuildpipeline@1.3.5-preview/Editor/Tasks/ArchiveAndCompressBundles.cs:197
5. 195:       var directory = Path.GetDirectoryName(finalPath);
6. 196:       Directory.CreateDirectory(directory);
7. -->197:       File.Copy(writePath, finalPath, true);
8. 198:   }
9. 199:   m_Results.BundleInfos.Add(bundleName, details);
10.  
11. ArchiveAndCompressBundles.Run()    Library/PackageCache/com.unity.scriptablebuildpipeline@1.3.5-preview/Editor/Tasks/ArchiveAndCompressBundles.cs:182
12. 180:       }
13. -->182:       SetOutputInformation(writePath, details.FileName, bundleName, details);
14. 183:   }
15.  
16. BuildTasksRunner.Run()    Library/PackageCache/com.unity.scriptablebuildpipeline@1.3.5-preview/Editor/Shared/BuildTasksRunner.cs:50
17. 49:   ContextInjector.Inject(context, task);
18. -->50:   var result = task.Run();
19. 51:   if (result < ReturnCode.Success)
20. 52:       return result;
21.  
22. GenericMenu.CatchMenu()
23.  

Deleting /Library or /Obj does not help and I also tried to recreate all groups and delete the AAS completly and reimport 0.6.7 cleanly.

Updated the thread title to reflect what actually is happening.

 

@rachelgarza it seems like this is related to the insanely long paths generated by the unity system. I moved the project to c:\r\vrame\ to see if shortening the path helps and pack separately generated the bundles there. However, it still has problems:

It is unable to find C:\r\vrame\Temp\com.unity.addressables\AssetBundles\prefabs_assets_assets\addressableassets\prefabs\furniture\tische\buffettischrechteckiginkl.skirting(tischrechteckig76x76x76)\gomi_tisch_rechteckig_183x100x76.prefab.bundle

With the exception

Code (CSharp):

1. [Exception] DirectoryNotFoundException: Could not find a part of the path "Temp/com.unity.addressables/AssetBundles\prefabs_assets_assets/addressableassets/prefabs/furniture/tische/buffettischrechteckiginkl.skirting(tischrechteckig76x76x76)/gomi_tisch_rechteckig_183x100x76.prefab.bundle" or "Assets/StreamingAssets/aa/StandaloneWindows64\prefabs_assets_assets/addressableassets/prefabs/furniture/tische/buffettischrechteckiginkl.skirting(tischrechteckig76x76x76)/gomi_tisch_rechteckig_183x100x76.prefab_f097b126842467138ce0e7efce54b35c.bundle"
2. File.Copy()    <d7ac571ca2d04b2f981d0d886fa067cf>:0
3.  
4. BuildScriptPackedMode.PostProcessBundles()    Library/PackageCache/com.unity.addressables@0.6.7-preview/Editor/Build/DataBuilders/BuildScriptPackedMode.cs:424
5. 422:           if (!Directory.Exists(Path.GetDirectoryName(targetPath)))
6. 423:               Directory.CreateDirectory(Path.GetDirectoryName(targetPath));
7. -->424:           File.Copy(Path.Combine(assetGroup.Settings.buildSettings.bundleBuildPath, originalBundleName), targetPath, true);
8. 425:       }
9. 426:   }
10.  
11. BuildScriptPackedMode.BuildData[TResult]()    Library/PackageCache/com.unity.addressables@0.6.7-preview/Editor/Build/DataBuilders/BuildScriptPackedMode.cs:183
12. 181:       List<string> bundles;
13. 182:       if (aaContext.assetGroupToBundles.TryGetValue(assetGroup, out bundles))
14. -->183:           PostProcessBundles(assetGroup, bundles, results, extractData.WriteData, runtimeData, locations);
15. 184:   }
16. 185:   foreach (var r in results.WriteResults)
17.  
18. AddressableAssetSettings.BuildPlayerContent()    Library/PackageCache/com.unity.addressables@0.6.7-preview/Editor/Settings/AddressableAssetSettings.cs:1416
19. 1414:       EditorUserBuildSettings.activeBuildTarget, EditorUserBuildSettings.development,
20. 1415:       ProjectConfigData.postProfilerEvents, settings.PlayerBuildVersion);
21. -->1416:   var result = settings.ActivePlayerDataBuilder.BuildData<AddressablesPlayerBuildResult>(buildContext);
22. 1417:   if(BuildScript.buildCompleted != null)
23. 1418:       BuildScript.buildCompleted(result);
24.  
25. AddressableAssetsSettingsGroupEditor.OnBuildPlayerData()    Library/PackageCache/com.unity.addressables@0.6.7-preview/Editor/GUI/AddressableAssetsSettingsGroupEditor.cs:233
26. 231:   void OnBuildPlayerData()
27. 232:   {
28. -->233:       AddressableAssetSettings.BuildPlayerContent();
29. 234:   }
30.  
31. GenericMenu.CatchMenu()    C:/buildslave/unity/build/Editor/Mono/GUI/GenericMenu.cs:121
32.  

However the file actually exists at this path:


The longest path throwing an exception before was 290 characters long, now this path is <230 characters long.

 

I know this is an old thread, but I just want to chime in since I experienced a very similar issue in a much later version of Addressables (v1.21.2).

I was constantly having big build sizes after I migrated my project to Addressables. Even after I removed many unused addressable entries from my groups, the build sizes always seemed to become larger instead of smaller.

Turns out there were some previously generated asset bundles with very long filepaths (their addressable groups were set to Pack Separately), and Unity's addressable build process wasn't able to delete those files and folders from the build cache/Gradle cache.
So, Unity ended up adding those unused "ghost bundles" from the build cache to my builds.

I had to manually delete the build cache folder (in my case, the "Library\Bee\Android\Prj\Mono2x\Gradle" folder) to get rid of those ghost bundles with long paths.
But after that, shortening the addressable names (for instance, using the "Simplify Addressable Names" option) fixed the cache issue. I think this is the true fix for @MNNoxMortem's original bug.

Then, if I remove any addressables from my addressable groups, or if I change any groups' Bundle Mode from "Pack Together" to "Pack Separately" (or vice-versa), Unity's addressable build process is able to delete the unused bundles correctly, as their paths are much shorter.

Related post regarding the long paths issue:
https://forum.unity.com/threads/add...generated-asset-bundles.1104511/#post-7109326