Extending Unity.Entities

Hey all,

I've been trying to do some more unsafe bits with the Entities package and have run into an interesting solution to avoid having to use reflection for grabbing internal methods and types.

Assembly Definition References.

If I make a new folder, add an asmref file and point it add `Unity.Entities` it allows to to extend that assembly as if I was altering the package directly.
This is super useful for implementing things such as copying components from 1 entity to another, which are near impossible to do with the public API.

However there is a down side.
It seems the current editor version have a bug that the csproj's generated will generate an incomplete csproj for Unity.Entities when the asmref is present. Is there any idea if this will be fixed?
https://fogbugz.unity3d.com/default.asp?1240286_3ogmlikr9bt3fgkc

A current workaround is checking the `Edit->Preferences->External Tools->Generate all .csproj files`
Note that compilation works either way, it's just the IDE (Rider in my case) that gets confused.

 

I can confirm the same issue with

Microsoft Visual Studio Community 2019 16.4.5;
Unity 2020.2.0a8
VisualStudio Editor package 2.0.1

This bug should be looked at.

 

An additional issue I've found. Is that if the `Generate all .csproj files` option is checked when you first open the project (or did a git clean), you will have to uncheck and re-check it for unity to generate the csproject files again.
This seems like an additional bug.

 

I would also be interested to know if being able to extend packages with an asmref is a supported use-case from Unity.

I was looking into extending the Entity Inspector to be able to implement a custom GUI for a set of types. However, all the governing classes for this logic are internal in the assembly so I'm unable to do so without an ungodly amount of reflection. Being able to extend packages this way would be extremely useful!

 

+1 on this. Would be good to see a policy regarding extending the framework.

 

They're planning to overhaul that window, so be careful with how much work you put into something like that. I would guess that however official this extension ability might be, those internal implementations will never be considered public APIs and will always be subject to change without warning. This may be neater than using reflection, but it's just as dangerous in that regard.

There's a feedback thread up for the changes they're planning to the DOTS debugging tools. I would suggest that you mention what you want to achieve in that thread and advocate for an official extensibility point for custom IComponentData inspectors.

 

Thanks for the heads up! I hadn't seen this before. I see a few people have already mentioned extensibility in this manner.

 

Please have a look at this bug. Unity should be correctly generating the projects when using an asmref.