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
  2. Megacity Metro Demo now available. Download now.
    Dismiss Notice
  3. Unity support for visionOS is now available. Learn more in our blog post.
    Dismiss Notice

Need DLL mapping options for 4.6 vs 3.5

Discussion in 'Experimental Scripting Previews' started by Dustin-Horne, Aug 10, 2017.

  1. Dustin-Horne

    Dustin-Horne

    Joined:
    Apr 4, 2013
    Posts:
    4,568
    As an asset publisher, my asset ships with multiple DLLs, each compiled for a different platform. I can choose to map one DLL for IL2CPP and one for .NET backend which is super helpful. However, I now have requests from customers to include .NET 4.6 support. The best I can do right now is ship them a separate package with the DLLs updated to support .NET 4.6. As a publisher, we need a way to also specify .NET version in the mapping (even if it is experimental) so we can specify some DLLs for .NET 3.5 and some for .NET 4.6 regardless of whether we're using IL2CPP or Mono.
     
  2. JoshPeterson

    JoshPeterson

    Unity Technologies

    Joined:
    Jul 21, 2014
    Posts:
    6,920
    How do to specify the difference between the IL2CPP and .NET backends now? Are you using #define statements and compiling different assemblies? Or is there a runtime check?
     
  3. Dustin-Horne

    Dustin-Horne

    Joined:
    Apr 4, 2013
    Posts:
    4,568
    IL2CPP vs .NET isn't the problem. The only reason I mentioned both is because in 2017 you can use .NET 4.6 Experimental for Standalone / PC and it only supports the .NET (Mono) backend.

    I do have different DLLs for different platforms. I have one DLL currently that's AOT friendly and used for iOS, Android, WebGL and IL2CPP on UWP. I have another DLL that's for Editor and Standalone. It's not AOT friendly but doesn't need to be (yet). Those two DLLs are .NET 3.5.

    I have a third DLL for targeting UWP with the .NET Backend and it's compiled against .NET 4.5.2 (I have to double check that), and it works fine. I can upgrade it actually to 4.6 without an issue. The problem comes when wanting to use .NET 4.6 for Standalone with the Mono backend, or when using it for any other platform with the IL2CPP backend. I can recompile my DLL to support .NET 4.6 (which adds support for types like BigInteger and adds back in support for dynamics, etc).

    My mapping for UWP (actually all Windows platforms with Mono backend) looks like this:
    uwp_net_mapping.PNG

    My mapping for AOT platforms looks like this:
    aot_mapping.PNG

    And the relevant player settings:
    playersettings.PNG

    So, I can change the player settings to .NET 4.6, but there's no way for me to specify a different DLL to be used when targeting .NET 4.6. Unfortunately, when using my .NET 3.5 AOT dll for UWP with IL2CPP backend and .NET 4.6 selected there is an exception that happens that looks to be Unity internal. It's trying to access an invalid / bad or corrupted memory address. Simply recompiling against 4.6 for some reason fixes that issue on top of adding support for additional types.

    I understand that 4.6 is still experimental, so this is just an ask, not a complaint. :) It would just be great to be able to ship a second set of DLLs in the package and specify that they are used for .NET 4.6.

    And to answer your question... yes it's a whole lot of different combinations of define statements but it's a bit more than that. There are also differences in the classes that get included and some shims added to support some missing System classes in some platforms. My Visual Studio solution contains multiple projects, each with a specific set of symbols defined and some with different framework versions as follows:

    vssln.PNG

    The IL2CPPNET46 project is a new beta enhancement where I've updated and rebuilt against .NET 4.6 and it seems to be working well, just no way to specify it based on the selected .NET version.
     
    Last edited: Aug 11, 2017
  4. JoshPeterson

    JoshPeterson

    Unity Technologies

    Joined:
    Jul 21, 2014
    Posts:
    6,920
    No worries! Indeed, one goal of this experimental release is to sort out issues like this.

    I think that I understand the situation, but my understanding might still be a little foggy. If we were to add an "Api Compatibility Level" option to the UWP platform settings in the plugin inspector, is that enough for you to specify what you need?
     
    Dustin-Horne likes this.
  5. Dustin-Horne

    Dustin-Horne

    Joined:
    Apr 4, 2013
    Posts:
    4,568
    Yes that should be good. Api Compatibility Level with options of "Any", ".NET 3.5" and ".NET 4.6 (Experimental)" or however you want to phrase it would be perfect. It would need to be for all platforms though, not just UWP. Because I need to be able to specify .NET 4.6 assemblies under IL2CPP or .NET for all platforms that support it (Standalone, iOS, WebGL, Android, etc).
     
  6. JoshPeterson

    JoshPeterson

    Unity Technologies

    Joined:
    Jul 21, 2014
    Posts:
    6,920
    Do you also need a scripting backend option for all platforms that support more than one scripting backend?
     
  7. Dustin-Horne

    Dustin-Horne

    Joined:
    Apr 4, 2013
    Posts:
    4,568
    Yes but that already exists. I think the scripting backend is completely independent so there's no need to specify it per framework version.

    Ideally It would be:

    DLL Properties
    ** Scripting Backend (Mono or IL2CPP - or DotNet as it exists in UWP)
    ** Framework Version (3.5 or 4.6 - Experimental)
    ** Placeholder - This is important because Editor only supports 3.5

    I added the Placeholder bit above as it's important. UWP already has it so the assemblies can target .NET 4.5.2+ but in the editor it uses the Placeholder which is a .NET 3.5 DLL. If we're going to be able to map assemblies per framework version, we need to be able to select a Placeholder DLL when we select 4.6 because as far as I know, the Editor still only supports 3.5 (unless I'm wrong).
     
  8. JoshPeterson

    JoshPeterson

    Unity Technologies

    Joined:
    Jul 21, 2014
    Posts:
    6,920
    Ok, thanks for clarifying. We will discuss this change, but I think it is something we can and should do. I don't think it is something we can back port to 2017.1 (although I'll know more when we get into the details). Going forward though, this looks like something we want to support in the plugin inspector.
     
    Dustin-Horne likes this.
  9. Dustin-Horne

    Dustin-Horne

    Joined:
    Apr 4, 2013
    Posts:
    4,568
    One other aside, if they're going to be making changes to that area... they might want to consider "Forward Compatibility". I'll give you this scenario:

    1. I create a package in Unity 5.3 and I map the DLLs only to iOS, Android, WebGL and Tizen
    2. Someone imports that package in Unity 5.2

    What happens in the above is that 5.2 encounters "Tizen" and it doesn't know about it because the platform didn't exist, so it defaults the DLL to "All Platforms" and breaks stuff. Ideally, people wouldn't import those packages into older versions of Unity but it happens sometimes. What it probably should do if it encounters a mapping it doesn't recognize is just ignore it and don't map to any platforms at all unless there are other mappings that it does recognize.
     
  10. Dustin-Horne

    Dustin-Horne

    Joined:
    Apr 4, 2013
    Posts:
    4,568
    No problems on the backport. I don't think it's a widely hit scenario yet, especially with it being experimental. I can continue to provide separate packages and if it makes it into 2017.2 then I'll publish the updated package with the full mappings for that platform and tell customers they'll need to use 2017.2 to get 4.6 support.
     
    JoshPeterson likes this.
  11. JoshPeterson

    JoshPeterson

    Unity Technologies

    Joined:
    Jul 21, 2014
    Posts:
    6,920
    After some more discussion, it seems the best way for us to track and correct this now is via a bug report. @Dustin-Horne do you mind submitting a bug report? You can just reference this forum thread, and I'll fill in the report details.
     
  12. Dustin-Horne

    Dustin-Horne

    Joined:
    Apr 4, 2013
    Posts:
    4,568
    Yeah I can do that. I'll try to get one submitted today.
     
    JoshPeterson likes this.
  13. envy82

    envy82

    Joined:
    Oct 18, 2016
    Posts:
    9
    Sorry for posting to an old topic, but still.. Any updates on this?
     
  14. JoshPeterson

    JoshPeterson

    Unity Technologies

    Joined:
    Jul 21, 2014
    Posts:
    6,920
    I don't think we have any updates on this. @Dustin-Horne, did you end up submitting a bug report? I can't find one now, so please let me know the case number if one exists.
     
  15. Dustin-Horne

    Dustin-Horne

    Joined:
    Apr 4, 2013
    Posts:
    4,568
    I did not. I need to get that done. It's just taken a backseat in priority. I'll try to get it done in the next day or two. I'll do it with 2018.1 now that it's released.
     
  16. Arvtesh

    Arvtesh

    Joined:
    Aug 16, 2014
    Posts:
    94
    That'd be a very useful tool when implemented. I wasn't able to find an open issue for this, so I have created one: case
    1039816.
     
    TooManySugar and JoshPeterson like this.
  17. Dustin-Horne

    Dustin-Horne

    Joined:
    Apr 4, 2013
    Posts:
    4,568
    Thanks @Arvtesh, also cc: @JoshPeterson I was supposed to create an issue for this but I've been full on firefighting with non-Unity stuff so I hadn't had the opportunity.
     
  18. HaraldNielsen

    HaraldNielsen

    Unity Technologies

    Joined:
    Jun 8, 2016
    Posts:
    136
    Hi @Dustin-Horne, there are actually done some work that hopefully would solve your issue.
    So by default, all Precompiled Assemblies are auto referenced by all, we are changing that, by an option in the PluginImporter, so it will not be auto referenced. This then will only be referenced if a user does so explicitly through an Assembly Definition, this will be included in 2018.3.
    Another feature we are working on is define constraints for assemblies, meaning that those assemblies will only be compiled/included given that specific compilation define. Dont know if this will be included for 2018.3, but will keep you updated.
     
  19. Dustin-Horne

    Dustin-Horne

    Joined:
    Apr 4, 2013
    Posts:
    4,568
    That sounds great! One more suggestion which might be solved with the 2018.3 update... if an inspector mapping is found for a dll but not valid... ignore it. Right now it defaults to "all platforms". As an example... If I map a dll to "Samsung TV" but then open it in a version of Unity that doesn't have that.... it will just auto map that dll to "all platforms". It has actually forced me to publish from way more versions of Unity than I need to in some cases.
     
  20. Tomas1856

    Tomas1856

    Unity Technologies

    Joined:
    Sep 21, 2012
    Posts:
    3,875

    Hi Dustin, this sounds like a bug, even if platform is deprecated, the settings for dll should persist and not default to all platforms. Could you please report a bug, with small repro project?

    Thank you
     
  21. Dustin-Horne

    Dustin-Horne

    Joined:
    Apr 4, 2013
    Posts:
    4,568
    I can check, it may have been fixed already. I haven't tried since 5.x, just worked around it. Same goes for backward compatibility... importing a package from a newer unity version that contained platforms that didn't yet exist were defaulting to all platforms. I just assumed it was supposed to work that way. :)
     
  22. HaraldNielsen

    HaraldNielsen

    Unity Technologies

    Joined:
    Jun 8, 2016
    Posts:
    136
    Hi @Dustin-Horne
    Just want to let you know the "assemblies will only be compiled/included given that specific compilation define" just got merged and will be included in the 2018.3 release
     
    Dustin-Horne likes this.
  23. Dustin-Horne

    Dustin-Horne

    Joined:
    Apr 4, 2013
    Posts:
    4,568
    Great news, thanks!