Search Unity

  1. Unity 2018.3 is now released.
    Dismiss Notice
  2. The Unity Pro & Visual Studio Professional Bundle gives you the tools you need to develop faster & collaborate more efficiently. Learn more.
    Dismiss Notice
  3. We've updated our Terms of Service. Please read our blog post from Unity CTO and Co-Founder Joachim Ante here
    Dismiss Notice
  4. Want to provide direct feedback to the Unity team? Join the Unity Advisory Panel.
    Dismiss Notice
  5. Improve your Unity skills with a certified instructor in a private, interactive classroom. Watch the overview now.
    Dismiss Notice

Referenging package dll's in external projects

Discussion in 'Package Manager' started by snacktime, Jan 8, 2019.

  1. snacktime

    snacktime

    Joined:
    Apr 15, 2013
    Posts:
    1,850
    So I have a C# project that generates a dll that is shared by client and server. I reference libraries like mathematics in this project. I've been referencing it from ScriptAssemblies, so I know the reference is always up to date with the package Unity is using.

    But Unity complains about that saying it's not able to reference the package. It eventually sorts it out as there are no compile errors. So I'm assuming the package dll's are at some point either built or copied to ScriptAssemblies during start or reload?

    So what is the correct way to reference packages from other projects?
     
  2. maximeb_unity

    maximeb_unity

    Unity Technologies

    Joined:
    Mar 20, 2018
    Posts:
    37
    Hi @snacktime,

    You got the gist of it. The assemblies under ScriptAssemblies are generated by the Unity compilation pipeline.

    Some context: scripts in packages are compiled with assembly definitions, which play a role in the compilation pipeline similar to Visual Studio projects (e.g. .csproj). When assemblies are compiled from assembly definitions and their scripts, the generated DLLs are copied to the ScriptAssemblies directory.

    When a project is first opened, that folder does not exist (unless it was put under source control, which is strongly discouraged). It gets populated with the assemblies built from code in packages and your project Assets. In addition, there are situations where they will be rebuilt and re-copied, which might provide a tiny window where the DLL files are missing.

    In addition, we don't currently support pre-compiled assemblies (DLL files built outside Unity, and imported from your Assets or in packages) referencing assemblies built with assembly definitions. While this can work, there will be situations where the precompiled DLL cannot has TypeLoadExceptions (for instance) as a referenced DLL has not been compiled yet; this seems to be your case, if I understand correctly.

    So assuming both your client and server are built with Unity, the simplest solution is to also use assembly definitions with the scripts directly under your Unity project, rather than building it outside of Unity. Since assembly definitions declare references to other assembly definitions, the compilation order is guaranteed, and it also ensures that your DLL won't be loaded without its dependencies being compiled first.
     
  3. snacktime

    snacktime

    Joined:
    Apr 15, 2013
    Posts:
    1,850
    Thanks for the info. The server is not Unity. While you could put the shared code under Unity in cases like this and copy dll's to the server, it's generally problematic. Like if you actually do unit testing the compile/test flow in VS is clearly superior and faster. Unity also has no first class support for Nuget and we make use of things like T4 templates and also build pipeline hooks.