We’re developing a game-engine agnostic pinball engine. Unity-specific code is in a sub folder as a sibling to the agnostic Engine. They are currently two .NET projects in one Solution. Something like:
├── Engine
└── Engine.Unity```
`Engine.Unity` has a dependency to `Engine`. We would like to use `Engine.Unity` as a package in Unity.
As far as I've understood, third-party dependencies can be added to the project's manifest, but as a package we don't have access to any manifest. I've also thought about adding `Engine` as a separate package, but it also has NuGet dependencies, so we would need a way to add (native) assemblies to the package as well.
What's the common way of doing this? If `Engine` compiles into a sub folder of `Engine.Unity` that would be acceptable, but how can I reference the assemblies in the package?
Unity Packages are designed to work inside Unity projects. As such they can have dependencies on other packages.
As for referencing your Engine assembly, since you’re fine with compiling it into a DLL stored under Engine.Unity, you simply need to do it once and add the generated DLL path to the assembly definition files (.asmdef) in your package. that need to consume it.
Thanks for the reply. We’ve currently added package.json to the root of the repository and added an .asmdef file to the agnostic engine as well. The major drawback is a massive amount of .meta files in the agnostic project.
We’re still hesitating about shipping the agnostic project as a DLL because build times seem to be slower when providing the DLL versus the source to Unity. Can you confirm that? Is there any reason why Visual Studio compiling the DLL and Unity (re)loading it would be slower than Unity compiling and reloading changes during development?
About adding the DLL to the Unity project’s .asmdef: It seems to me that Unity grabs everything in a given package folder, including any DLLs? Why and how would I need to add it?