Search Unity

  1. How can our website serve you better? Give us your feedback. Take our survey and let us know.
    Dismiss Notice

.Net 5 support

Discussion in 'Experimental Scripting Previews' started by Lymdun, Mar 3, 2020.

  1. JoshPeterson

    JoshPeterson

    Unity Technologies

    Joined:
    Jul 21, 2014
    Posts:
    5,340
    I was not aware of this - but it looks like you are correct. This is certainly an avenue we should explore more.
     
    ModLunar, Knil, Thaina and 2 others like this.
  2. Thaina

    Thaina

    Joined:
    Jul 13, 2012
    Posts:
    576
    For all these I think it raise more reason to fork unity for switching ecosystem and allow only new project to fresh start in the new ecosystem while don't need to care for existing project

    Also for the argument about pre built assembly. I think it's opposite. It just extracting unitypackage in project's directory directly make everything completely a mess. And code conflict when there are many package try to use the same library

    The actual problem is because UPM are too lacking. If UPM already just support git dependency or can registering their package to unity registry and be more mature, almost all packages can stop using prebuilt dll and release there library as code in git directly

    Release code that need recompiling in package has more benefit to make version specific code too. And so it actually better to have raw code package

    All in all those problem are the reason we should completely fresh start the new ecosystem in parallel. Unity can have Unity 2021 and Unity.net 2021. As I said I am totally fine as long as I can install both in unity hub
     
    Huszky likes this.
  3. PerfidiousLeaf

    PerfidiousLeaf

    Joined:
    Aug 30, 2019
    Posts:
    18
    I would like to see a branch too for one year/generation. The only real issue here is the amount of retooling the editor is going to need is a lot of work and knowing Unity's track record I don't expect anything tangible until 2025+.

    Also, Unity seems hell-bent on not porting over to the RyuJIT (.Core/5+) runtime. Unity can talk all they want to but it doesn't mean anything until it's in the roadmap, as their history shows. I agree that IL2CPP has its place but it's not a replacement for Mono. Unity doesn't really have a language feature-set issue, the existing C# 7-8 lang spec is more than versatile enough to handle what needs to be done when making a game (not saying that new features aren't nice).

    Frankly speaking, the main thing keeping newer developers on Unity is C# because of ease of access and the simplicity from a managed runtime (memory, etc). C++ is the main issue the Unreal Engine is having in regards to getting indie teams and hobbyists to adopt it. And before you say it, there are plenty of issues with Unreal's editor workflow, etc., etc., but Unity has issues as well in the same vein so it's not really an argument. You learn the workflow of the tools you use.

    The problem with the DOTS+IL2CPP replacement argument is while you may gain a slight performance advantage over the RyuJIT runtime, you lose a lot of the feature-set that makes C# attractive over C++'s development process, mainly in rapid development. Also, DOTS+IL2CPP, as a result of this, requires that you still make use of Mono's components/functions because many features are not supported in DOTS.

    Also, something that Unity doesn't seem to consider is that ease-of-modding is really important for consumer-facing projects (ie. Steam games). A big example is Risk of Rain 2, the truth of the matter is that modding has added a massive amount of content to the game at no cost to the original developers. I'm not saying in an exploitative manner, modders want to do it voluntarily. Modding also extends the lifecycle of the game. Indie teams do not have a lot of money to work with so this is actually important a lot of the time. IL2CPP has actually put a giant wall in this regard because of an inability to inspect the MSIL.

    Obviously, I'm not saying that Unity dev teams must cater to this, they can even explicitly stop modding attempts. The issue is that allowing this instead is not really an option for IL2CPP games without a lot of resources on the part of the developers to make it happen, which indie teams do not have a lot of.

    And finally, if Unity switched over to RyuJIT, it would make supporting future changes/features to C# and the now unified .NET ecosystem much easier and faster.

    Again, keep IL2CPP; Apple, Android, Console platforms, etc. all require it but, I would like to see RuyJIT or a similar vein on the Unity Roadmap. Even if it's far out, that's fine but, I don't trust Unity given their track record of reneging on things they say that aren't in the roadmap.
     
  4. Knil

    Knil

    Joined:
    Nov 13, 2013
    Posts:
    65
    As a point of reference, creator of Tabletop Simulator here we have migrated the game over the years all the way back starting with Unity 4.3 in 2013 and we are currently on 2019 LTS (investigating moving to 2020 LTS). We have never migrated renderers (Marmoset Skyshop, but we also use the standard renderer for modding) or UI system (ngui, very early on we did use onGUI). The big system we have migrated away from was the old raknet networking and that has been replaced with a custom networking solution on top of steam p2p (not surprising with the state of Unity's networking solutions, we are also looking into Epic's online service for platform independence). Unless there is a clear benefit to a project you don't really touch it because a shiny new thing came out.

    With that said, if I had to throw my hat in the ring .net 6 support is definitely our most requested improvement to Unity. From the benchmarks it has better performance than IL2CPP, without all the compatibility and build issues (we currently ship mono builds, yuck I know). Modern api and features, with hopefully better tracking of .net releases. Mono needs to be taken out back and put down for the betterment of us all lol.
     
    tonialatalo, Davon92, Huszky and 3 others like this.
  5. optimise

    optimise

    Joined:
    Jan 22, 2014
    Posts:
    911
    Looks like Assembly Load Context can eliminate super long domain reload time after just change one line of code if the project supports fast enter play mode. Am I right?
     
  6. Digika

    Digika

    Joined:
    Jan 7, 2018
    Posts:
    184
    Can someone write a simple blogpost about the aforementioned issues? Can be even a personal blog, does not matter much.
     
    Ramobo likes this.
  7. PerfidiousLeaf

    PerfidiousLeaf

    Joined:
    Aug 30, 2019
    Posts:
    18
    I just wanted to say, thank you for powering all of my social drinking activities during COVID.

    Yes please! Like I've said before, Unity has made multiple broken promises. The only way the have some reassurance is an official posted statement from Unity Technologies (news/post/roadmap).

    Also @JoshPeterson , I am curious as to what major issues or hurdles there are with porting over to RyuJIT (Core CLR JIT) from Mono? I actually genuinely want to know all of the pain and random non-sense that's involved in porting it over, things that we as product users would probably never be aware of otherwise.
     
  8. CaseyHofland

    CaseyHofland

    Joined:
    Mar 18, 2016
    Posts:
    149
    Is this what you're looking for?
    https://forum.unity.com/threads/net-5-support.839890/page-5#post-7021204

    I actually have no idea, I know what JIT stands for but the rest is all gibberish to me :')
     
    ModLunar likes this.
  9. Thaina

    Thaina

    Joined:
    Jul 13, 2012
    Posts:
    576
    As we argue, I am more convinced that unity team put their effort in the wrong way

    Smooth migration is not really what we need. There never been smooth migration without developer need to modified something along the development chain anyway. Instead the faster the release leds to earlier migration. No smooth migration can replace the time we lost for each day passed
     
    chrisk and bdovaz like this.
  10. CaseyHofland

    CaseyHofland

    Joined:
    Mar 18, 2016
    Posts:
    149
    That would be great for small creators, yes, but catastrophic for larger studios that have projects running over several years. Imagine if Unity's philosophy was such that every new major version would have you change your code: no deprecation or legacy support whatsoever. Unity wouldn't be an attractive solution for studios like e.g. Blizzard to create Hearthstone, which had an initially expected lifespan of 10 years.

    Since Unity generates their income from these larger studios, we are all better off by their smooth integration policy. Because of it, larger studios keep coming, and small creators can enjoy the benefits of free Unity to learn, grow, and to create a career out of what was a hundred years ago a preposterous job proposition.

    Regarding time loss, those studios are careful to monitor performance from the get-go anyway, so to them it is a welcome bonus, not a safety net.
     
  11. Knil

    Knil

    Joined:
    Nov 13, 2013
    Posts:
    65
    You mean the smooth migration to DOTS lol? Focusing on RyuJIT would have been a much faster and easier win for the entire community compared to that.
     
    SMHall, Qbit86, bdovaz and 1 other person like this.
  12. Digika

    Digika

    Joined:
    Jan 7, 2018
    Posts:
    184
    I'm gonna rephrase previous statement to get the point across: DOTS was created as a means to have something competitive against UE, which currently leads on every single field where Unity DOTS would be applicable (medium and big gamedev studios). On the other hand, very prevailing majority of Unity indie devs dont need DOTS and probably will never need (unless they grew into a bigger studio naturally and would want to use Unity for some reason for bigger projects), so for them, moving AND syncing scripting backend to .NET ecosystem would be way more beneficial and useful.
    Unity tries to sit on both chairs here but it does not seems to be working well.
     
    SMHall, Huszky, Ramobo and 2 others like this.
  13. chrisk

    chrisk

    Joined:
    Jan 23, 2009
    Posts:
    699
    If I were Unity, I would start a clean branch. There is no such thing as a "smooth transition" on such a scale as this one. It will take decades if not more at this rate. Remember what happened to the DOTS fiasco, and it's still ongoing. It would've been much "smoother" if DOTS had its own branch to avoid all kinds of regression bugs. And let people who really need DOTS opt-in. 90% of projects out there don't need DOTS and Monobehaviour is the better choice for faster and easier development. Please don't make the same mistake again.

    My recommended plan of attack is to branch off .NET and let people play with it ASAP. I believe many will choose to migrate voluntarily and it's all up to them. I believe the majority of the projects will just require recompilation or simple changes.

    And at the same time, guide exiting users to prepare for the changes, i.e., making their project compatible for fast-enter-to-play mode and etc.

    If you really want to help the migration easier, you can add optional Mono compatibility packages after .NET version releases. But then that depends on how much effort it requires vs benefits and you can worry about it after .NET releases. This will be the easiest path for Unity and let's see how long it takes to get there. ^^

    Cheers!
     
    Ramobo and Thaina like this.
  14. SugoiDev

    SugoiDev

    Joined:
    Mar 27, 2013
    Posts:
    351
    Forking a complex codebase like Unity's is a monumental effort, even more so keeping both forks up to date, across the many versions they would have to maintain for a long time.
    We might see some experimental builds to gather feedback at some point, but I wouldn't expect an actual fork to ever happen at this scale.

    That's not to say I'm not interested in newer runtimes and wouldn't jump straight out if I could. I definitely would.
    I've been using alternative compilers for Unity to at least have newer C# features since Unity 4 or 5, and just finally stopped when they switched to their Bee system (which broke my entry point to replace the compiler). But, now we can have C# 9 and I'm satisfied with that.

    For years now, the thing that hurts me the most is editor iteration performance. I've worked on some javascript games and having next to 0 iteration delay is absolutely incredible. Time just flows and I rarely procrastinate because of the delays. 5-10 seconds might not be much, but it adds up when you're doing heavy iterative coding for 10+ hours straight.

    Sadly, I don't think even a full CORE editor would eliminate --or even significantly reduce-- iteration delays for everyone, as some (most?) of those delays would be coming from user code (but would be more than happy to be proven wrong!).
    But, if we have the capacity to reload only relevant assemblies, we at least would not have to reload most packages and at maybe some of Unity's internal assemblies (where about 80% of my iteration times comes from).
    For example, IDE integration assemblies would almost never need to actually be reloaded.



    All in all, I'm happy to see work being done on Editor iteration performance. Also very happy to see some communication too. For real, keep talking to us, please.
    Hoping to see great progress in the future!
     
    ModLunar and Andresmonte like this.
  15. JoshPeterson

    JoshPeterson

    Unity Technologies

    Joined:
    Jul 21, 2014
    Posts:
    5,340
    Thanks for the great discussion everyone! I appreciate the feedback.

    I won't be able to address everything here, but I'll try to do my best.

    Regarding DOTS and UPM, these are both outside of my team and experience, so I can't speak too much to their past or future. Regarding future .NET work, I don't expect any changes to them to happen or to impact the move to .NET 6 though.

    Regarding the Unity Roadmap, we're trying to do a better job of getting things on there as we have confidence when they will ship. That should include future .NET work. I'm still looking to start a forum thread which is kind of a "developer log" where we will try to post non-binding updates more frequently. There was a question about the internal hurdles to moving to CoreCLR/RyuJIT earlier in the thread. This is the kind of thing that I would to discuss on that thread. Hopefully we will be able to start it soon.

    In general, I like to think of the .NET ecosystem on three vectors, hopefully this will help others understand where we are going. The three vectors are:
    1. .NET base class libraries
    2. .NET runtime
    3. .NET reference profiles
    The .NET base class libraries (BCL) provide the implementation of common types, like List, string, Dictionary, etc. Historically there have been three implementations:
    There are five major .NET runtimes that I know of, each consists of a code generated engine and runtime code (GC, thread, file, socket access, etc.).
    • CLR - .NET Framework's JIT runtime, I'm not sure what the code generation engine is called
    • CoreCLR - .NET Core's JIT runtime, using RyuJIT for code generation
    • Mono - JIT and AOT runtime based on .NET Framework (and now .NET Core), using Mono's JIT and AOT for code generation, as well as an IL interpreter used for Wasm
    • IL2CPP - Unity's AOT runtime, based on Mono, using a transpiler from IL to C++ and then native C++ compilers for code generation
    • CoreRT - Microsoft's experimental AOT runtime, based on CoreCLR, I'm not sure how code generation works here.
    .NET reference profiles are an API surface without implementation used to compile C# code to IL code. The most important one here is .NET Standard, which is a "bridge" from .NET Framework BCL to .NET Core BCL.
    • .NET Standard 2.0 is supported by .NET Framework, .NET Core, Mono, and IL2CPP
    • .NET Standard 2.1 is supported by .NET Core, Mono, and soon Unity's Mono and IL2CPP
    The idea here is that any assembly compiled against .NET Standard 2.0 will work with .NET Framework or .NET Core BCLs.

    Ok, so with that in mind, Unity's plan is to first exposed .NET Standard 2.1 support, then .NET 6 support later, likely using Mono as a JIT solution and IL2CPP as an AOT solution. Then we plan to expose CoreCLR as a JIT solution, and possibly replace Mono.

    I'll have more to say about this in detail later as plans become clearer, but hopefully this gives some color.
     
  16. Ramobo

    Ramobo

    Joined:
    Dec 26, 2018
    Posts:
    212
    They've actually been using RyuJIT for quite a while, per this 2013 post.
     
  17. JoshPeterson

    JoshPeterson

    Unity Technologies

    Joined:
    Jul 21, 2014
    Posts:
    5,340
    Thanks for clarifying that!
     
    Ramobo likes this.
  18. Thaina

    Thaina

    Joined:
    Jul 13, 2012
    Posts:
    576
  19. JoshPeterson

    JoshPeterson

    Unity Technologies

    Joined:
    Jul 21, 2014
    Posts:
    5,340
    Ramobo, Jes28, bdovaz and 8 others like this.
  20. Digika

    Digika

    Joined:
    Jan 7, 2018
    Posts:
    184
    I'm recalling now a thread somewhere here where one of the devs posted benchmarks of his monogame ported to CoreRt and getting 10x speedup on Switch. Stuff's insane when it works.
     
    Thaina likes this.
  21. PerfidiousLeaf

    PerfidiousLeaf

    Joined:
    Aug 30, 2019
    Posts:
    18
    Okay, that's understandable, and thanks very much for the rundown. The last part is the big one we kind of wanted to hear, even if it's not set in stone. It lets us have a mental map of "Oh okay, so when they finish .NET Standard 2.1, then we'll get more details on how .NET 6 is going to work out."

    Awesome.
     
  22. TieSKey

    TieSKey

    Joined:
    Apr 14, 2011
    Posts:
    56
    As a response for those asking for a fork. Bear in mind that fork or not, the app domain reload issue has to solved before 95% of us can even start a new project on a new fork. Without the app domain reload thingy in order, only games compatible with the fast enter play mode would work, and I think only very very very few projects are actually compatible (I think it's only pure DOTs based ones).
    For example, in my project, the gRPC library I use is completely incompatible (has static state) and I can't just fix/replace it.
     
    Ramobo likes this.
  23. Digika

    Digika

    Joined:
    Jan 7, 2018
    Posts:
    184
    Which one it is?
     
  24. TieSKey

    TieSKey

    Joined:
    Apr 14, 2011
    Posts:
    56
  25. Mr_FJ

    Mr_FJ

    Joined:
    Sep 4, 2013
    Posts:
    4
    Question: Given that as Microsofts .net teams has recently put it; "over 50% of all games published, use Unity"; is Microsoft not interested in putting resources towards lifting Unity up to .net 6? To brag about game performance, drag over big studios, or even just get more marketing buzz statistics? "Unity is now .net 6 compatible! Look guys! Jump in, the water is great!"
     
    Vincenzo, GliderGuy and bdovaz like this.
  26. CaseyHofland

    CaseyHofland

    Joined:
    Mar 18, 2016
    Posts:
    149
    That would show a glimmer of competence in Microsofts marketing team and that's just not on-brand.
     
    Last edited: May 29, 2021
    dCalle likes this.
  27. forteller

    forteller

    Joined:
    Jun 15, 2019
    Posts:
    46
    This is simply not true. I can account first hand, that there are games currently in production at AAA studios which use DOTs almost entirely.
     
    CaseyHofland likes this.
  28. Kamyker

    Kamyker

    Joined:
    May 14, 2013
    Posts:
    627
    DOTS is Unity's Data Oriented Tech Stack not DOD
     
  29. forteller

    forteller

    Joined:
    Jun 15, 2019
    Posts:
    46
    When I say DOTS I mean specifically the Unity packages in DOTS. I'm sure varying degrees of DOD happens in gameobject-Unity-land all the time (although these systems would have to be really isolated from the Unity Engine as gameobject's and components aren't
    DOD-friendly).

    I can confirm that specifically the JOBS system (w/BURST) and the Entities(/ECS) system are used. I can't confirm about any of the other packages, as I haven't personally worked on these teams.
     
    Last edited: Jun 27, 2021
  30. Lurking-Ninja

    Lurking-Ninja

    Joined:
    Jan 20, 2015
    Posts:
    7,064
    You mean aren't, I presume.
     
    forteller likes this.
  31. forteller

    forteller

    Joined:
    Jun 15, 2019
    Posts:
    46
    thanks, edited.
     
  32. KebbieG

    KebbieG

    Joined:
    May 24, 2017
    Posts:
    1
    I am trying to start the process of creating a video game. Does unity support .net5 yet and if so what version? I am also having a hard time getting my Photon Server up with the .net5 libraries. This has been a nightmare so far.
     
  33. VolodymyrBS

    VolodymyrBS

    Joined:
    May 15, 2019
    Posts:
    88
    Unity does not support .NET 5.
    Current supported API versions are .NET Standard 2.0 and NET Framework 4.7.1 (if I'm not missing).
    .NET Standard 2.1 should land in Unity 2021.2.

    Photon has packages specially for Unity. They are published in Assets Store (at least was published when I work with it last time). And as I remember there was no problem with setup
     
unityunity