Search Unity

Official Poll: What's preventing you from switching to IL2CPP scripting backend on Windows Store?

Discussion in 'Windows' started by Tautvydas-Zilys, Dec 14, 2016.

?

What's preventing you from switching to IL2CPP scripting backend on Windows Store?

  1. Lack of Windows Runtime support

    28 vote(s)
    26.2%

  2. Plugins that I use for Windows Store don't work

    31 vote(s)
    29.0%

  3. Longer iteration times

    55 vote(s)
    51.4%

  4. No C# debugger

    35 vote(s)
    32.7%

  5. I had no idea IL2CPP was even an option

    2 vote(s)
    1.9%

  6. I don't target Windows Store

    11 vote(s)
    10.3%

  7. I already use IL2CPP when targeting Windows Store!

    11 vote(s)
    10.3%

  8. Other (please tell us about it in the thread!)

    18 vote(s)
    16.8%
Multiple votes are allowed.
Page 1 of 2

  1. Tautvydas-Zilys

    Tautvydas-Zilys

    Unity Technologies

    Joined:
    Jul 25, 2013
    Posts:
    10,680
    Hello dear developers targeting Windows Store!

    We have been internally discussing about reasons people are still using the .NET scripting backend. It is no secret that we're planning to drop .NET scripting backend support eventually, and make Windows Store an IL2CPP-only platform. The timeline for that, however, is a different discussion, and we'd like you to help us figure that one out. This is not something that will be done in 5.6, 5.7 or even 5.8 - and before we do it, we must make sure that we accommodate the needs of the developers and ideally have everyone switched to IL2CPP by that time. The answers to this poll will allow us to prioritize our IL2CPP work items.

    So, can you tell us what is preventing you from switching to IL2CPP scripting backend on Windows Store?
     
    Tautvydas-Zilys, Dec 14, 2016
    #1

  2. liortal

    liortal

    Joined:
    Oct 17, 2012
    Posts:
    3,562
    5.7 ? 5.8 ? I thought the next release will be named 2017.x :)
     
    liortal, Dec 14, 2016
    #2

  3. Tautvydas-Zilys

    Tautvydas-Zilys

    Unity Technologies

    Joined:
    Jul 25, 2013
    Posts:
    10,680
    Eh, whatever. You know what I meant :).
     
    Tautvydas-Zilys, Dec 14, 2016
    #3

  4. tatoforever

    tatoforever

    Joined:
    Apr 16, 2009
    Posts:
    4,369
    Hi,
    We use IL2CPP if properly supported by the target platform but we are not targeting Windows Store on our builds. Probably add this as an option to the poll?
    [EDIT] Poll*, not pool (silly me). :D
     
    Last edited: Dec 14, 2016
    tatoforever, Dec 14, 2016
    #4

  5. Tautvydas-Zilys

    Tautvydas-Zilys

    Unity Technologies

    Joined:
    Jul 25, 2013
    Posts:
    10,680
    Done
     
    Tautvydas-Zilys, Dec 14, 2016
    #5
    tatoforever likes this.

  6. Dustin-Horne

    Dustin-Horne

    Joined:
    Apr 4, 2013
    Posts:
    4,568
    I personally only use Windows Store at the moment for testing my asset so I test both .net and il2cpp. For me though, the debugger is a biggie, though most of my debugging has already been done im the editor. I'd also love to see some performance metrics between an il2cpp build and a .net build that has been run through .net native.
     
    Dustin-Horne, Dec 14, 2016
    #6

  7. davsteve

    davsteve

    Joined:
    Mar 1, 2016
    Posts:
    2
    The C++ code it generates is a real problem for us. Not being able to debug scripts from the Unity side in the context of our Windows Store app is a real sticking point.
     
    davsteve, Jan 8, 2017
    #7
    ddayptc likes this.

  8. Tautvydas-Zilys

    Tautvydas-Zilys

    Unity Technologies

    Joined:
    Jul 25, 2013
    Posts:
    10,680
    Do you mind elaborating? Did you ever try debugging generated C++ code? Is the problem the fact that it is hard to understand which portion of C++ code got generated from your C# code? Have you given Unity 5.6 beta a try where we introduced original source code annotations for generated C++ code? If so, does that help?
     
    Tautvydas-Zilys, Jan 9, 2017
    #8

  9. davsteve

    davsteve

    Joined:
    Mar 1, 2016
    Posts:
    2
    We haven't attempted debugging with C++, but have inspected the output. In our tests, it was hard to find and recognize the generated C++ and where it fits in for complex components.

    In general, developing in C# and then doing runtime debugging with C++ will certainly be a hindrance. Developers will need to know C++ well enough to understand the language conventions, and if there is a bug we're working on fixing, the iteration time between C#/C++ will certainly be a productivity hit.

    We have not looked at Unity 5.6... the source code annotations sound like they will help some. We have some work planned to look at it in the coming few weeks.
     
    davsteve, Jan 11, 2017
    #9

  10. Tautvydas-Zilys

    Tautvydas-Zilys

    Unity Technologies

    Joined:
    Jul 25, 2013
    Posts:
    10,680
    Thank you for the feedback, that is helpful! Looking forward to you trying 5.6.
     
    Tautvydas-Zilys, Jan 12, 2017
    #10

  11. mr_zog

    mr_zog

    Joined:
    Jan 21, 2014
    Posts:
    165
    I must have missed that: Since when is ILCPP considered stable for Windows Store?

    Last time I checked, it was experimental and half of the extensions we use didn't support it.
    What are the pros and cons?
    Is there stuff not gonna work?
    Only pro of ILCPP is better performance?
     
    mr_zog, Jan 13, 2017
    #11

  12. Tautvydas-Zilys

    Tautvydas-Zilys

    Unity Technologies

    Joined:
    Jul 25, 2013
    Posts:
    10,680
    We aim to have all plugins and extensions be compatible with IL2CPP in 5.6.

    It's 'stable', and people are shipping games using it, but until 5.6 it was still missing some features - namely Windows Runtime support, so some plugins wouldn't work.

    Pros:

    * Identical .NET API compared to other unity platforms - you no longer have to rewrite your code to work on Windows Store;
    * In some cases significantly better performance;
    * IL2CPP uses the same serialization backend as all other Unity platforms, which eliminates certain long standing Windows Store bugs (like the one where we cannot scan static fields for UnityEngine.Object references and thus they will get unloaded when nothing else is referencing them), and enables some features previously unsupported on Windows Store (for instance, type trees for Asset Bundles, which makes you able to build them in one unity version and not have to rebuild them every time you update the editor).

    Cons:

    * No C# debugger;
    * Longer build times (we're working on this one).

    IL2CPP is an AOT compiled platform, so obvious things like System.Reflection.Emit do not work. Up until 5.6, many plugins that were made especially for .NET scripting backend wouldn't work either - you'd have to use the plugin variant that worked on the standalone player instead.
     
    Tautvydas-Zilys, Jan 13, 2017
    #12

  13. mr_zog

    mr_zog

    Joined:
    Jan 21, 2014
    Posts:
    165
    Thanks for the detailed info!
    We use IL2CPP for iOS and Android, so I guess the System.Refleciton.Emit won't be an issue anyway.

    We are now just upgrading to 5.5, it'll take a while until we use 5.6.
    We have to evaluate 5.6 soon, since lightmapping completly changes, so I guess when we do that, we can also give IL2CPP a shot ... the API unification sounds promissing.

    On the other hand, does that actually mean I cannot access native code from unity script anymore?
    E.g. this util function:
    Code (csharp):
    1.  
    2.   public static bool IsWindowsMobile()
    3.   {
    4. #if UNITY_WSA_10_0 && NETFX_CORE
    5.  
    6.     string platformFamily = Windows.System.Profile.AnalyticsInfo.VersionInfo.DeviceFamily;
    7.  
    8.     if (platformFamily.Equals("Windows.Desktop"))
    9.     {
    10.       return false;
    11.     }
    12.     else if (platformFamily.Equals("Windows.Mobile"))
    13.     {
    14.       return true;
    15.     }
    16.  
    17.     return false;  
    18.  
    19. #elif UNITY_WP_8_1
    20.     return true;
    21. #elif UNITY_WSA
    22.   return false;
    23. #else
    24.     return false;
    25. #endif
    26.   }
    27.  
     
    mr_zog, Jan 13, 2017
    #13

  14. Tautvydas-Zilys

    Tautvydas-Zilys

    Unity Technologies

    Joined:
    Jul 25, 2013
    Posts:
    10,680
    That should almost work just fine in 5.6 with IL2CPP - you'll just have to change "NETFX_CORE" define to "ENABLE_WINMD_SUPPORT". As I said before, we aim to make IL2CPP compatible with code you used with .NET scripting backend.

    NETFX_CORE define used to mean two things: that your C# scripts were compiled against .NET Core 5 class libraries, and that you could reference ".winmd" files from scripts. With IL2CPP in 5.6, you can target full .NET 4.6 desktop class libraries. .NET 4.6 for desktop is almost entirely a superset of .NET Core 5, but it has minor differences - so we decided to not define NETFX_CORE instead introduce a new define that means that you can reference ".winmd" files from C# scripts. We also have new defines for different API compatibility level player setting on all platforms on Mono and IL2CPP scripting backend - NET_2_0, NET_2_0_SUBSET and NET_4_6.

    The minor differences I mentioned is the lack of these types in .NET 4.6 profile that used to work on .NET scripting backends:

    Code (csharp):
    1. Microsoft.VisualBasic.CallType
    2. Microsoft.VisualBasic.CompilerServices.Conversions
    3. Microsoft.VisualBasic.CompilerServices.DesignerGeneratedAttribute
    4. Microsoft.VisualBasic.CompilerServices.IncompleteInitialization
    5. Microsoft.VisualBasic.CompilerServices.NewLateBinding
    6. Microsoft.VisualBasic.CompilerServices.ObjectFlowControl
    7. Microsoft.VisualBasic.CompilerServices.Operators
    8. Microsoft.VisualBasic.CompilerServices.OptionCompareAttribute
    9. Microsoft.VisualBasic.CompilerServices.OptionTextAttribute
    10. Microsoft.VisualBasic.CompilerServices.ProjectData
    11. Microsoft.VisualBasic.CompilerServices.StandardModuleAttribute
    12. Microsoft.VisualBasic.CompilerServices.StaticLocalInitFlag
    13. Microsoft.VisualBasic.CompilerServices.Utils
    14. Microsoft.VisualBasic.Constants
    15. Microsoft.VisualBasic.HideModuleNameAttribute
    16. Microsoft.VisualBasic.Strings
    17. System.Collections.Immutable.IImmutableDictionary`2
    18. System.Collections.Immutable.IImmutableList`1
    19. System.Collections.Immutable.IImmutableQueue`1
    20. System.Collections.Immutable.IImmutableSet`1
    21. System.Collections.Immutable.IImmutableStack`1
    22. System.Collections.Immutable.ImmutableArray
    23. System.Collections.Immutable.ImmutableArray`1
    24. System.Collections.Immutable.ImmutableDictionary
    25. System.Collections.Immutable.ImmutableDictionary`2
    26. System.Collections.Immutable.ImmutableHashSet
    27. System.Collections.Immutable.ImmutableHashSet`1
    28. System.Collections.Immutable.ImmutableInterlocked
    29. System.Collections.Immutable.ImmutableList
    30. System.Collections.Immutable.ImmutableList`1
    31. System.Collections.Immutable.ImmutableQueue
    32. System.Collections.Immutable.ImmutableQueue`1
    33. System.Collections.Immutable.ImmutableSortedDictionary
    34. System.Collections.Immutable.ImmutableSortedDictionary`2
    35. System.Collections.Immutable.ImmutableSortedSet
    36. System.Collections.Immutable.ImmutableSortedSet`1
    37. System.Collections.Immutable.ImmutableStack
    38. System.Collections.Immutable.ImmutableStack`1
    39. System.Diagnostics.StackFrameExtensions
    40. System.Globalization.GlobalizationExtensions
    41. System.Linq.ImmutableArrayExtensions
    42. System.Net.Http.RtcRequestFactory
    43. System.Numerics.Vector
    44. System.Numerics.Vector`1
    45. System.Numerics.VectorExtensions
    46. System.Reflection.AssemblyExtensions
    47. System.Reflection.AssemblyFlags
    48. System.Reflection.AssemblyHashAlgorithm
    49. System.Reflection.DeclarativeSecurityAction
    50. System.Reflection.DispatchProxy
    51. System.Reflection.EventInfoExtensions
    52. System.Reflection.ManifestResourceAttributes
    53. System.Reflection.Metadata.AssemblyDefinition
    54. System.Reflection.Metadata.AssemblyDefinitionHandle
    55. System.Reflection.Metadata.AssemblyFile
    56. System.Reflection.Metadata.AssemblyFileHandle
    57. System.Reflection.Metadata.AssemblyFileHandleCollection
    58. System.Reflection.Metadata.AssemblyReference
    59. System.Reflection.Metadata.AssemblyReferenceHandle
    60. System.Reflection.Metadata.AssemblyReferenceHandleCollection
    61. System.Reflection.Metadata.BlobHandle
    62. System.Reflection.Metadata.BlobReader
    63. System.Reflection.Metadata.Constant
    64. System.Reflection.Metadata.ConstantHandle
    65. System.Reflection.Metadata.ConstantTypeCode
    66. System.Reflection.Metadata.CustomAttribute
    67. System.Reflection.Metadata.CustomAttributeHandle
    68. System.Reflection.Metadata.CustomAttributeHandleCollection
    69. System.Reflection.Metadata.CustomAttributeNamedArgumentKind
    70. System.Reflection.Metadata.DeclarativeSecurityAttribute
    71. System.Reflection.Metadata.DeclarativeSecurityAttributeHandle
    72. System.Reflection.Metadata.DeclarativeSecurityAttributeHandleCollection
    73. System.Reflection.Metadata.Ecma335.EditAndContinueLogEntry
    74. System.Reflection.Metadata.Ecma335.EditAndContinueOperation
    75. System.Reflection.Metadata.Ecma335.ExportedTypeExtensions
    76. System.Reflection.Metadata.Ecma335.HeapIndex
    77. System.Reflection.Metadata.Ecma335.MetadataAggregator
    78. System.Reflection.Metadata.Ecma335.MetadataReaderExtensions
    79. System.Reflection.Metadata.Ecma335.MetadataTokens
    80. System.Reflection.Metadata.Ecma335.TableIndex
    81. System.Reflection.Metadata.EntityHandle
    82. System.Reflection.Metadata.EventAccessors
    83. System.Reflection.Metadata.EventDefinition
    84. System.Reflection.Metadata.EventDefinitionHandle
    85. System.Reflection.Metadata.EventDefinitionHandleCollection
    86. System.Reflection.Metadata.ExceptionRegion
    87. System.Reflection.Metadata.ExceptionRegionKind
    88. System.Reflection.Metadata.ExportedType
    89. System.Reflection.Metadata.ExportedTypeHandle
    90. System.Reflection.Metadata.ExportedTypeHandleCollection
    91. System.Reflection.Metadata.FieldDefinition
    92. System.Reflection.Metadata.FieldDefinitionHandle
    93. System.Reflection.Metadata.FieldDefinitionHandleCollection
    94. System.Reflection.Metadata.GenericParameter
    95. System.Reflection.Metadata.GenericParameterConstraint
    96. System.Reflection.Metadata.GenericParameterConstraintHandle
    97. System.Reflection.Metadata.GenericParameterConstraintHandleCollection
    98. System.Reflection.Metadata.GenericParameterHandle
    99. System.Reflection.Metadata.GenericParameterHandleCollection
    100. System.Reflection.Metadata.GuidHandle
    101. System.Reflection.Metadata.Handle
    102. System.Reflection.Metadata.HandleComparer
    103. System.Reflection.Metadata.HandleKind
    104. System.Reflection.Metadata.InterfaceImplementation
    105. System.Reflection.Metadata.InterfaceImplementationHandle
    106. System.Reflection.Metadata.InterfaceImplementationHandleCollection
    107. System.Reflection.Metadata.ManifestResource
    108. System.Reflection.Metadata.ManifestResourceHandle
    109. System.Reflection.Metadata.ManifestResourceHandleCollection
    110. System.Reflection.Metadata.MemberReference
    111. System.Reflection.Metadata.MemberReferenceHandle
    112. System.Reflection.Metadata.MemberReferenceHandleCollection
    113. System.Reflection.Metadata.MemberReferenceKind
    114. System.Reflection.Metadata.MetadataKind
    115. System.Reflection.Metadata.MetadataReader
    116. System.Reflection.Metadata.MetadataReaderOptions
    117. System.Reflection.Metadata.MetadataStringComparer
    118. System.Reflection.Metadata.MetadataStringDecoder
    119. System.Reflection.Metadata.MethodBodyBlock
    120. System.Reflection.Metadata.MethodDefinition
    121. System.Reflection.Metadata.MethodDefinitionHandle
    122. System.Reflection.Metadata.MethodDefinitionHandleCollection
    123. System.Reflection.Metadata.MethodImplementation
    124. System.Reflection.Metadata.MethodImplementationHandle
    125. System.Reflection.Metadata.MethodImplementationHandleCollection
    126. System.Reflection.Metadata.MethodImport
    127. System.Reflection.Metadata.MethodSpecification
    128. System.Reflection.Metadata.MethodSpecificationHandle
    129. System.Reflection.Metadata.ModuleDefinition
    130. System.Reflection.Metadata.ModuleDefinitionHandle
    131. System.Reflection.Metadata.ModuleReference
    132. System.Reflection.Metadata.ModuleReferenceHandle
    133. System.Reflection.Metadata.NamespaceDefinition
    134. System.Reflection.Metadata.NamespaceDefinitionHandle
    135. System.Reflection.Metadata.Parameter
    136. System.Reflection.Metadata.ParameterHandle
    137. System.Reflection.Metadata.ParameterHandleCollection
    138. System.Reflection.Metadata.PEReaderExtensions
    139. System.Reflection.Metadata.PropertyAccessors
    140. System.Reflection.Metadata.PropertyDefinition
    141. System.Reflection.Metadata.PropertyDefinitionHandle
    142. System.Reflection.Metadata.PropertyDefinitionHandleCollection
    143. System.Reflection.Metadata.SerializationTypeCode
    144. System.Reflection.Metadata.SignatureAttributes
    145. System.Reflection.Metadata.SignatureCallingConvention
    146. System.Reflection.Metadata.SignatureHeader
    147. System.Reflection.Metadata.SignatureKind
    148. System.Reflection.Metadata.SignatureTypeCode
    149. System.Reflection.Metadata.StandaloneSignature
    150. System.Reflection.Metadata.StandaloneSignatureHandle
    151. System.Reflection.Metadata.StringHandle
    152. System.Reflection.Metadata.TypeDefinition
    153. System.Reflection.Metadata.TypeDefinitionHandle
    154. System.Reflection.Metadata.TypeDefinitionHandleCollection
    155. System.Reflection.Metadata.TypeLayout
    156. System.Reflection.Metadata.TypeReference
    157. System.Reflection.Metadata.TypeReferenceHandle
    158. System.Reflection.Metadata.TypeReferenceHandleCollection
    159. System.Reflection.Metadata.TypeSpecification
    160. System.Reflection.Metadata.TypeSpecificationHandle
    161. System.Reflection.Metadata.UserStringHandle
    162. System.Reflection.MethodImportAttributes
    163. System.Reflection.MethodInfoExtensions
    164. System.Reflection.PortableExecutable.Characteristics
    165. System.Reflection.PortableExecutable.CoffHeader
    166. System.Reflection.PortableExecutable.CorFlags
    167. System.Reflection.PortableExecutable.CorHeader
    168. System.Reflection.PortableExecutable.DirectoryEntry
    169. System.Reflection.PortableExecutable.DllCharacteristics
    170. System.Reflection.PortableExecutable.Machine
    171. System.Reflection.PortableExecutable.PEHeader
    172. System.Reflection.PortableExecutable.PEHeaders
    173. System.Reflection.PortableExecutable.PEMagic
    174. System.Reflection.PortableExecutable.PEMemoryBlock
    175. System.Reflection.PortableExecutable.PEReader
    176. System.Reflection.PortableExecutable.PEStreamOptions
    177. System.Reflection.PortableExecutable.SectionCharacteristics
    178. System.Reflection.PortableExecutable.SectionHeader
    179. System.Reflection.PortableExecutable.Subsystem
    180. System.Reflection.PropertyInfoExtensions
    181. System.Reflection.TypeExtensions
    182. System.StringNormalizationExtensions
    183. System.Text.CodePagesEncodingProvider
    184. System.Threading.PreAllocatedOverlapped
    185. System.Threading.ThreadPoolBoundHandle
     
    Last edited: Jan 13, 2017
    Tautvydas-Zilys, Jan 13, 2017
    #14

  15. castor76

    castor76

    Joined:
    Dec 5, 2011
    Posts:
    2,517
    IL2CPP with zip plugin I use crashes the player on x86 only. I believe the bug has been submitted but I am not sure how long it will take to be fixed, if fixed at all.
     
    castor76, Jan 18, 2017
    #15

  16. Mogurito

    Mogurito

    Joined:
    Sep 21, 2015
    Posts:
    11
    It doesn't work with Windows Store IAP.
    We could submit our game to the Windows Store and works fine, sadly we can't implement IAP because doesn't work with IL2CPP.
     
    Mogurito, Jan 19, 2017
    #16

  17. Tautvydas-Zilys

    Tautvydas-Zilys

    Unity Technologies

    Joined:
    Jul 25, 2013
    Posts:
    10,680
    Do you have a case number? We definitely fix bugs.

    Yeah, it's a known issue, but we're aiming to make it work for 5.6.
     
    Tautvydas-Zilys, Jan 23, 2017
    #17

  18. castor76

    castor76

    Joined:
    Dec 5, 2011
    Posts:
    2,517
    I will try to get the bug report number from the plugin author and post it here.
     
    castor76, Jan 23, 2017
    #18

  19. Astarorr

    Astarorr

    Joined:
    Jan 17, 2013
    Posts:
    41
    Two issues are preventing:
    1. Lack of IAP (should work in 5.6, i know)
    2. Lack of Win 8.1 support, which is important for mobiles
     
    Astarorr, Jan 23, 2017
    #19

  20. Mogurito

    Mogurito

    Joined:
    Sep 21, 2015
    Posts:
    11
    I'm so glad to hear that Unity is working on this. We really appreciate the effort, our thanks and best wishes.
     
    Mogurito, Jan 24, 2017
    #20

  21. mr_zog

    mr_zog

    Joined:
    Jan 21, 2014
    Posts:
    165
    Wasn't aware of that. This also includes Windows Phone 8.1?
    If so, this is a no-go for us, our WP8.1 user base is too big to drop.
    I know the OS has no future, but at current state, it's too important (and will remain so this year at least).
     
    mr_zog, Jan 24, 2017
    #21

  22. castor76

    castor76

    Joined:
    Dec 5, 2011
    Posts:
    2,517
    castor76, Jan 26, 2017
    #22

  23. Tautvydas-Zilys

    Tautvydas-Zilys

    Unity Technologies

    Joined:
    Jul 25, 2013
    Posts:
    10,680
    Tautvydas-Zilys, Jan 26, 2017
    #23

  24. mr_zog

    mr_zog

    Joined:
    Jan 21, 2014
    Posts:
    165
    Thanks to this thread and since we recently upgraded the Unity version used, which now generates working C# projects, I must says, during development of native code, the C# export is very powerful!

    E.g. if you have to implement some kind of login code using MSAuth:
    1) I implement the logic on the Unity side.
    2) I make a C# project export, and in that, I add the MS native stuff (actually modifying the Unity-C#-game logic scripts), which I can then test on the device within a matter of seconds instead of minutes if I'd have to re-export the whole game everytime I change an enum[1].

    So during development, I would say IL2CPP will not be considered an option, as long as C# is there.

    I would also like to note, that real games/apps are most likely to use native extensions, so please bear that in mind when making the final decision.


    [1]: We usually create isolated projects when integrating a new native feature, but it always makes trouble in the final game and even in a small demo project the iteration cycle time is huge compared to the C# project approach.
     
    mr_zog, Feb 3, 2017
    #24

  25. matt33315

    matt33315

    Joined:
    Mar 28, 2014
    Posts:
    94
    I have recently been Implementing Xbox Live functionality into my Windows 10 game and being able to implement the native code in the generated C# project has been a god sent. I was worried I would have to create some kind of plugin to be able to call the code from within Unity. I'm hoping that I will get to do more live projects in the future so I would really like the C# option to stay in. I guess I could achieve the same result by using the IL2CPP backend then implement the native features using the C++ api but with the C# being so user friendly I would only do this if I had to.
     
    matt33315, Feb 3, 2017
    #25

  26. Tautvydas-Zilys

    Tautvydas-Zilys

    Unity Technologies

    Joined:
    Jul 25, 2013
    Posts:
    10,680
    We have a goal to make this possible (to write scripts in VS with full intellisense in C#) for IL2CPP scripting backend too. In 5.6, we're making the part where you can call windows APIs from C# possible. And we've been working with Microsoft to enable intellisense for that (not sure if intellisense part will make it into 5.6).
     
    Tautvydas-Zilys, Feb 3, 2017
    #26

  27. mega-me

    mega-me

    Joined:
    Oct 26, 2017
    Posts:
    2
    My biggest problem is lack of C# output - from UWP side I need C# host project.

    I have created several LOB apps (not games) using Unity and UWP - with most business logic contained inside UWP project, interfacing easily with Unity. These apps use C# and lots of UWP libraries and C++ on host project side is not an option.

    I plan to try to hack the IL2CPP output to be WinRT component to be used within C# UWP project, but this should be an option from Unity's output.

    Other than that - being able to debug/step into Unity's C# code is really important.
     
    mega-me, Sep 14, 2018
    #27

  28. Tautvydas-Zilys

    Tautvydas-Zilys

    Unity Technologies

    Joined:
    Jul 25, 2013
    Posts:
    10,680
    There are two possible ways to achieve it.

    1. You can put all your C# business logic inside Unity. Then you get the benefits of everything getting IL2CPPd (so you get great performance), and interfacing with Unity C# code will be a breeze.
    2. You can change generated project to be a C# project. There's nothing requiring it to be a C++ project - UnityPlayer is already a Windows Runtime Component. You could even model it after the project generated by .NET scripting backend. Just don't forget to include GameAssembly.dll into the build. This approach has obvious disadvantages (and that's why we decided to not include it by default): You have two separate C# runtimes, which cannot directly interact with one another. That also means two garbage collectors, two sets of metadata, etc. That will affect performance and memory footprint greatly.

    That was fixed in 2018.2. You can now step through C# code on IL2CPP.
     
    Tautvydas-Zilys, Sep 14, 2018
    #28

  29. tomasvomacka

    tomasvomacka

    Joined:
    Nov 6, 2015
    Posts:
    4
    We are in a similar situation: We have 110 UWP DLLs, multiple nuget package UWP dependencies, and Unity is only being used in 1 of them to give us 3D and HoloLens/VR support. The app is a LOB app, not a game and all those 110 projects are C# projects that contain a lot of code, XAML views and logic. The way we use Unity now is just as a 3D XAML viewport with all the logic done in UWP (in those 110 UWP projects). Everything including meshes, textures, lightning, camera and animations is handled in C# UWP - we reference Assembly-CSharp.dll and all the UnityEngine*.dll files which gives us access to objects in the viewport and their scripts.

    So option 1 (putting all C# code into Unity) is not possible.

    Regarding option 2:
    "You have two separate C# runtimes, which cannot directly interact with one another." That was the job of the WinRTBridge, was it not? Creating a GameObject in UWP would create the same object in Unity and then it was possible to interact with the object from UWP code. Does it mean with IL2CPP this will no longer work?

    Edit:
    Looking at the sample app compiled using IL2CPP, it looks like that's the case indeed. For example, we are using the following code in our UWP DLL (not in Unity):

    Code (CSharp):
    1.  
    2. private void SetUnityMesh(UnityEngine.GameObject owner)
    3. {
    4. UnityEngine.MeshFilter meshFilter = owner.GetComponent<UnityEngine.MeshFilter>();
    5. if (meshFilter == null)
    6.    meshFilter = owner.AddComponent<UnityEngine.MeshFilter>();
    7.  
    8. UnityEngine.Mesh mesh = meshFilter.mesh;
    9. mesh.Clear();
    10. mesh.vertices = _unityVertices;
    11. mesh.uv = _unityUVs;
    12. mesh.triangles = _unityTriangles;
    13. }
    14.  
    This works fine with the NET scripting backend. How are we supposed to achieve the same with the IL2CPP? We'd need to access Unity objects and scripts somehow and that does not seem to be possible.
     
    Last edited: Oct 19, 2018
    tomasvomacka, Oct 19, 2018
    #29

  30. Tautvydas-Zilys

    Tautvydas-Zilys

    Unity Technologies

    Joined:
    Jul 25, 2013
    Posts:
    10,680
    No, WinRTBridge allowed us to call managed methods from our C++ player code. You were actually in the same .NET world as your scripts on .NET scripting backend, so you'd create the objects directly.

    Do you have a large amount of code that directly references Unity components? Everything referencing UnityEngine.dll or Unity APIs would have to be inside Unity project so it could be converted by IL2CPP. And then you can expose your own API that you can call from your C# code in Visual Studio on the UWP project side.
     
    Tautvydas-Zilys, Oct 19, 2018
    #30

  31. stonstad

    stonstad

    Joined:
    Jan 19, 2018
    Posts:
    659
    Hi @Tautvydas-Zilys! I'm glad you asked this question. Reason for not switching... our game is far along in its development cycle. It's a C#/XAML/UWP game which uses Unity w/ SwapChainPanel in a UserControl. The reason we aren't switching is because the game has really extensive UI (think Civilization) built in C#/XAML. There is also a C# portable class library which is shared between client and server (and also Unity) with about 900 C# model/logic classes. The ability to share C# object references between the UWP application (which has XAML and non-rendering logic) and Unity is really nice. The only way to do that with IL2CPP is to convert existing screens and business logic to Windows Runtime classes -- which can't do inheritance and in general, are not as reusable as a C# PCL.

    It would be awesome if there was some way to have C# code on the UWP side talk to C# code in Unity... pretty sure you guys killed that feature with IL2CPP.

    *edited for grammar
     
    Last edited: Jan 22, 2019
    stonstad, Oct 26, 2018
    #31

  32. Tautvydas-Zilys

    Tautvydas-Zilys

    Unity Technologies

    Joined:
    Jul 25, 2013
    Posts:
    10,680
    Yeah, there's no direct way to talk with Unity C# code from .NET C# code with IL2CPP. The only way to do it is to add a C++ proxy in between. One approach that might or might not work would be to move ALL your C# code to Unity side, and drive swapchainpanel from there. Not sure how feasible that is with your project.
     
    Tautvydas-Zilys, Oct 26, 2018
    #32

  33. dadude123

    dadude123

    Joined:
    Feb 26, 2014
    Posts:
    789
    Our biggest issue is that System.Linq.Expressions is not possible in IL2CPP.
    Probably not something you guys can realistically fix, right?
     
    dadude123, Oct 26, 2018
    #33

  34. JoshPeterson

    JoshPeterson

    Unity Technologies

    Joined:
    Jul 21, 2014
    Posts:
    6,936
    @dadude123

    It is possible for us to support it, since Mono has a Linq expression interpreter written in C# in the class library code, and IL2CPP can convert that C# code. We have a few limitations at the moment.

    First, the Linq expression interpreter uses a lot of reflection, so it is not kind to managed code stripping. At the moment we can work around that with a link.xml file, as described in this issue:

    https://issuetracker.unity3d.com/is...rown-in-build-with-newtonsoft-dot-json-plugin

    In the 2019.x release cycle we will pull in some newer class library code from Mono which handles the preservation of this code in managed code stripping automatically, so the link.xml file won't be necessary. I'll resolve this issue when that is the case.

    Second, the Linq expression interpreter itself works, but it can hit some corner cases for AOT compilation of value-type generics that IL2CPP does not handle now. Unfortunately, it is not always clear which expressions you might write in C# code which will hit these limitations, and we don't have a good way to detect them until run time. So it is difficult to use, as you need to have test coverage for all of your use cases to ensure an AOT limitation is not lurking.

    One of our next development items for IL2CPP is support for value-type generics. Once this is ready, we will have full support for the Linq expression interpreter. I don't have a timeline for this to be complete yet though.
     
    JoshPeterson, Oct 26, 2018
    #34

  35. stonstad

    stonstad

    Joined:
    Jan 19, 2018
    Posts:
    659
    I appreciate you thinking of ways to make it work. I have about 90 C#/XAML UWP screens. Bringing them into Unity would be a rewrite. My current thinking is that I'll be stuck on the last version of Unity to support the Mono scripting backend :(

    The other option is to use C++/Windows Runtime. I would need to convert these C# screens to XAML/C++ and then convert my C# PCL library. I can see the screens getting converted since it is 1:1 API surface area. BUT the business object library (written as a C# PCL) would need to be rewritten because it uses inheritance.

    Strange, because the language of choice in Unity is C#. I imagine it was not an easy technical decision to deprecate the Mono backend and lose C# language interoperability with UWP. Also surprising given that the majority of UWP applications published to the store are written in C#.
     
    stonstad, Oct 27, 2018
    #35

  36. Tautvydas-Zilys

    Tautvydas-Zilys

    Unity Technologies

    Joined:
    Jul 25, 2013
    Posts:
    10,680
    Yeah, a rewrite like that doesn't sound feasible.

    How big is the API area that you call into code on Unity side from your UWP project? Have you considered the approach I showed in this thread?
     
    Tautvydas-Zilys, Oct 27, 2018
    #36

  37. stonstad

    stonstad

    Joined:
    Jan 19, 2018
    Posts:
    659
    I really appreciate your thoughts on how to move forward.

    Short answer -- quite big. There's a PCL library of approximately 900 C# classes that is shared between client, server, and Unity. The client is UWP/C#/XAML, server is Azure/WebAPI/C#, and then Unity/C#. In a world where the Mono scripting backend is not deprecated, it is an amazing design because it allows me to share the same business object library across all three layers. This greatly simplifies state management, i.e I get to share object references between UWP and Unity and reconstruct the same on the server for authoritative state management. So my principle communication between UWP and Unity are C# object instances.

    Here are some things I've tried in pursuit of IL2CPP:
    • Converting the business object library to a Windows Runtime compontent. Doesn't work because I rely on extensive inheritance. Changing to Windows Runtime also requires rework of the game server.
    • Converting UWP/XAML/C# screens to UWP/XAML/C++. While helpful, this does not resolve the class library hang-up.
    • Rebuild UIs in Unity and continue using business library in Unity. There are 90 XAML screens with code behind. (The asset store package, Noesis, doesn't allow accessing of variables via code.). I feel like this would be a significant effort, too!
    I think where I am ... is that I'll need to ship on the latest version of Unity that supports the Mono scripting backend. Is Unity still creating LTS Releases? I'll just need to stay on the best available LTS release with Mono.

    Architecture Diagram
    https://imgur.com/a/AVqzyUn

    *edited to add architecture diagram, in case it might help.
     
    Last edited: Oct 28, 2018
    stonstad, Oct 28, 2018
    #37

  38. Tautvydas-Zilys

    Tautvydas-Zilys

    Unity Technologies

    Joined:
    Jul 25, 2013
    Posts:
    10,680
    Nit: it's not Mono scripting backend - UWP never supported that. It's called .NET scripting backend because it's using Microsoft's .NET runtime.

    Anyway, .NET scripting backend is only going away in 2019.1, so it will still be supported in 2018 LTS until 2020.
     
    Tautvydas-Zilys, Oct 29, 2018
    #38

  39. Noemata

    Noemata

    Joined:
    Dec 14, 2018
    Posts:
    6
    stonstad, it is possible to retain your current approach and switch to IL2CPP it's just not at all obvious how this is done efficiently with 2018.3+. If you message me privately we can discuss this in more detail.
     
    Noemata, Jan 11, 2019
    #39

  40. stonstad

    stonstad

    Joined:
    Jan 19, 2018
    Posts:
    659
    Absolutely! PM'd. Thank you.
     
    stonstad, Jan 11, 2019
    #40

  41. briank

    briank

    Joined:
    Mar 25, 2017
    Posts:
    74
    Just adding that I see significantly worse performance (i.e., code running longer and larger memory consumption), on x86 IL2CPP platforms (e.g. HoloLens) when compared to .NET scripting backend.

    I haven't been able to find a specific cause for this although clearly IL2CPP is playing a role. Interestingly, 2018.3 showed some improvements in memory usage (2018.2 IL2CPP memory usage was downright awful in my test app), but the speed is still bad in 2018.3 when comparing .NET and IL2CPP.

    If it makes sense, I can share a sample project/file a bug.
     
    briank, Jan 15, 2019
    #41

  42. Noemata

    Noemata

    Joined:
    Dec 14, 2018
    Posts:
    6
    If IL2CPP had the following capabilities, most UWP integration issues would go away.

    (1) Ability to link directly to C# libraries from IL2CPP without having the libs going through the IL2CPP translation process. The native C# compiler is significantly more performant than IL2CPP, so having a "References" like linkage rather than an IL translation of the DLL would go a long way toward resolving integration problems. Let the VS linker do the linking. .Net Standard 2.0 has resolved a lot of the pain associated with UWP, now with IL2CPP, the pain has come back because libraries are not translated correctly, defeating the benefits.

    (2) Better integration with C# in general. Once IL2CPP has done it's thing, it becomes challenging for non-C++ devs to work with what's been generated. Again, the UWP C# Native compiler is very, very good at what it does, so being able to leverage it more is essential.

    (3) Better support for Unity in a XAML container with full C# support for the XAML side of things. Please let us use the real System.Reactive in our UWP apps. Likewise for the hundreds of other amazing libraries (nuget packages) out there.

    (4) Leverage the UWP C# Native compiler if at all possible.

    (5) Bundle up more of Unity into a .Net Standard DLL so we can use parts of Unity outside of Unity, especially for iterative non-UI related development and unit testing. This would also allow the C# Native compiler to contribute more to performance improvements.

    (6) Please retain the current App Launcher, GameEngine DLL separation as it has many benefits.

    (7) Finance, and help the fellow working on a Nuget system for Unity. Why not just work with the best lib packaging solution available for .Net? C# and Nuget our now synonymous outside of the Unity universe.

    (8) Last, but not least, have a version of the editor Play mode that runs as a UWP App, which would facilitate having much more UWP capability light up in the editor on Windows 10. This could be implemented as a XAML Island and a UWP API access layer. It's not really that hard anymore. Given it's 2019, all of Unity should be a UWP app at this point.

    The folks still in denial over UWP are lost to the future anyhow.
     
    Noemata, Jan 15, 2019
    #42
    HighSkillz likes this.

  43. stonstad

    stonstad

    Joined:
    Jan 19, 2018
    Posts:
    659
    Tautvydas-Zilys, I definitely appreciate your efforts. At the same time, I'd like to echo some of @Noemata's statements. The UWP integration story with IL2CPP feels like a step backwards to me. IL2CPP simplifies Unity architecture but at what expense if user adoption among UWP developers is greatly hindered? Again, I really appreciate your work and I'm just sharing a single opinion.
     
    stonstad, Jan 16, 2019
    #43
    HighSkillz likes this.

  44. Tautvydas-Zilys

    Tautvydas-Zilys

    Unity Technologies

    Joined:
    Jul 25, 2013
    Posts:
    10,680
    It indeed makes it harder embed Unity in your UWP XAML app. That is unfortunate side effect and one bit we missed when looking at use cases. I will be writing some documentation that will hopefully make it more clear how to approach this.

    However, at the same time it makes UWP a much more similar platform to other Unity platforms and makes it easier to make multiplatform games. Since this is the primary goal of the engine, we believe this is the important bit.
     
    Tautvydas-Zilys, Jan 16, 2019
    #44

  45. makaqo

    makaqo

    Joined:
    Sep 16, 2015
    Posts:
    22
    With the change to il2cpp it becomes impossible to porting a game to UWP, I'm talking about:
    - In-App purchases
    - Ads integration
    - Any other native integration

    the last month of life I spent it reading your tips to communicate unity with the xaml.cpp and I tried everything but it did not work.

    il2cpp is another hit to the Windows Store and the number of games available in it
     
    makaqo, Jan 17, 2019
    #45

  46. Tautvydas-Zilys

    Tautvydas-Zilys

    Unity Technologies

    Joined:
    Jul 25, 2013
    Posts:
    10,680
    Are you not able to call into those plugins directly from your C# scripts? Communication between XAML and Unity should only be needed for apps that embed unity as one of their components, rather than games that just want to call into some APIs.
     
    Tautvydas-Zilys, Jan 17, 2019
    #46

  47. makaqo

    makaqo

    Joined:
    Sep 16, 2015
    Posts:
    22
    Unity integration with il2cpp and Vungle winmd does not work, Windows Ads does not work either.
    When you develop a multiplatform game (Appstore, Google Play, Amazon Appstore) it is easier to call ads natively and the use of il2cpp makes this technique impractical.
     
    makaqo, Jan 20, 2019
    #47

  48. Noemata

    Noemata

    Joined:
    Dec 14, 2018
    Posts:
    6
    If you create your own Launcher layer that replaces the code generated Unity Launcher (cpp), you can make arbitrary calls between your Unity IL2CPP generated code and your C# code on the Launcher side. Thus you have the ability to work around any particular limitation of IL2CPP and still have the full benefits of the C# Native compiler when building for UWP. This capability, in fact, makes UWP the most performant supported Unity platform. Unfortunately, leveraging this capability is not easily discoverable.
     
    Noemata, Jan 22, 2019
    #48

  49. Noemata

    Noemata

    Joined:
    Dec 14, 2018
    Posts:
    6
    Based on some additional experiments that I've done, I no longer understand why the C# Native compiler is not being leveraged to a greater extent for UWP builds. IL2CPP is really good, but the UWP C# Native compiler is 2-10x better and can handle very tricky managed code transformations, including everything Linq can throw at it. The now deprecated C# back end could have been reworked to use the Visual Studio compiler for all aspects of creating a release build. Improving on the UWP C# Native compiler is a tall order (big problem), and drifting away from coreclr (bigger problem) will lead to dead ends. The best runtime GC and compiler backends are currently part of the UWP build environment. It makes more sense to bring those to other platforms than morphing Unity into a separate Unity Universe. Get Microsoft to give you their compiler framework and let C# shine on all the other supported platforms. After all, I don't think Unity wants to be in the cross compiler business when those investments can be better spent on improving the 3D engine.

    Oh, and the Visual Studio C# editor experience is another little item that is hard to beat.
     
    Noemata, Jan 22, 2019
    #49

  50. Tautvydas-Zilys

    Tautvydas-Zilys

    Unity Technologies

    Joined:
    Jul 25, 2013
    Posts:
    10,680
    IL2CPP was built for cross platform capabilities in mind. .NET native runs on exactly 1 platform right now. Porting .NET native to all platforms Unity supports is not feasible (otherwise we would have just ported Mono and not bothered with IL2CPP).

    IL2CPP was designed with exact requirements Unity has in mind (like embedding API). Furthermore, it allows us to use the same class libraries on all platforms, and that allows us to provide consistent experience no matter which platform you're targeting through Unity. There were reasons why .NET scripting backend was such a pain for cross platform games, and porting to UWP from let's say Windows Standalone would always be a miserable experience.

    Even though .NET gained .NET Standard 2.0 support on UWP, for all practical purposes it's not really useful because it requires minimum OS version of 16299, and you have to choose between not supporting full user base or you have to fork your code base. IL2CPP does not have this restriction.
     
    Tautvydas-Zilys, Jan 22, 2019
    #50
Page 1 of 2