Search Unity

  1. Welcome to the Unity Forums! Please take the time to read our Code of Conduct to familiarize yourself with the forum rules and how to post constructively.
  2. We are updating our Terms of Service for all Unity subscription plans, effective October 13, 2022, to create a more streamlined, user-friendly set of terms. Please review them here: unity.com/legal/terms-of-service.
    Dismiss Notice
  3. Have a look at our Games Focus blog post series which will show what Unity is doing for all game developers – now, next year, and in the future.
    Dismiss Notice
  4. Join us on Thursday, September 29, for a day with Unity's SRP teams here on the forum or on Reddit, and discuss topics around URP, HDRP, and the Scriptable Render Pipeline in general.
    Dismiss Notice

Support Multiple Unity Versions with a Managed DLL

Discussion in 'Scripting' started by popMark, Jan 11, 2022.

  1. popMark

    popMark

    Joined:
    Apr 14, 2013
    Posts:
    113
    Hi,

    I have a managed DLL that references the Unity API, 2019.4.8 specifically.

    The DLL is distributed using package manager.

    I'm trying to upgrade a project that uses the DLL to Unity 2020/2021 but finding it wont build unless I rebuild the DLL with the 2020+ (something about UnityEngine.dll moving into CoreModule.dll?), but that DLL isnt compatible with 2019.4.8 and I have several projects on that version.

    Any ideas how to support 2019 and 2020+? Ideally with a single package

    I tried including the 2 versions of the DLL with UNITY_2020_OR_NEWER on one and inverted on the other but that seemed to crash the editor on 2019.4.8

    I cant change to source because that will mess up all the script guids in scenes and prefabs.

    No bad suggestions
     
  2. popMark

    popMark

    Joined:
    Apr 14, 2013
    Posts:
    113
    So I got the Define Constraints working using UNITY_2020_1_OR_NEWER on the 2020 DLL and !UNITY_2020_1_OR_NEWER on the 2019 DLL, the DLLs are identically named, with one in a folder called 2019 and one in a folder called 2020, seems to work.

    The DLL contains Behaviours though and I'm concerned about the GUIDs.

    If I'm in a project using 2019 and I use the "Add Component" dropdown it only shows the behaviour from the 2019 DLL which is great, but I can drag and drop the behaviour from the 2020 DLL if I want, and if I ping that it pings the 2020 DLL. It all works and I can assign references between components whose script pings both the 2019 and 2020 DLLs without problems, the components work fine in the build too. Also in that case the 2020 DLL is included in the Editor Log Build Report along with the 2019 version, but the Build_Data/Managed folder only contains the 2019 version.

    Vice versa If I upgrade that project to 2020 the "Add Component" dropdown only shows the 2020 version but pre-existing components will ping the 2019 version.

    Should I be worried about the GUIDs?
     
  3. Neto_Kokku

    Neto_Kokku

    Joined:
    Feb 15, 2018
    Posts:
    1,427
    The GUIDs will be different. From Unity's POV the components from the 2019 dll are different than the 2020 dll components. This can cause issues if someone starts the project in 2019 and upgrades to 2020 later: they will be using the 2019 components.

    I'm not sure how you can do this in a clean way with a single package version. Maybe you could have separate version lines for 2019 and 2020, kinds like the SRP packages.
     
  4. popMark

    popMark

    Joined:
    Apr 14, 2013
    Posts:
    113
    That's what I thought, I upgraded a 2019 project to 2020 and they are using the 2019 GUIDs, but since that DLL is excluded and it still all works I wonder if the components with 2019 GUIDs still end up using the 2020 implementation.

    I think the version lines sounds interesting, would that be publishing the package twice with different unity versions in the package.json for each DLL update? Does the package manager filter old packages incompatible with your current Unity version somehow?
     
unityunity