How to create a library (DLL) that references Unity.Entities?

Hello!

We are trying to make a shared library for use in multiple projects. When I make a library, we can usually add a reference to a .csproj or a .dll to include in our own project. I don't see such files in the Unity.Entities package.

Unity.Entities seems to be loose .cs files contained in

C:\Users\UserName\AppData\Local\Unity\cache\packages\packages.unity.com\com.unity.entities@0.0.12-preview.8

What would be the best way to reference this?

• Include all Unity.Entities scripts inside our library, and do NOT use the Unity Package Manager? This would break if we have multiple libraries that want to reference the same Unity.Entities code.
• Is there some other way to reference these scripts in our library without using a .csproj file or a .dll?

Thanks for the help!!!

 

You can copy the package folder directly to your Packages folder, it's located on the same level of your project as Assets, Library, ProjectSettings, etc folders.

 

I apologize for not being clear! I've edited the topic title to reference a DLL.

We sometimes make a .dll file that we have compiled to drop into our projects. This DLL is made outside of the Unity Editor, using only Visual Studio or Rider.

The Visual Studio project references the UnityEngine.dll so our compiled dll can use the UnityEngine namespace, but there is not actually a Unity project that exists.

We would like to do the same thing with the Unity.Entities namespace. That is, reference it from a Visual Studio project so we can compile a DLL without using the Unity Editor. So there are no folders such as Assets, Library, or ProjectSettings that exist.

 

Ah, I see now.

I believe that just like the old C# project DLLs, all packages and asmdefs in a project get compiled to the Library/ScriptAssemblies folder. You might want to create a blank project that just compiles these Dlls at the package level you want. I don't think there's currently a "proper" solution for this, although some enterprising person might have made or be working on a nuget-like extention for VS or something that pulls from Unity's package manager.

 

I think the way forward with Unity right now is to be in UPM ecosystem including your own shared library. That means you keep your shared lib together in a folder somewhere uncompiled with package.json + .asmdef linked to Unity.Entities. Then that will compile with Entities UPM packages version indicated in any project and you get a fresh .dll inside each project instead of making one outside and drop into each project.

To do the equivalent of dropping dll file to a project currently you can use local UPM with `file:` pattern in your manifest.json to walk relatively from manifest file to the destination that has packages.json with the matching package "name".

Code (CSharp):

1. {
2.   "dependencies": {
3.     "com.e7.asset-store-extensions": "file:../../PackageDev/Assets/AssetStoreExtensions",
4.     "com.e7.e7ecs": "file:../../PackageDev/Assets/E7ECS",
5.     "com.e7.e7unity": "file:../../PackageDev/Assets/E7Unity",
6.     "com.e7.exceed-sound-engine": "file:../../PackageDev/Assets/ExceedSoundEngine",
7.     "com.e7.google-sheets-unity": "file:../../PackageDev/Assets/GoogleSheetsUnity",
8.     "com.e7.native-audio": "file:../../NativeAudio/Assets/NativeAudio",
9.     "com.e7.native-touch": "file:../../NativeTouch/Assets/NativeTouch",
10.     "com.e7.odinhierarchy": "file:../../PackageDev/Assets/OdinHierarchy",
11.     "com.e7.protobuf-unity": "file:../../PackageDev/Assets/protobuf-unity",
12.     "com.google.firebase": "file:../../Firebase/Assets/",
13.     "com.sirenix.odin-inspector": "file:../../PackageDev/Assets/OdinSource",
14.     "com.unity.addressables": "0.2.2-preview",
15.     "com.unity.ads": "2.0.9",
16.     "com.unity.analytics": "2.0.16",
17.     "com.unity.burst": "0.2.4-preview.25",
18.     "com.unity.entities": "0.0.12-preview.10",
19. ...

When doing it this way I think it is good to keep all custom UPM together in one Unity project rather than just a normal folder since I think you need the same generated .meta file to include to all your project. And you can test how they work because they are all inside "Assets" of some project, but when grabbing the code with UPM you dig inside Assets to each package's folder so it now works like a normal folder. Also you can make each package subfolders that are in the same Unity project as git repo so when UPM can do git repo we can transition immediately.

You can copy the format for package.json from other UPM package but currently custom "author" and "version" still not showing up.

 

Sorry for bumping this old thread. I'm having a similar situation.

Similar to the OP, I need to reference UnityEngine.Timeline in an external C# Dll project built for Unity 2019, which has it as a core package. It is located in

<Untiy-path>\Editor\Data\Resources\PackageManager\BuiltInPackages\com.unity.timeline

Is there a solution now?

 

Packages are always in Library/PackageCache. I prefer referencing those because then shared projects are just automatically up to date when you update the packages in Unity.

VS will reference them as relative paths when it can automatically. So if you have a standardized directory structure for your game then it's portable regardless of where developers put it locally.

 

Packages in Library/PackageCache are source code (.cs files) in their respective directories with the names starting with "com.unity.". How can you reference them in such a form? In addition, there is not the directory named "com.unity.timeline".

Just to be clear, I'm talking about reference in C# project as shown in following the screenshot:

 

My bad I meant to say Library/ScriptAssemblies.

 

Interesting. That's not working for me. If I reference compiled package DLLs, then I get compilation errors like:

The type 'GameObject' is defined in an assembly that is not referenced. You must add a reference to assembly 'UnityEngine.CoreModule, Version=0.0.0.0, Culture=neutral, PublicKeyToken=null'.

Referencing the CoreModule in my DLL project is not possible as we should use the monolithic Unity DLLs, instead of the concrete libraries.

@snacktime can you please verify that this is working for you?

 

In case you (or anyone else) haven't found a solution for this yet, the easiest way I've found is to build your own DLLs from the scripts of the package and use them in your external projects.

In my case, I needed the (now packaged) Unity UI in an external project that compiles into a DLL - using the UnityEngine.UI.dll produced by the Unity project didn't work (throwing similar errors as yours) and replacing the monolithic Unity DLLs with the individual modules also didn't work (just to spare you some hours of work).

So, I've just set up a new library project, copied the package's scripts over, compiled it into a DLL (make sure it matches the DLL name that's created by Unity) and used that DLL in my external project. Now it compiles without any issues and also works fine in Unity.

I really hope there'll be an easier solution in the future, as more and more previously built-in functionality is moved into packages, this'll get really tedious soon...

 

That's interesting. I discussed this with the Unity QA and they mentioned that you should be able to replace the monolithic DLL and simply reference all specific dlls needed (I also asked if you simply could ref all and they said that would be fine). I tried and it worked for me. The QA also told me that they want to update the docs about this topic.
Basically the monolithic dll is simply there for legacy reasons.

It's still a non-trivial problem as there is a lot of confusion in the docs as well as the understanding of the monolithic dll (I was wrong here too, thought that this would be the "future way" to do it ).

 

The issue I had with the individual module DLLs was that it threw errors for the Unity UI related things, but opening the classes/errors fixed them - and once all errors where 'fixed' and I hit compile, they where all back and it couldn't compile. At that point I just gave up and went the easy route

I hope they don't remove the monolithic DLL in the future, it's way more convenient to update one DLL instead of 10+ when supporting a new Unity release. Especially when I still have to support older versions as well.

 

Maybe there is something strange going on with the UI stuff I never pulled that in. But we have multiple C projects outside unity that pull in packages from Library/ScriptAssemblies and the unity engine monolithic dll's we use the ones that come with the editor. Making a copy of the appropriate folder so our projects have a static location to reference from.

 

That actually sounds more like an IDE issue. Are you using VS?

 

Yeah, VS 2017.