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
- After converting a Built-in project to URP render texture related errors are spammed that can lead to Game view being rendered on top of Scene view
- UI Builder slider value lags and stutters when sliding/modifying certain property values
- "Reset UI Builder Layout" functionality inconsistently changes Canva Size when "Match Game View" is enabled/disabled
- Texture Import Warnings are obscured by other Terrain Layer options in the Inspector
- Burst Inspector middle divider is jittering when resized with the Burst Inspector window docked
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.