Search Unity

  1. Megacity Metro Demo now available. Download now.
    Dismiss Notice
  2. Unity support for visionOS is now available. Learn more in our blog post.
    Dismiss Notice

[Solved] Handling Plugin Dll Dependency

Discussion in 'Package Manager' started by as3mbus, Mar 18, 2020.

  1. as3mbus

    as3mbus

    Joined:
    Dec 5, 2016
    Posts:
    71
    sorry beforehand if this post is already answered else where. i've searched "dll dependency" but found no related thread to what i'm looking for.

    i am trying to extract most of my module to unity package. but i am troubled by dependency of a module that require specific dll (in this case system.collection.immutable.dll) i realized that if i add this specific plugin to my package folder i would end up conflicting with other package that have the same dll inside it or in a case where a project already using said dependencies.

    is there a way to solve this ?
     
  2. Davidtr_Unity

    Davidtr_Unity

    Unity Technologies

    Joined:
    Mar 5, 2020
    Posts:
    34
    Hi as3mbus,

    Bundling a dll directly into an existing package is not recommended for the reasons you mentioned. The safest way to do it would be to move the dll into its own package and then add it as a dependency on your module, it would then be added only once to the project. If you plan on publishing your package on a public registry (like OpenUPM) then other developers could reuse your bundled dll and make themselves compatible with your package by sharing the same dependency.
     
    JakePerryGameDev likes this.
  3. as3mbus

    as3mbus

    Joined:
    Dec 5, 2016
    Posts:
    71
    doesn't that mean there will be bunch of single dll bundled inside UPM in their own way ?

    or i could just wrap dll that i mostly used into 1 upm ?

    and how would the recommended structure be like ?
     
  4. Davidtr_Unity

    Davidtr_Unity

    Unity Technologies

    Joined:
    Mar 5, 2020
    Posts:
    34
    Creating one package per dll would be the best way to do it, especially if you plan to make your package available to the public. Having a single package with all the dlls would solve your problem short term but it could make things more complicated in the long run if you end up with a lot of packages depending on it, like if you're working with a team or if you plan to release your package publicly. It's perfectly fine to create a big package with everything though for your private usage if you don't plan on having a lot of packages depending on it.

    As for the structure, it would be roughly the same as a normal package. In your example, the `system.collection.immutable.dll` would go in the RunTime folder since it needs to be included into the final game. So you'd have

    <root>
    ├── Runtime
    │ ├── com.system.collection.immutable.asmdef
    │ └── system.collection.immutable.dll
    ├── package.json

    If bundling each dll individually, you can simply use the dll version as your package version. For example: If `com.system.collection.immutable.dll` is version `1.7.0` then you can make your package start at version `1.7.0` so as to make things less confusing. If you're bundling all the dlls in a single package then you can start at version `1.0.0` and increase the version every time you change one of the dll.
     
    douglas_barcelos likes this.
  5. as3mbus

    as3mbus

    Joined:
    Dec 5, 2016
    Posts:
    71
    that's a good idea i guess.

    but providing proper maintenance for each dll would be a big hassle. would love if most of used third party dll provider would make UPM package, so that i don't need to do all these maintenance

    With all included unity dll (system.*) and it's different version (.net, mono, and .netframework) doing those seems quite an inconvenience