CoreCLR and .NET Modernization - Unite 2024

[TheZombieKiller]

For anyone craving some more modern .NET features in Unity, it seems that Unity 6 (potentially Unity 2023 too, I have not checked there) has undocumented support for UnmanagedCallersOnly in both Mono and IL2CPP. You just need to define the attribute yourself, in the appropriate namespace (i.e., by copying this file into your project). Once you have the attribute available, it works just fine:

public sealed unsafe class UnmanagedCallersOnlyExample : MonoBehaviour
{
    [DllImport("user32", ExactSpelling = true)]
    private static extern int EnumWindows(delegate* unmanaged[Stdcall]<void*, nint, int> lpEnumFunc, nint lParam);

    [DllImport("user32", ExactSpelling = true)]
    private static extern int GetWindowTextW(void* hWnd, char* lpString, int nMaxCount);

    [DllImport("user32", ExactSpelling = true)]
    private static extern int GetWindowTextLengthW(void* hWnd);

    [UnmanagedCallersOnly(CallConvs = new[] { typeof(CallConvStdcall) })]
    private static int EnumWindowsProc(void* hWnd, nint lParam)
    {
        var text = string.Create(GetWindowTextLengthW(hWnd), (nint)hWnd, (span, hWnd) =>
        {
            fixed (char* pText = span)
            {
                GetWindowTextW((void*)hWnd, pText, span.Length + 1);
            }
        });

        Debug.Log(text);
        return 1;
    }

    private void Awake()
    {
        EnumWindows(&EnumWindowsProc, 0);
    }
}

[Mindstyler]

whoooo i didn’t even know about this attribute until now. That’s great to know, even for non-unity projects.

[xoofx]

@JiRo_Dev

When would we get the chance to try and test Unity 7 Alpha or whatever it’s going to be called, basically the build of the engine with CoreCLR? I was told we will hear an announcement about this before this year is out.

Unfortunately, I can’t provide an answer to that just yet. As mentioned earlier, it’s unlikely we’ll have an update to share before the end of the year. We appreciate your patience in the meantime

[optimise]

@xoofx

@JiRo_Dev

When would we get the chance to try and test Unity 7 Alpha or whatever it’s going to be called, basically the build of the engine with CoreCLR? I was told we will hear an announcement about this before this year is out.

Unfortunately, I can’t provide an answer to that just yet. As mentioned earlier, it’s unlikely we’ll have an update to share before the end of the year. We appreciate your patience in the meantime

Does official going to bring .Net 8 or .Net 9 when release since .Net 9 just release recently?

[Eclextic]

Again, very likely.

The reason Unity switched to CoreCLR is to be able to update .NET versions easily.

[xoofx]

@optimise

Does official going to bring .Net 8 or .Net 9 when release since .Net 9 just release recentl

The goal is to stay up-to-date with the latest .NET version. We’ve made significant efforts to standardize our .NET runtime integration. Though, aligning .NET’s STS and LTS release cycles with Unity’s release schedule brings some challenges. There may be cases where the latest .NET runtime version isn’t available in a subsequent minor Unity release (e.g. because it could break things) - but we’ll navigate these situations when we can evaluate them better. Overall, this new approach should greatly improve the experience compared to what we have today.

[DragonCoder]

Since I have a decision to make rather sooner than later:

Will there be any version of Unity with Core CLR that also supports the Built-In Rendering Pipeline?

Or will the BiRP be “finally” removed with this occasion?

[huntermlg123465]

I think that they will remove BiRP with releasing CoreCLR.

[Eclextic]

is BiRP deprecated in Unity 6? Then yes.
Is it not? Then no.

[huntermlg123465]

CoreCLR will be release in Unity 7.

[goldbug]

@huntermig123456 I could be wrong, and if so, I would love to be corrected.
But I don’t think they have stated that anywhere.
We have just been assuming that to be the case.

[CaseyHofland]

There is absolutely no reason to believe that. Hell, right now they’re going to try to make it easier for you to use URP and HDRP in the same project. Throwing away their only feature-stable pipeline would be a move almost as questionable as charging a runtime-fee.

Edit: nevermind, apparently I completely missed this. Which is odd, considering I check the roadmaps weekly…

[vertxxyz]

@CaseyHofland

There is absolutely no reason to believe that.

@Matjio

First, we will remove the Built-in render pipeline to simplify our offering.

[…]

This is why the Built-in render pipeline will be maintained in the Unity 6 generation for a long time, giving you multiple years to plan your transition. If you are starting a new project, we highly recommend you using URP or HDRP.

The Unity 6 generation is the last for BiRP. This is not unexpected and doesn’t compare to the runtime fee. The next generation of Unity will be a chance to get rid of the old systems, and if you’re not comfortable with any of that then Unity 6 has been designed to be supported long into the future.

This isn’t particularly on-topic for this thread, so if you do have replies to this please use the Unified Rendering thread.

[CaseyHofland]

@vertxxyz

The Unity 6 generation is the last for BiRP. This is not unexpected and doesn’t compare to the runtime fee. The next generation of Unity will be a chance to get rid of the old systems, and if you’re not comfortable with any of that then Unity 6 has been designed to be supported long into the future.

Oef, well I have egg on my face.

Then I just pray they’ll also improve on URP build times even further.

[CaseyHofland]

Ugh… I know I responded cynically but I have to confess, the more I think about it, the more I am glad that we are finally getting a unified solution again. The whole render-split has been such a mess for asset store- and game developers alike. The conversion is gonna hurt and that annoys me, but I can recognize that the change is for the better and even though nobody asked I wanted to express that I was wrong and say stupid shit sometimes.

[WinterOfBit]

Unity and .NET, what’s next?

We are expecting.

[WuaUP]

Will Unity support modern .NET Native Memory without issues on major platforms? Modern C# Native Memory offers incredible performance; when used with structs, pointers, and parallel loops, it performs very close to C++. It’s not hard to work with and provides an alternative to ECS and other performance-oriented systems. Personally, I love it and find it easy to use. In theory, Unity should support it when modern .NET becomes available, but I’m asking because I’m concerned it might not, as I already have thousands of lines of code using it as a separately compiled DLL.

[Player7]

I thought that was a new blog entry… so when is a guide on best practices and future proofing our projects for this CoreCLR stuff… things that we can do now so we don’t have a major headache later updating things in Unity 7 whenever that comes out…

[grownontree]

Unity already has an implemetation of native memory APIs which is being used intensively in DOTS. We can also use it in OOP without problem.

[WuaUP]

It is evident that in a .NET environment, it can be used without issues, but the potential problem I’m asking about is when it is compiled in IL2CPP for consoles. Specifically, I’m referring to (double*)NativeMemory.AllocZeroed compiled in IL2CPP. My question is about compatibility. Using structures in NativeMemory and parallel loops outperforms DOTS in terms of performance. I’ve tested it thoroughly. There is nothing faster than directly managing memory. Once you get used to it, it’s a valid, straightforward approach and a way to develop.