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
- Too little validation messages in the "WebAssembly Language Features" Memory settings
- Project Settings Search Highlights are misaligned when using the Bitmap Text Rendering Mode
- "GetControlID at event ValidateCommand returns a controlID different from the one in Layout event" Warning is thrown when undoing the deletion of Sprite Shape Profile
- Memory related fields in the "WebAssembly Language Features" can be set to the negative numbers
- "WebAssembly Language Features" Header in the Player Settings has a smaller indentation
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.