Well, creating an Asmdef for my Unity ECS baking components was a colossal waste of time and an excercise in futility.
That part of the tooling needs an immediate overhaul.
Sorry to play the annoyed asshole here again, but that’s not a DX that I expect from a mature product like Unity.
Here’s my developer experience for the night:
- you can’t multi-drag Assembly Definition References
- you can’t even single drag-add them (other lists allow you to drag an item to its top, bottom, or sometimes between elements, but here, you have to first create an empty one and then fill it)
- you can’t sort the entries
- you can’t automatically remove duplicates
- you can’t autodetect needed dependencies (seriously, by default, a new asmdef asset should be populated with all the previous references the code it covers uses)
- compiler errors are shortened to the point of being useless, (if they don’t stop coming/changing altogether)
- good luck figuring out which of the three or four candidate assemblies will resolve the compile issues; massively exacerbated by ECS’ very generous helping of extra many assemblies.
- the new searcher shows nothing but useless garbage when trying to pick asmdefs - in safe mode, you get even less info, so you better hope you don’t have to shut down the editor half way (spoiler alert, you do the compiler gets stuck, especially codegen and burst, but also something called “Waiting for Scriptupdater” just hangs)
- safe mode has no Focused Inspector (huh?!), so back to Locked Inspector workflow like it’s 2010 (circa, colorized)
- with many more packages in the average unity project, this workflow suffers quadratic complexity and effort the more complex it gets.
- with the out of box workflow, some things just can’t be done, including for example creating an asmdef that contains code referencing URP or HDRP.
“Hmm, are those enough assemblies, or did I forget one?”
Suggestions, any of these would be celebrated by the users:
PLEASE provide single entry point assemblies, e.g. Unity.Entities for ALL ECS packages that are currently installed.
PLEASE Create a sample asmdef import for EVERY package, so one can quickly copy that. Make GUID entries copy/pasteable, so one can take them from the template.
PLEASE Allow the use of literal strings again - that feature is gone now, even though the checkbox still exists.
Checkbox “use GUIDs” is off, still guid based asmdef asset links, the editable string lists of the past have been taken away now it seems. Editing YAML is no longer an option, because this is what it looks like now…
no longer human readable, finally an excuse to turn on binary asset serialization again…
PLEASE Allow the use of WILDCARDS - e.g. Unity., Tiger.Editor., MongoDB.BSON.*
PLEASE show the assembly name and root namespace in the searcher. (and please fix it, see below)
PLEASE auto-populate new Asmdef assets with all referenced assemblies (if impossible, it would even help to just have one with ALL Assemblies, and then one can prune manually)
Alternatively, PLEASE make all Unity.* packages automatically part of the “Engine References” packages. It would cut asmdef editing needs easily by 85%. This specifically includes URP, DOTS, et. al.
PLEASE Allow us to place Asmdefs in that editor via drag & drop (seriously, most other lists do this, but in this inspector, of all places, you simply omitted it? Only after adding the new Searcher, of course, which makes search even harder.)
… any one of these suggestions would make asmdef inspector at least remotely useful again.
But, oh, that wonderful, now no longer optional searcher:
(that finds nothing useful, ever)
This searcher one get when clicking on the object selector in the Asmdef inspector must be some kind of joke, it can’t even seach in packages and it very skillfully obfuscates the actual assembly names. But at least it tells us the file name twice!
It also can’t find any Engine or Package assemblies.
It also can’t find any Engine or Package assemblies.
It also can’t find any Engine or Package assemblies.
Out of the box, most unity projects and templates contain about a dozen core packages. This is a serious defect and makes asmdef creation an Impossible task. There are workarounds, but they are adding several extra clicks to each step of an already unbearable workflow.
It also can’t preview or inspect asmdefs, so you have to guess what’s inside (e.g. conditionals, platform flags, etc.). Better keep a list on paper to check which ones you already added only to find out they’re not the ones you wanted.
To add injury to insult, it will also INSTANTLY overwrite the object field you clicked the Circle icon on, so while scrolling through the list, be careful not to ever click INTO the list. Undo is unreliable here, by the way.
Yeah, I’m done for the day. It has only, oh, minus 24 minutes left, anyway.