It's a shame it's only for Windows Store Apps. I'd love to see what this can do to other .Net programs.
Although saying that, it's quite amazing how much of the core libraries are written in C#, you what have thought it would be wrappers over C++ libraries.
I would have loved to see this a few years ago on Windows Forms/WPF apps as well. Performance was an issue as the libraries continued to expand and grow with additional interdependencies.
.NET Reflector came in handy once or twice to copy out a few library functions to avoid adding another reference dll.
How do .Net Native and .Net Core interact? I remember there was a post about .Net Corr here a while back, and one of the advantages touted was the ability for the .Net team to push out security updates for framework dlls via Windows Update that your app would automatically use because of the CLR Cache.
How will .Net Native deal with this sort of stuff if the framework parts are directly baked into the executable?
My understanding from reading the many blog posts and some of the GitHub repo discussions: .NET Core is the refactored .NET libraries which are used by many projects, one of which is .NET Native. The cross platform work is also only in .NET Core and not the .NET Framework, the new ASP.NET is as well.
The open source .NET Core provides a subset of the libraries in the .NET Framework. Namely, .NET Core does not include WinForms, etc. The open source effort of .NET Core is divided into CoreFX (C# libraries) and CoreCLR "Runtime" (JIT, GC, C++ libraries, for the most part).
.NET Native is built on .NET Core, but does not depend on the runtime (unclear to me what that means vis-a-vis GC, and C++ libraries, which I assume are still there... but certainly no JIT).
.NET team member here ... We like to think of .NET Native as a native tool-chain for .NET Core. I say "a" because the Xamarin and Unity (IL2CPP) tool-chains are equally applicable (and we've talked to them about it).
The core framework libraries (CoreFX) - https://github.com/dotnet/corefx - are used for all .NET Core scenarios, including .NET Native (UWP). This means that your code does the same thing in all of these different environments, since it's using the same underlying framework libraries. Separately, the Mono project is taking a lot of the same code, which means that the base framework for Xamarin apps are becoming more compatible with CoreFX, too. Yeahh! We hope to make this more formal in the future. We talk to @migueldeicaza about this frequently.
Today, .NET Native and .NET Core use two different runtimes, MRT and CoreCLR, respectively. MRT expands to the extremely creative "managed runtime". Colloquially, we call it "Mr. T". Earlier in the project, everyone working on .NET Native had posters of Mr. T (yes, that one) on our doors. Mohawks were entirely optional on the parts of team members.
MRT was built for static ahead-of-time (AOT) compilation. It is the child of the Redhawk project (http://www.zdnet.com/article/microsoft-codename-redhawk-live...). Redhawk was built to be a .NET-esque (using C# + extensions) systems programming environment. MRT was built to have many of the same benefits, but be compatible with .NET (not just "esque") and support nothing less, nothing more than C#.
CoreCLR is a child of the .NET Framework CLR. CLR (and by extention, CoreCLR) was built for dynamic execution, with a JIT. It supports AOT compilation in the pre-jit/NGEN sense.
The GC is the primary shared component between the two (MRT, CLR/CoreCLR) runtimes.
We plan to bring static compilation to more scenarios, however, we strongly believe that both JIT and (real) AOT are legitimate and compelling technologies and experiences and both are on our long-term roadmap. We'd like to leave the compilation choice/appraoch up to our users/customers. Novel idea, eh?
We have a lot of fun runtime and compiler tech on the team. It's a fun place to work. Much of it is now open source, meaning that we get to work on this fun tech in the open. This is our latest compiler announcement: http://blogs.msdn.com/b/dotnet/archive/2015/07/20/announcing....
Your app is compiled from MSIL to native on MS's servers if it's like Windows Phone. I think they can recompile everything if a dependency changes for example and push a new app version for you.
Looking at MSDN and trying to find any setting about it in VS 2015, it seems .NET Native is only supported in Windows Store Apps. What about standard Winforms or Console Applications?
The end of the article says: "The current preview only supports Windows Store apps written in C# and running on x64 or ARM machines, but we’re hard at work adding support for other scenarios."
[+] [-] velox_io|10 years ago|reply
Although saying that, it's quite amazing how much of the core libraries are written in C#, you what have thought it would be wrappers over C++ libraries.
[+] [-] andzt|10 years ago|reply
.NET Reflector came in handy once or twice to copy out a few library functions to avoid adding another reference dll.
[+] [-] CmonDev|10 years ago|reply
[+] [-] Lx1oG-AWb6h_ZG0|10 years ago|reply
How will .Net Native deal with this sort of stuff if the framework parts are directly baked into the executable?
[+] [-] Eyas|10 years ago|reply
The open source .NET Core provides a subset of the libraries in the .NET Framework. Namely, .NET Core does not include WinForms, etc. The open source effort of .NET Core is divided into CoreFX (C# libraries) and CoreCLR "Runtime" (JIT, GC, C++ libraries, for the most part).
.NET Native is built on .NET Core, but does not depend on the runtime (unclear to me what that means vis-a-vis GC, and C++ libraries, which I assume are still there... but certainly no JIT).
[+] [-] runfaster2000|10 years ago|reply
The core framework libraries (CoreFX) - https://github.com/dotnet/corefx - are used for all .NET Core scenarios, including .NET Native (UWP). This means that your code does the same thing in all of these different environments, since it's using the same underlying framework libraries. Separately, the Mono project is taking a lot of the same code, which means that the base framework for Xamarin apps are becoming more compatible with CoreFX, too. Yeahh! We hope to make this more formal in the future. We talk to @migueldeicaza about this frequently.
Today, .NET Native and .NET Core use two different runtimes, MRT and CoreCLR, respectively. MRT expands to the extremely creative "managed runtime". Colloquially, we call it "Mr. T". Earlier in the project, everyone working on .NET Native had posters of Mr. T (yes, that one) on our doors. Mohawks were entirely optional on the parts of team members.
MRT was built for static ahead-of-time (AOT) compilation. It is the child of the Redhawk project (http://www.zdnet.com/article/microsoft-codename-redhawk-live...). Redhawk was built to be a .NET-esque (using C# + extensions) systems programming environment. MRT was built to have many of the same benefits, but be compatible with .NET (not just "esque") and support nothing less, nothing more than C#.
CoreCLR is a child of the .NET Framework CLR. CLR (and by extention, CoreCLR) was built for dynamic execution, with a JIT. It supports AOT compilation in the pre-jit/NGEN sense.
The GC is the primary shared component between the two (MRT, CLR/CoreCLR) runtimes.
We plan to bring static compilation to more scenarios, however, we strongly believe that both JIT and (real) AOT are legitimate and compelling technologies and experiences and both are on our long-term roadmap. We'd like to leave the compilation choice/appraoch up to our users/customers. Novel idea, eh?
We have a lot of fun runtime and compiler tech on the team. It's a fun place to work. Much of it is now open source, meaning that we get to work on this fun tech in the open. This is our latest compiler announcement: http://blogs.msdn.com/b/dotnet/archive/2015/07/20/announcing....
[+] [-] batou|10 years ago|reply
[+] [-] simfoo|10 years ago|reply
[+] [-] sandyarmstrong|10 years ago|reply
[+] [-] unknown|10 years ago|reply
[deleted]
[+] [-] joshuapants|10 years ago|reply
[+] [-] runfaster2000|10 years ago|reply
[+] [-] alyx|10 years ago|reply
https://msdn.microsoft.com/en-us/vstudio/dotnetnative
[+] [-] mhomde|10 years ago|reply
[+] [-] platz|10 years ago|reply
[+] [-] CmonDev|10 years ago|reply
Native and allowing reflection? I am now much less interested in M#.
[+] [-] pcunite|10 years ago|reply
[+] [-] PaulHoule|10 years ago|reply