Search Unity

Unity Future .NET Development Status

Discussion in 'Experimental Scripting Previews' started by JoshPeterson, Apr 13, 2021.

  1. JoshPeterson

    JoshPeterson

    Unity Technologies

    Joined:
    Jul 21, 2014
    Posts:
    5,561
    We’ve had a good bit of interest on various forum threads about Unity’s plans for C# and .NET in the future. Microsoft has been pushing the .NET ecosystem in a number of beneficial directions, and we at Unity want to bring those improvements to our users as soon as we can.

    While we are not in a position to mention specific details about when various newer .NET features will come to Unity releases, we would like to provide more transparency into our ongoing work to bring these features to Unity.

    Our goal with this forum thread is to provide updates on what we are working on, and when we think it will be available to Unity releases. As with any large software project, there are many unknowns, so everything discussed here is subject to change.

    Please do not consider discussions on this thread to be official announcements, those will happen via release notes and blog posts. But we hope that more information will allow you to have more insight into our progress.
     
  2. JoshPeterson

    JoshPeterson

    Unity Technologies

    Joined:
    Jul 21, 2014
    Posts:
    5,561
    We wanted to give an update about our current progress towards support of new .NET features in Unity. I’ll try to list the work items we know about now and provide both a likely release as well as confidence about how likely we are to make that release goal.

    Everything here is subject to change!

    Update Unity’s fork of Mono to the latest code from the upstream Mono repo

    (You can follow the development in our fork here: https://github.com/Unity-Technologies/mono/tree/unity-master-new-unitychanges)

    Unity’s fork of Mono is about two years behind the latest upstream code.
    • So this effort pulls in many bug fixes from upstream Mono.
    • It also improves the managed debugger.
    • It will allow Mono to run in 32-bit floating point mode, improving floating point performance.
    • It brings in more .NET Core class library implementation, including many changes to the way the class library code interacts with platform-specific code.
    When this change is available in Unity, it won’t have any new .NET features. But it does provide us a firm foundation to use to ship new .NET features in Unity.

    The internal cut-off for Unity 2021.2 is approaching (weeks away), but we are 95% confident that this work will land in time.

    EDIT: This work landed in Unity 2021.2.0a18

    Add support for .NET Standard 2.1

    Many of the API that users have been asking for from .NET Core (namely Span and ranges) are in .NET Standard 2.1. We’re planning to first add .NET Standard 2.1 support to Unity’s existing .NET Framework-based ecosystem. Although .NET Framework does not support .NET Standard 2.1, Mono’s class libraries do support it, so we should be able to provide a nice bridge to a .NET Core-based ecosystem.

    We’re hoping to get this into Unity 2021.2, but it is not far along enough to be sure, I’m 75% confident that we will make it though.

    EDIT: .NET Standard 2.1 support will be available in Unity 2022.1.0a3. It will also be available in a 2021.2 beta release. I'll update here when I know the version.

    EDIT 2: .NET Standard 2.1 support will be available in Unity 2021.2.0b6.

    Complete C# 8 support

    The newest Mono code mentioned above has default interface methods support. We still need to add this support to IL2CPP as well.

    This, along with .NET Standard 2.1 support, will give Unity users full access to C# 8 features.

    We’re hoping to get this into Unity 2021.2, but it is not far along enough to be sure, I’m 75% confident this one will make it as well.

    EDIT: Default interface methods support is available in both Mono and IL2CPP in Unity 2021.2.0a21 and later.

    EDIT 2: I was incorrect, Unity 2021.2.0a21 does not yet have default interface methods support. I'll update this part of the post later when we actually have it shipped properly.

    EDIT 3: Default interface methods support (and full C# 8 support) will be available in Unity 2022.1.0a3. It will also be available in a 2021.2 beta release. I'll update here when I know the version.

    EDIT 4: Default interface methods and full C# 8 support will be available in Unity 2021.2.0b6.

    Complete C# 9 support

    We’d like to have covariant return type support in Mono and IL2CPP for Unity 2021.2. This will bring full C# 9 support to Unity users as well.

    We still have some discovery to do on this one, so I’m maybe 50% confident this will make Unity 2021.2.

    EDIT: We don't plan to have covariant return type support in Unity 2021.2. Other C# 9 features that do not depend on runtime support are present in Unity 2021.2 alphas.

    .NET 6 support

    This one is still a bit fuzzy. We would like to have something out in a preview in the fall of 2021 to coincide with .NET 6 release from Microsoft. I expect that this will be .NET 6 based (not .NET 5 based), as that is the long-term-support release from Microsoft. So Unity will likely skip .NET 5 entirely.

    At the moment it looks like the JIT runtime here will be Mono, but that is still uncertain. We may need to move directly to CoreCLR for .NET 6 support.

    The biggest hurdles are:
    • This is a breaking change for all Unity users. Any assemblies compiled against mscorlib.dll from the .NET Framework ecosystem will not work, and must be recompiled.
    • The .NET Core ecosystem does not support domain reloading, which is a fundamental requirement of the Unity Editor. We have done work to use Assembly Load Context instead, but that will be a breaking change, and will require time to implement properly, both from the Unity side and in user projects.
    We’re not far along enough in this work yet for me to give a meaningful confidence level about when it will ship.
     
    Last edited: Jul 27, 2021
  3. Knil

    Knil

    Joined:
    Nov 13, 2013
    Posts:
    66
    Thanks for sharing with us, you might want to pin this.
     
    phobos2077, Tanner555 and GliderGuy like this.
  4. chrisk

    chrisk

    Joined:
    Jan 23, 2009
    Posts:
    699
    Hi, Josh, thanks for the info and I really appreciate you are really trying to help.
    It seems like you have a lot on your plate and I'm a bit worried if you will burn out before reaching the goal. ^^

    To be honest, the only thing I'm interested in is the .NET 6 support. The biggest problem I had was slow Editor performance and long iteration time as project size grows. I currently ditched Unity because it was too painful to use and moved Unreal right now. I'm really happy with Unreal but I miss C#. I vowed to myself not to start another large-scale project on Unity unless Unity gets rid of Domain Reload and improves Editor performance. I believe .NET is the only answer.

    Mono will be history soon and it has no future. And my question is that, are all support for .NetStandard, C# 8, 9 necessary steps for .NET 6? I'm sure it's useful but I'm not certain if we need to beat around the bush instead of going to the goal directly. It looks like you will be quite busy throughout the year supporting Mono. .NET 6 will probably give us everything you mentioned above anyway, no?

    I'm really excited about the .NET preview later this year. I suppose it is an independent build without Mono, right? If so, it is really a good decision. Rolling in smoothly into the existing eco-system will be very difficult with all the old baggages to carry around. It will be much easier to add Mono migration support after it's released first.

    Please keep the good work.
     
  5. DinostabOMG

    DinostabOMG

    Joined:
    Jan 4, 2014
    Posts:
    21
    Exciting news. While breaking changes are happening, is there any chance of rectifying the funky Unity-only behavior of the null coalescing and null propagating operators? While I understand the reasons for the null equality override that causes this issue, the concern seems outdated in a context where Unity development has become more professionalized.

    The operators themselves are a very popular feature, and I'm unfortunately put in a position where I constantly have to steer my teams away from them, to their dismay and indeed skepticism. It seems to me that exposing a public `Object.destroyed` member would be a good tradeoff for getting to use more updated language features - even if this were only made optional in project settings.
     
  6. neuecc

    neuecc

    Joined:
    Apr 20, 2014
    Posts:
    112
    Thank you.
    I'm really looking forward to the new .NET and C#.

    One thing that bothers me about this story is Span.
    There are two modes of Span, one called Fast Span and the other called Slow Span.
    There is a big performance difference between them.

    I think we have to wait for CoreCLR before we can start using Fast Span,
    but one more thing, I think we need to support IL2CPP.

    It would be nice if the status of Fast Span support could be made visible.
     
  7. Issun

    Issun

    Joined:
    Nov 7, 2013
    Posts:
    11
    This is great news and something I hope that comes sooner rather than later, and that you can stay up to date with the latest releases!

    One thing I think you guys really need to get on is the Visual Studio integration. Unity projects are still dodgy and not real .csproj files, and lack features such as project references, which is really important for some projects such as Client/Server games, where multiple projects are needed, with shared projects between. Something I am working on. I was shocked to find out a few months ago that project references are not supported, and that I had to add post-build command arguments to copy the generated DLL files into the unity scripts folder to use them, this is just a bit dodgy and removes features such as debugging and being able to step into code from the shared project, as there is no code available in the DLLs, metadata.

    I would be glad to talk to you more about this if you need more feedback.
     
    phobos2077, Ramobo, bdovaz and 2 others like this.
  8. Gladyon

    Gladyon

    Joined:
    Sep 10, 2015
    Posts:
    335
    Pretty sure that you can generate the pdb and copy them along with the dlls.
    I know that it is possible to attach Visual Studio and debug mods for games allowing loading dlls at runtime.

    But you're 100% right, improving Visual Studio <--> Unity link would be a very good idea.
    Especially the attachement which sometimes do not work well, and the breakpoints which will not always work (maybe because of generics, not sure about it).
    Unfortunately I'm pretty sure that it's not the same team in Unity who is responsible for that.
     
    Issun likes this.
  9. DrummerB

    DrummerB

    Joined:
    Dec 19, 2013
    Posts:
    127
    How would a destroyed property fix the null coalescing and null propagating operators? As far as I understand, the problem with those is that they cannot be overridden and always check the true null state, instead of the custom null comparison.
     
  10. Thaina

    Thaina

    Joined:
    Jul 13, 2012
    Posts:
    616
    I think the point is, we then could have unity in newer version have a converter to convert code that use implicit conversion from GameObject to boolean into GameObject.destroyed instead
     
  11. JoshPeterson

    JoshPeterson

    Unity Technologies

    Joined:
    Jul 21, 2014
    Posts:
    5,561
    Good point, done!
     
  12. JoshPeterson

    JoshPeterson

    Unity Technologies

    Joined:
    Jul 21, 2014
    Posts:
    5,561
    Yes, we do need to accomplish all of these step to get to .NET 6 support.

    Mono already supports .NET Standard 2.1, C# 8 and C# 9 (although there might be some missing there, I'm not sure yet). So most of the work for these tasks will be Unity and IL2CPP. Honestly, I listed these tasks as separate steps because they are differently logically, but they don't require nearly as much effort as the first task of upgrading to the latest Mono and the last task of full .NET 6 support.

    I'm not sure about this yet. Our current plan is to continue to use Mono as the JIT runtime solution with the .NET 6 class libraries from corefx (the same ones used for .NET 6 from Microsoft). But there are still some unknowns around that. Here is a post on another thread where I recently tried to summarize the .NET ecosystem as we see it and what we plan to do: https://forum.unity.com/threads/net-5-support.839890/page-6#post-7029694
     
    phobos2077, cxode, Ramobo and 3 others like this.
  13. JoshPeterson

    JoshPeterson

    Unity Technologies

    Joined:
    Jul 21, 2014
    Posts:
    5,561
    This is not something that we want to tie to the .NET upgrade work, as breaking changes for the move to .NET 6 will likely be possible to catch at build time. This breaking change would probably only be detected at run time, which makes it more difficult to diagnose with useful errors.

    With that said, this change is likely not off the table, but is outside the scope of my team. I'll ask the team which might tackle it though.
     
  14. JoshPeterson

    JoshPeterson

    Unity Technologies

    Joined:
    Jul 21, 2014
    Posts:
    5,561
    I'm not familiar with these two modes of Span. Can you provide links to documentation about them? I'd like to learn more.
     
  15. JoshPeterson

    JoshPeterson

    Unity Technologies

    Joined:
    Jul 21, 2014
    Posts:
    5,561
    This really is our long-term intention. There will always be some lag between a new .NET release from Microsoft and Unity's adoption of it. But our goal is to make this lag a fixed, predictable time so that users can plan ahead.
     
    phobos2077, Ghat-Smith, cxode and 5 others like this.
  16. JoshPeterson

    JoshPeterson

    Unity Technologies

    Joined:
    Jul 21, 2014
    Posts:
    5,561
    Thanks for the feedback on this. I'll bring it up with the team that handles it. I don't think it is tied to the .NET upgrade, but certainly it seems there are areas here where Unity can improve.
     
  17. sebas77

    sebas77

    Joined:
    Nov 4, 2011
    Posts:
    1,388
    The biggest elephant in the room here is the GC implementation.
     
    KAJed and rzubek like this.
  18. sebas77

    sebas77

    Joined:
    Nov 4, 2011
    Posts:
    1,388
    This is related to my previous post. Fast Span cannot be implemented as long as Unity uses their old GC implementation as the GC must be aware of the Span references (don't remember the details but can be easily found on google).
     
  19. xoofx

    xoofx

    Unity Technologies

    Joined:
    Nov 5, 2016
    Posts:
    347
    That's not completely correct. Unity today is using a (stack-root) conservative GC mode and it's an orthogonal problem to the Fast Span implementation. A conservative GC is more conservative than a normal GC, but it still tracks references on the stack. That being said the work required to support Fast Span is still necessary, but that was brought to Mono a few years ago already, so we should in theory benefit fast span (I haven't checked how well this is working in Mono). The codegen won't be as good as CoreCLR, but that will help to smooth the transition to it.
     
    Jes28 and sebas77 like this.
  20. Issun

    Issun

    Joined:
    Nov 7, 2013
    Posts:
    11
    Yes probably not tied to .NET version at all, unless switching to .NET Core / .NET the csproj structure is considerably different. Thanks for replying to my concerns, it pleases me to see you guys stepping the right direction.
     
  21. sebas77

    sebas77

    Joined:
    Nov 4, 2011
    Posts:
    1,388
    Ah so you are saying that the current GC implementation would already support Fast Span? Last time I asked I thought that the GC implementation was one of the biggest obstacle to overcome, but tbh this part of the CLR is not clear to me as I have read about it just once a long time ago.
     
  22. Prodigga

    Prodigga

    Joined:
    Apr 13, 2011
    Posts:
    1,023
    There are some features that are still not supported properly in IL2CPP. IE exception filters:
    https://forum.unity.com/threads/il2cpp-exception-filter-support-eta.1087604/#post-7010431

    I wish there was a comprehensive list of things that are and aren't supported when comparing IL2CPPs version of C# to the version of C# Unity claims to support. Its not enough to know unity has support for, say, C#8 or whatever - I guess we need a clear breakdown of whats actually supported with each version and what isn't. Preferably a single page that lists the C# feature and which unity version onwards supports that feature. Or something that effect. One source of truth where I can check to make sure I'm not using something that'll break on device but work fine in editor.
     
  23. GoGoGadget

    GoGoGadget

    Joined:
    Sep 23, 2013
    Posts:
    775
    I would just like to applaud the Unity team here on such clear, and honest communication with regards to such a core engine feature. Seeing this fills me with confidence that Unity scripting is on the right track, and working on solid, measurable improvements in reasonable time frames.

    Good luck to the Unity team and keep up the good work with .NET and IL2CPP!
     
  24. AngryAnt

    AngryAnt

    Keyboard Operator Moderator

    Joined:
    Oct 25, 2005
    Posts:
    3,045
    Thank you for the thorough overview - an excellent roadmap to look forward to :)
    On the topic of planning ahead: Do any of these moves hold the potential to disrupt use of Cecil on Unity-compiled assemblies? On the surface I would not expect so, but wanted to verify in case we do indeed need to account for an eventuality like that.
     
    GliderGuy and Prodigga like this.
  25. joncham

    joncham

    Unity Technologies

    Joined:
    Dec 1, 2011
    Posts:
    270
    I assume you mean the ability for you to use Cecil to modify the compiled assemblies? I would expect you can continue to use Cecil long into the future. If you care about which assemblies are referenced (e.g. mscorlib) you will need to account for any changes. Additionally, any new IL/runtime features may require support in Cecil and thus you migrating to a newer version.
     
    GliderGuy likes this.
  26. AngryAnt

    AngryAnt

    Keyboard Operator Moderator

    Joined:
    Oct 25, 2005
    Posts:
    3,045
    Excellent! Exactly my meaning and expectation. Thanks :)
     
  27. hez2010

    hez2010

    Joined:
    Jun 7, 2019
    Posts:
    4
    phobos2077, Knil and Enderlook like this.
  28. xoofx

    xoofx

    Unity Technologies

    Joined:
    Nov 5, 2016
    Posts:
    347
    Any reasons to not use asmdef? They are currently the most direct equivalent of csproj files (although they are not as versatile) and they do work in a similar way like ProjectReferences. If you add dependencies between asmdef, they will generate ProjectReferences in the csproj files. So I'm curious what is not working with them today?

    That being said, we have a medium term plan (e.g not this year, but hopefully we can start to evaluate this next year) to move from asmdef to new SDK csproj file, with the additional benefit of bringing support for NuGet.
     
  29. xoofx

    xoofx

    Unity Technologies

    Joined:
    Nov 5, 2016
    Posts:
    347
    The overall plan about .NET at Unity is to come back to a much more compatible approach with .NET. So for this particular issue, yes, we will have to figure out a proper way to do this, being e.g a property like `GameObject.IsDestroyed` and a Roslyn/API Updater to upgrade user code automatically.
     
  30. xoofx

    xoofx

    Unity Technologies

    Joined:
    Nov 5, 2016
    Posts:
    347
    IL2CPP is targeting a lot more platforms than the NativeAOT feature that is being developed in .NET. That being said, we will keep an eye on how things are evolving in that domain in the .NET runtime to leverage as much as possible on such opportunities if it makes sense for Unity.

    But we have also a longer term idea in the future to "combine" Burst+IL2CPP effort and to push for the best .NET AOT experience for Unity apps. This AOT solution could be considered as a Tiered level 4 compilation compatible with CoreCLR. But before going there, we will have quite some work ahead, as highlighted by @JoshPeterson in the original post above.
     
  31. optimise

    optimise

    Joined:
    Jan 22, 2014
    Posts:
    1,000
    Can you expand more on this? The only feature I would like to see for this future .NET Core ecosystem is the plan to reach ultimate goal of Unity getting to insanely fast 500 ms compile and enter play mode iteration time. Currently what I see despite the long script compilation time, the domain reload also cost quite long time. Will Assembly Load Context can totally eliminate domain reload or only domain reload the changed assembly if my project supported fast enter play mode? Just change 1 line of code should take less than 5 seconds.
     
  32. joncham

    joncham

    Unity Technologies

    Joined:
    Dec 1, 2011
    Posts:
    270
    First, the issue with Assembly Load Context is that is doesn't provide all the functionality of appdomain reloads. In general Assembly Load Context is cooperative, and any remaining references (static fields, GC Handles, running threads, etc) will prevent the code from being unloaded. We are investigating how to augment the current behavior.

    Second, we have the same goal of quick iteration with small changes. I would say this is not (easily) possible with the .NET ecosystem today, however it is something we are pursuing and discussing with others involved in the .NET ecosystem.
     
  33. AngryAnt

    AngryAnt

    Keyboard Operator Moderator

    Joined:
    Oct 25, 2005
    Posts:
    3,045
    Pretty sure the original scenario described is something like:
    1. cs Project A builds an assembly with shared resources / protocol definitions etc.
    2. cs Project B builds some runtime target like a server standalone - it references project A directly - not via assembly.
    3. Unity Project C needs to interact with B via A (network protocol / file formats / IPC / whatever).
    AFAIK step 3 can only be resolved by having Project A produce an assembly which is dumped into Unity Project C - rather than optimally have it reference Project A directly like Project B does. Unless there is an asmdef/ref use case here which I am unaware of?
     
    Energy0124 and bdovaz like this.
  34. xoofx

    xoofx

    Unity Technologies

    Joined:
    Nov 5, 2016
    Posts:
    347
    Completely agree, 5s is unacceptable and we definitely want to solve this problem.

    (Edit: In addition to what @joncham explained above, was writing this response in the meantime)

    I can give some highlights about the challenges behind this.
    While ALC is a candidate for a part of the solution, we are not yet settled with the best solution. We want to work also with Microsoft to see how we can develop an intermediate solution between AppDomains (that are overly complicated and a reason why they have been abandoned) and a fast shutdown/reload cycle when you need to reboot a .NET runtime. We are not the only company/project looking for such a solution, so there is a chance that we can find allies on this topic.

    But the problem with iteration time goes much beyond just the problem of domain reload, CoreCLR won't help to solve this alone. As you implied we have many parts involved in the full refresh cycle (assets pre-import, compilation, domain-reload, initialineonLoads, post-import) and we agreed that we haven't been doing a great job at tracking the performance/regression of this entire part. But this is a high priority for Unity and is going to be a high priority for many teams, so expect improvements coming in the future.
     
  35. xoofx

    xoofx

    Unity Technologies

    Joined:
    Nov 5, 2016
    Posts:
    347
    Ok, If @Issun can open a separate thread and ping me from there, we will try to see exactly which scenario is not working and see if we have any workaround in the meantime.
     
    bdovaz likes this.
  36. TheOtherMonarch

    TheOtherMonarch

    Joined:
    Jul 28, 2012
    Posts:
    280
    Mono is a dead end. Time to break and move to CoreCLR.
     
    Knil, Ramobo and bdovaz like this.
  37. DrummerB

    DrummerB

    Joined:
    Dec 19, 2013
    Posts:
    127
    Looking forward to covariant return types! Might make some templating a bit more elegant.

    I think I would prefer the more concise and elegant code that the new null operators allow over the additional debug info when a NRE is thrown. Usually the LOC is enough information to find the source of the issue.
     
  38. Digika

    Digika

    Joined:
    Jan 7, 2018
    Posts:
    199
  39. xoofx

    xoofx

    Unity Technologies

    Joined:
    Nov 5, 2016
    Posts:
    347
    Sorry, I was using the term "today" to emphasis that this will hopefully change in the future. Unity has been and is still relying on the Boehm GC, which is a conservative (stack-root) GC. The link above doesn't go into some details like how managed objects on the stack are collected by the GC, but basically: a conservative GC will scan the entire stack of all managed threads to "pin" memory referenced by it. Because of this blind scan, it can bring false pin, because it can interpret an integer value, as a pointer to a region of the heap memory, while it was really an int in the first place. By doing so, a conservative GC can start to block some objects from being collected (or worse for a moving-generational GC, to relocate objects). Otoh, a precise GC is able to scan precisely stack-roots and report only pointers that actually point to heap memory. In order for a precise GC to work, the (JIT) codegen needs to be GC aware, which is the case for CoreCLR.
     
    phobos2077, sebas77, JoNax97 and 3 others like this.
  40. JoshPeterson

    JoshPeterson

    Unity Technologies

    Joined:
    Jul 21, 2014
    Posts:
    5,561
    I agree, documentation is an area where we need to improve. We currently have this page: https://docs.unity3d.com/Manual/ScriptingRestrictions.html but it could be expanded and updated.
     
  41. Huszky

    Huszky

    Joined:
    Mar 25, 2018
    Posts:
    51
    Can you elaborate on this one? Will unity support multiple tfm configurations similar to Xamarin/Maui? Because that would be neat.
     
  42. bdovaz

    bdovaz

    Joined:
    Dec 10, 2011
    Posts:
    894
    My 2 most painful points today that would be easier to alleviate by the fact of not having to do with .NET5/6/Mono/CoreCLR/etc have to do with project generation.

    1. Inability to use Nuget packages

    The fact of not being able to do it leads to having to bring the whole chain of dependencies of a nuget package manually (dll one by one) with the loss of time that it supposes initially and in the consequent updates.

    It has led for years to "fight" conflicts of different versions of asset store asset assemblies or even official Unity packages. Examples:

    https://forum.unity.com/threads/ple...ystem-runtime-compilerservices-unsafe.732056/

    https://forum.unity.com/threads/con...onsoft-and-packagemanagers-newtonsoft.843898/

    Another problem that I've been fighting for quite a long time and I managed to solve partly thanks to @HaraldNielsen: https://forum.unity.com/threads/edi...ken-assembly-could-not-load-signature.754508/

    Luckily since the emergence of UPM projects like @xoofx (https://github.com/xoofx/UnityNuGet) have emerged, to which I have contributed in several PRs and it helps quite a lot at least to be able to add nuget dependencies "in the world" of UPM.

    I do not understand how in the era in which Microsoft embraces open source and cross platform tools, Unity does not take advantage of them and alwaays tries to reinvent the wheel with the expense of time ("NPM -> UPM fork" instead of using Nuget, Mono fork very far from the official one with the complexity of updating it, ...) and resources when it could be focused on functionalities more typical of an engine like Unity.

    Since Unity left aside the other two languages (UnityScript and Boo) I don't understand why it doesn't use official .NET tools.

    2. Replace asmdef files with sdk style csproj files

    I see that this is something that is going to be worked on and I am very happy because it is something that solves the first problem and solves many others.

    Since the sdk style format was created it makes it very easy to edit the csproj files by hand so it would not be necessary initially to have a special inspector in the editor unless you need properties that you want to migrate from Unity's own asmdef.

    A problem that we encounter is the same as @Issun and many others and is the fact of being able to reference external projects to Unity (pure C#) without binaries (source code directly) as is the very common case of our communication protocols between a backend and Unity: Rest APIs with NSwag, shared data models, utility libraries, etc ....

    It would also solve in part the continuous reloads with the Visual Studio blocking dialog that makes you open a new instance of VS. With SDK style reloads in many cases happen in the background without blocking interaction.
     
    Last edited: Apr 19, 2021
  43. Huszky

    Huszky

    Joined:
    Mar 25, 2018
    Posts:
    51
    Welp, a 100 times, this. I also tried to do this with various degrees of success: https://github.com/KuraiAndras/CsprojToAsmdef

    But the main pain point remains: All the automation you can do to reference packages and projects outside of unity can only get you so far. I have managed to use most NuGet packages, and csprojs outside of unity, but there are things that are still near-impossible to do. (Using the correct platform specific DLLs from SQLite? Localized DLLs used by FSharp.Core?)

    Also, if you make changes to the project system what will happen to UPM? Will this mean that Unity will get some custom TFM, or that you will make it available on NuGet.org or through some other nuget feed?
     
    Qbit86 and kloot like this.
  44. PerfidiousLeaf

    PerfidiousLeaf

    Joined:
    Aug 30, 2019
    Posts:
    19
    Care to elaborate? I am a CoreCLR advocate but even I know that there are feature differences between the two that hold the transition back and those feature differences are important (like domain reloading).

    Also, just wanted to say thanks here as well for making this blog thread. It was a bit overdue but much better late than never. Things like this give us the confidence to stay with Unity.
     
    Last edited: Apr 13, 2021
    Qbit86 and GliderGuy like this.
  45. TheOtherMonarch

    TheOtherMonarch

    Joined:
    Jul 28, 2012
    Posts:
    280
    Meh, trivialities aside the truth is Unity is too busy maintaining its Mono branch to be serious about moving to CoreCLR.
     
  46. neuecc

    neuecc

    Joined:
    Apr 20, 2014
    Posts:
    112
    Others have already answered this question, but here's what you need.

    Code (CSharp):
    1. // Fast Span
    2. public readonly ref struct Span<T>
    3. {
    4.         ByReference<T> _pointer;
    5.         int _length;
    6. }
    7.  
    8. // Slow Span
    9. public readonly ref struct Span<T>
    10. {
    11.         Pinnable<T> _pinnable;
    12.         IntPtr _byteOffset;
    13.         int _length;
    14. }
    Detailed blog post: https://adamsitnik.com/Span/
    Quote:
    IL and C# do not support ref T fields. .NET Core 2.0+ implements it by representing it via ByReference type, which is just a JIT intrinsic.

    It's great to know that the latest mono already supports it.
    I understand that IL2CPP works on a different mechanism.
    In order to reduce confusion, and also for the sake of performance,
    it would be nice if IL2CPP also supports Fast Span at the same time.
    (Also, interoperability with NativeArray, etc.: ......)

    Recently, I've found a big performance issue only on Unity in my library that work on both .NET Core and Unity.
    That performance issue is caused from the use of (Slow)Span.
    There was a bigger performance difference than shown in the bloThere was a bigger performance difference than shown in the blog (maybe because the runtime on the .NET Core side is .NET 5).
    g (maybe because the runtime on the .NET Core side is .NET 5).
    I don't want to think about SlowSpan if I'm going to be able to use it as standard in Unity.
     
  47. sebas77

    sebas77

    Joined:
    Nov 4, 2011
    Posts:
    1,388
    Care to explain more? Maybe this was the missing bit I was thinking of. In other words I could just ask: what is actually missing to support fast span?
     
  48. Digika

    Digika

    Joined:
    Jan 7, 2018
    Posts:
    199
    Ah, yes, I see what you mean, I've read your blog a while back on this proposal of local to stack reference types.
    Honestly, it is about time we can have some leeway in the size of the stack within reasonable limits that dont affect hurt general performance much. Perhaps may be per thread with some small additions.
     
  49. PerfidiousLeaf

    PerfidiousLeaf

    Joined:
    Aug 30, 2019
    Posts:
    19
    I'm sorry but I have to ask if you're trolling or you were just too lazy to read the posts above.

    First off, they've already said here and in the other thread that they need to support these features (.NET 6, C# 9+, etc.) to be able to move over to CoreCLR/RyuJIT in the first place. A couple of posts up, they even bring up an issue with AppDomainReload versus AssemblyLoadContext in that the latter is lacking functionality. In other words, they can't port the editor over with it as-is. There's more, just go actually read it.

    Also, their process makes sense. If they go in the order of .NET Standard 2.1 -> C#9 -> .NET 6 -> CoreCLR. They will be able to update IL2CPP to be on par with CoreCLR (mostly) at the time they switch over. Then they'll have a much better base to keep things in parity with Microsoft.

    And before you claim I'm a blind fanboy or something along the lines, I was one of the people grilling them in the other thread that lead to this dev blog even being made.

    Of course, we'll see in the next 1-3 years how well they keep up on this.
     
    Qbit86, vis2k, stuksgens and 2 others like this.
  50. TheOtherMonarch

    TheOtherMonarch

    Joined:
    Jul 28, 2012
    Posts:
    280
    1: Right they are in no rush to move to CoreCLR. It is not their main priority. They have too many platforms and they want to update mono.

    2: You make it sound like CoreCLR is somehow is lacking too much functionality right now but that is far from accurate. Some things will need work but CoreCLR can deliver.

    3: .NET Standard 2.1 -> C#9 -> .NET 6 -> CoreCLR. Does not make sense for most developers

    This is a really silly discussion because Unity has its own plans which are based around their mono branch and all their platforms. Not necessarily what most developers want.
     
    Last edited: Apr 14, 2021
unityunity