.Net Native

zerodowned

zerodowned

Moderator
Just heard about this: https://msdn.microsoft.com/en-us/vstudio/dotnetnative.aspx

.NET Native compiles C# to native machine code that performs like C++. Windows 10 Universal applications built with C# or VB are optimized with .NET Native. With .NET Native optimization, apps start up to 60% faster and use 15-20% less memory when compiled with .NET Native. NET Native is configured to run on "Release" builds, while CoreCLR provides a rapid F5 experience for "Debug" builds.
Click to expand...
 
They love spamming .NET Native .NET Native .NET Native .NET Native xD
Would you suggest using this to run the core of ServUO?
Personally i see good and bad sides using that, mainly maintenability and pointer related issues.
 
I have not tried to compile ServUO to native code yet but I have done so in other apps. I seen no performance upgrades except for a few ms faster startup time (Within the margin of error so I disregard). One huge downside was a waaaayyyy longer compilation time. Like WAAAYYY longer.

Another positive for some developers is that since the binary is compiled to native code instead of basically a container containing your c# code for the framework to read your binary will be much harder to decompile and steal. As much as c would be anyway.

Also, if you use F# or are fond of any F# DLL's then you are out of luck, .net native does not support it.

Honestly, I am excited. I am looking forward to seeing how it goes. I believe it is only windows 10 though which kinda sucks. I could be off on that though.
 
dmurphy said:
I have not tried to compile ServUO to native code yet but I have done so in other apps. I seen no performance upgrades except for a few ms faster startup time (Within the margin of error so I disregard). One huge downside was a waaaayyyy longer compilation time. Like WAAAYYY longer.

Another positive for some developers is that since the binary is compiled to native code instead of basically a container containing your c# code for the framework to read your binary will be much harder to decompile and steal. As much as c would be anyway.

Also, if you use F# or are fond of any F# DLL's then you are out of luck, .net native does not support it.

Honestly, I am excited. I am looking forward to seeing how it goes. I believe it is only windows 10 though which kinda sucks. I could be off on that though.
Click to expand...
good to know.
it was my understanding that it is Win10 specific as well.
 
So it turns out it is only for windows 10 store applications right now, it was just a happy coincidence that the app I was working on at the time was a store app.

It would be useless for ServUO anyway since we load code dynamically so JIT is required.

It is pretty awesome though. All the .net framework stuff such as the garbage collector actually gets compiled into the native exe, you don't need to end user to have the redistributable installed on their machine or anything, they just run the exe. I figure though you will need to create binaries that target specific architectures though such as x86 and x64 instead of the framework telling the app what to do.
 
I can also confirm its for the store applications right now. But thats because they target .Net Core Native (https://github.com/dotnet/core). There is a lot of missing functionality, so so its going to be some time before something like ServUO can use it. A lot of things are changed, mainly libraries need to be portable, File IO is different, a lot of things are async/await, meaning ServUO would have to change a lot of method signatures to use Task async/await patterns. The nice thing will be however, .Net native is being created to be cross platform, so one day, ServUO will be able to run natively on Linux. One day, it will be possible, but it will require ServUO to be rewritten from the floor up, so I don't know that it will happen, not sure anyone is really up to that task, but we will see. I see async/await being the biggest problem. I use it every day at work, and have become the resident expert in it. It has a lot of caveats that Microsoft doesn't really explore in most of their samples/blogs/etc. An example of that for those that are interested is something know as "async void" and how the calling thread into a "async void" can hand off it's processing to another thread while the function has not finished, meaning the caller continues on, but the code executing inside the "async void" may not be written with this in mind.

High level example:
Code: 
private int _value;

public async void Run()
{
     _value = 0;

     await Task.Delay(1000); // wait 1 second

  _value = 5;
}

Now, lets say you run this code
Code: 
Console.WriteLine(_value);
Run();
Console.WriteLine(_value);

The console writes "0" because it the calling "Run" function doesn't return a task, so the caller doesn't know its a long running asynchronous function. Therefore, it does not know to wait for the Task Delay. So, the practice that has to be used is Run has to be transformed into an async call.
Code: 
public async Task RunAsync()
{
     _value = 0;

     await Task.Delay(1000); // wait 1 second

  _value = 5;
}

And now running the following:
Code: 
Console.WriteLine(_value);
await RunAsync();
Console.WriteLine(_value);

Writes "5".

So, what I'm getting at, is that all the functions from the top most call to the bottom, need to implement Task async/await patterns, and thats a huge undertaking. All the File IO functions in .Net Native use async/await, all the Net code, uses async/await, I can go on.. .but I think you guys might get my point ;) TPL is a bitch because of these issues, and its really only scratching the surface as far as caveats go. The entire .Net framework is fragmented at the moment because of TPL, having to use a mix of TPL + non-TPL causes a lot of issues, and Microsoft needs to catch up as far as writing most of .Net with async/await pattern code, but again, time, it takes time.

I think I may have gone off on a tangent... its late.
 
You must log in or register to reply here.
Back