Search Issue Tracker
By Design
Votes
0
Found in
2018.4
2019.4
2019.4.19f1
2020.2
2021.1
2021.2
Issue ID
1311295
Regression
No
All assets that are in the project are included as dependencies when exporting the asset as a package
Reproduction steps:
1. Open the user's attached project
2. In the project window, create a new C# script and call it "ATest" (or anything else)
3. In the project window, right-click on TestProjects/MoboFPS/GameScene scene and select Export Package
4. Observe the included dependencies
Expected result: "ATest" script and other assets that aren't in the GameScene scene are not included as dependencies
Actual result: "ATest" script is included as a dependency (together with other assets that are in the Project but not in the GameScene scene)
Reproducible with: 2018.4.31f1, 2019.4.20f1, 2020.2.4f1, 2021.1.0b6, 2021.2.0a4
Note: It does not reproduce with all assets:
1. Issue is not reproducible when exporting Material, Shader, empty Scene
2. Issue is reproducible when exporting Script, Scene that includes other assets
Add comment
All about bugs
View bugs we have successfully reproduced, and vote for the bugs you want to see fixed most urgently.
Latest issues
- Crash on when D3D12RenderPass::SetupDeviceResources when opening FBX animation preview
- Serialization errors are thrown when "com.unity.render-pipelines.core" is added as a custom package and Graphics window is opened
- Character Joints unexpectedly rotate when a ragdoll is created using the Ragdoll Wizard
- Crash on GfxDeviceD3D11Base::DrawBuffersBatchMode when rendering the Scene view
- The shared EditorBuildSettings.asset file of symlinked projects is not updated when changing the order of the Scenes in Build Settings in one of the projects
Resolution Note:
In the user's project the scene includes a GameObject with attached script to it, and that is why when you do "Export as a package" for that scene - all scripts are included as dependencies. The same happens if you do "Export as a package" on any script - it will show all scripts in the project as dependencies. The thing here is that we can't say what exact script can affect other scripts (for example one script uses type introduced in another script, or more complex scenarios), that is why we include all the scripts as dependencies - not perfect, but in this case we are sure that the package includes all dependencies.
The believe here is that most developers will not use "Include all dependencies" option as they know their real dependencies and will include them manually, again - not the best solution..., but the one we have currently.