Search Unity

  1. Unity Asset Manager is now available in public beta. Try it out now and join the conversation here in the forums.
    Dismiss Notice

How do I include external DLLs / Plugins?

Discussion in 'Project Tiny' started by Kmsxkuse, Oct 15, 2020.

  1. Kmsxkuse

    Kmsxkuse

    Joined:
    Feb 15, 2019
    Posts:
    306
    I've been trying to link an external plugin, WebRTC, from Microsoft in an empty project for some prototypes.

    However, no matter what I do and where I place the DLL, I get this error:

    > The type or namespace name 'MixedReality' does not exist in the namespace 'Microsoft' (are you missing an assembly reference?)

    I've placed: the DLL in a folder called Plugins under Assets, set it to autoreference, typed
    using Microsoft.MixedReality.WebRTC;
    at the very top of the script, and used this one and only line
    var test = new PeerConnection();
    in the body.

    Of course that will throw an error as PeerConnection can not be accessed by this way but Unity should throw that error once it reads the DLL.

    But instead it doesnt even know the DLL exists. What am I doing wrong?
     
  2. elliotc-unity

    elliotc-unity

    Unity Technologies

    Joined:
    Nov 5, 2015
    Posts:
    230
    There are a few issues going on here.
    1. Most immediately, we haven't implemented support for precompiled assemblies in our special tiny-specific build pipeline. This is because ...
    2. Our tiny .NET runtime & core library that we use for web & mobile builds in tiny is so restricted that arbitrary precompiled assemblies from the .NET ecosystem are nearly guaranteed to be incompatible with it. So, you are likely to hit a mysterious build error if you were to get our build setup to pick it up and try to include it. And,
    3. We haven't implemented tooling to try to decide at build time whether a given precompiled assembly is indeed tiny-compatible.

    Personally, I think 2 is so overwhelmingly true that it seems unlikely to be worth dealing with 3, which would be required to make 1 a good experience for everybody using tiny. And, the thing that makes tiny tiny is also the thing that makes it incompatible with most precompiled .NET assemblies, so if we were to try to support this, we would probably just not be tiny anymore.

    Now, we are exploring some non-tiny usecases for pure dots runtime (which would run with a big .NET backend), and for those cases it might be worthwhile to implement 1. But, I doubt that would actually help this case, because it sounds like you are interested in tiny specifically.

    At a high level, I know some people internally are very interested in making web XR stuff work in tiny, so I think you may be happier about that general area in the future, but I don't know the timeline for it.
     
  3. Kmsxkuse

    Kmsxkuse

    Joined:
    Feb 15, 2019
    Posts:
    306
    Oh no, understandable though. I guess I'll just configure my packages for regular DOTS to be 2d only and use the external libraries there.

    Shame. Hopefully Tiny will mature in a couple years time with some sort of networking solution.
     
  4. Elringus

    Elringus

    Joined:
    Oct 3, 2012
    Posts:
    483
    But what if we're authoring an in-house library specifically for a Tiny project(s)? Like some core rules/structures using only the most basic .NET APIs, that are compatible with the Tiny runtime. That's a common practice to separate high-level policies from the implementation details, which Unity/Tiny front-end is. I understand, that such use case may not be a priority while Tiny is in early development, but I really hope the support for managed plugins will be there once it's labeled as production ready.
     
  5. djsell

    djsell

    Joined:
    Aug 29, 2013
    Posts:
    77
    You can still do this by creating a Unity package.

    https://docs.unity3d.com/Manual/CustomPackages.html

    It's just precompiled libraries that aren't supported.
     
  6. Elringus

    Elringus

    Joined:
    Oct 3, 2012
    Posts:
    483
    So Tiny's build system will link DLLs from a package, but won't do the same from the project directory? That's weird...