Which is TOTALLY against Apple (and most other platforms) policies. If they catch you doing it (i.e. dynamic code loading/execution), your account will be banned forver (yes the whole account, not only the app/game)
7 Likes
i surely do hope that whatever version 7 builds will be publicly available it will not be next year
and version 6 and its .1 (and subsequent releases) will be supported and iterated over for years to come
the extreme pacing of rapid yearly releases is finally over and we as consuming public can finally enjoy (hopefully) more stable ecosystem
on a slightly more technical note: while mono compared to latest .NET(Core) is ancient at this point, the .netstandard brought it at least half way to be usable with existing .NET libraries without any additional effort since more mature projects do have older .NET variants available anyway
those which don’t require (possibly non trivial) work if they’re needed that desperately - but i can’t stress enough that things were much worse up to that point and yet - somehow - stuff was made and shipped
/ and people complain now, when things are moving forward after a long time -
but it is to be very much expected that a single word like ‘msbuild’ implies years of effort .)
what, ever. o/
I have watch the whole roadmap video and rewatch it again around timeline and it seem there is totally no mentioning about when the next generation will be released
The closest thing related to this point might be next beta here and some mention about overlapping release between generation
But this also hinting that update release might not be the new generation, is it meant the major release we have hope for the unite next year ? I don’t know
Thank you so much for sharing the roadmap video! Really excited about a bunch of these.
Here is my understanding of the .NET modernization based on the roadmap video shared above:
- CoreCLR is NOT coming in Unity 6 or any of the minor 6.x releases.
- CoreCLR will come in one of the future major releases, one can hope for Unity 7, but this was not mentioned.
- They are looking for slower release cycles, next major version will come no earlier than in 2 years. Quote from the presentation (timestamp 3:00):
Time between generations will be longer, generally a minimum of 2 years.
Unity 6 came to alpha quite a while ago, so one can hope that Unity 7 could be available in alpha later next year, but if you don’t care about alpha release, there will be at least 2 years wait for this feature.
One interesting thing from the video which is not related to .NET but could be quite a big deal is that it sounded like the built-in renderer will be no longer available in the next gen release. They recommended to migrate to URL/HDRP now (in Unity 6), but they also mentioned that URP/HDRP will be deprecated in favor of unified renderer…
5 Likes
URP/HDRP are not being deprecated, the process of choosing URP/HDRP will be. Because you’ll simply author your game the way you would in either pipeline, with the tooling being unified, and the end result being defined by graphics and platform settings.
6 Likes
Has there been any discussion around adopting .NET’s built in NativeAOT instead of IL2CPP and being able to refocus those resources elsewhere in the editor?
NativeAOT is still a very new feature, but between .NET 7, 8 and then upcoming changes in 9 it’s development has been pretty rapid and I won’t be surprised to see it become a preferred method of a lot of applications in future versions
Is there a specific set of features that IL2CPP provides that C++ just wouldn’t be able to?
Yes. This has repeatedly been brought up.
3 Likes
Graphics sell games, but Code makes 'em - I have a foot in both camps, but the changes here are easily the most impactful and hype-inducing for me. I was expecting some .NET-update announcements, and Burst was fated for core-functionality, but the MsBuild integration (and NuGet!) particularly caught my eye 
This part worries me a bit though. I haven’t followed this aspect closely, but how much re-architecting will this entail on the user’s end? I’ve got a great setup now with local sub-projects as library packages, and judicious use of assembly definitions, such that compile times are a non-issue. Version-defines are handy too for segregating some dependencies.
I’m assuming that aspects of that won’t go away, but it’s unclear if that workflow would still be supported.
Feels like the Unity dev ecosystem already has a hard bifurcation between teams who have the skills/exp to take advantage of the Engine’s more advanced (or even intermediate) features, and those who don’t. Between this and the node/graph graphics changes (still mulling over those), I worry that gap is just getting bigger, which is bound to lead to even more frustration. Folks don’t always realize how deep the water is relative to their swimming ability…
Looking forward to reading through the other top-level Roadmap threads, lot of good stuff here. Hopefully we can keep the drama on the gameplay-screen 
1 Like
Let’s separate out two issues here - compiling vs (re)loading.
On the compiling front: the MSBuild integration means that we’re aiming to replace asmdef files with SDK-style csproj files. You’ll still be able to have your code split into multiple assemblies, and MSBuild should still only spend time recompiling assemblies where you actually changed something, so your compile times should still stay in a great place. Naturally, a project which uses many asmdef files will have more to convert to csproj than a project which uses few, but that’s a one-time cost when first upgrading your project, and we’re considering what we can do to save you from having to do it all manually.
Then, after compilation has finished, the old versions of your assemblies need to be unloaded, and the new versions need to be loaded in their place. In today’s Unity, that’s accomplished through domain reload, which means unloading and reloading everything in the managed domain - including assemblies you didn’t modify, and including Unity’s assemblies. In the new ALC design, we’re able to do that at a much more granular level. In the worst case scenario of a project which has all code in a single assembly, we’re at least able to reload that assembly without reloading Unity’s assemblies; but if you’ve broken your project down into multiple assemblies, then you’ll be able to more quickly take advantage of Code Reload by putting your infrequently-changing assemblies (like your library packages) into a different ALC than your frequently-changing assemblies (like your gameplay code).
So for projects where you’ve already invested in making sure there’s a good architecture at the assembly level, it shouldn’t mean rearchitecting anything; in fact it should mean you’re well positioned to be able to take immediate advantage of these new features and get even more benefit from them compared to projects which haven’t been as organised.
18 Likes
Is there active plans and/or rough etas for mobile platforms to receive the garbage collector upgrade?
There are no plans/ETAs for this currently.
2 Likes
Are there any plans for an asmref alternative?
Thank you - that is more than reassuring! I’ve experimented in the past with making MSBuild-compatible modifications to my csproj files, but of course the Unity process rewrites all changes.
At bare minimum, I use some MSBuild properties folder aliases and Unity folder symlinks to keep my version control neat.
If we can get to a place where we get the benefits of Unity and all the MSBuild configuration goodies - whoo boy, I’ll be a nerdy happy camper 
The issue with asmref had been discussed on the old thread. tannergooding has pointed us to UnsafeAccessorAttribute and the upcoming UnsafeAccessorTypeAttribute. Could these 2 attributes be applicable as an alternative to asmref?
1 Like
That discussion was about somehing else. I was using asmref to get a reference to an assembly in the 2d.common package that has access to internal Unity code. Using this asmref allowed me to access internal Unity code in a hacky but performant way.
With UnsafeAccessor’s I could access that internal Unity code in a performant way without the need of asmref’s (which only makes my life better 
)
However, to shed some light on the situation, it was not about an alternative to asmrefs specifically. Though my best guess is that they will be “replaced” (or rather obseleted) by csproj project references.
1 Like
Is that confirmed? Would really suck if basically no game that’s been in development for some time now could switch to CoreCLR just because the first version that includes it would also drop support for built-in render pipeline which is what older projects would be using …
Maybe something a Unity dev could clear up?
Wdym?
Unity is doing this deliberately because they have the statistics to say that they should…
In their presentation they talked about how ~90% of all games made with Unity since SRP have been made with SRP.
So most developers wouldn’t be affected.
Are you talking out of personal experience?
and if a game used birp right now, than that problem is definitely on the developer. go with the times.
1 Like
URP is wayyy more performant anyways, so a developer deciding to not use URP and instead use the BiRP is on purpose degrading performance for their users.