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?