21–30 of 85 posts
What is the difference between this and NGEN? Anybody?
No MDIL. NGEN can still JIT for things like cross domain generics and because it loads non-native code, still needs to optimize at run time. Project N compiles to fully native code, so there can be no JIT, and significantly smarter optimizations can happen since they don't impact performance at runtime.
Earlier quoted context omitted.
Sure, but ngen solved that problem years ago: http://msdn.microsoft.com/en-us/library/6t9t5wcf(v=vs.110).a...
So I guess this is ngen in the cloud to skip doing it on the PC.
Earlier quoted context omitted.
Damn, that's awesome! For the longest time that was the only thing that really bothered me about writing .NET code.
But doesn't anyone with the Windows Store already have the CLR?
Earlier quoted context omitted.
But doesn't anyone with the Windows Store already have the CLR?
Probably -- I don't care too much about the windows store, I'm more excited about being able to write C# code that doesn't require a VM. Not that there's anything /wrong/ with the CLR, but one thing I miss about C++ when I'm not writing it is self contained programs where it's just a small exe without a bunch of huge dependencies.
vs. the latest .NET install
https://www.dropbox.com/s/eizfqwg0ouiq4ql/Capture4.PNG
This is a brand new Windows 8.1 computer.
Earlier quoted context omitted.
Yeah I don't understand the need to get rid of a .NET framework dependency though. This only supports building Windows store apps, which only run on devices that have the .NET framework right now...
One admittedly crazy theory is that this is laying the groundwork for building iOS apps and therefore would compete with Xamarin. Any kind of JIT would not be allowed on the iOS app store.
I'm kind of scratching my head here, can someone explain what problem this solves? There's already a CLR and already a way to build native apps for Win 8, etc. This is a new CLR that can run new 'native' apps?
It gives faster startup time (due to AOT compilation rather than JIT), and doesn't require that the .NET framework be installed. Possibly better runtime performance, but I wouldn't expect huge gains there. P/Invoke should have lower overhead, which may be highly relevant for some things. I suspect that there's things that require this which they haven't announced yet, since on its own it seems like something kinda ni…
Earlier quoted context omitted.
Probably -- I don't care too much about the windows store, I'm more excited about being able to write C# code that doesn't require a VM. Not that there's anything /wrong/ with the CLR, but one thing I miss about C++ when I'm not writing it is self contained programs where it's just a small exe without a bunch of huge dependencies.
I think you're forgetting about the Visual C++ 20xx Redistributables. They aren't exactly tiny. https://www.dropbox.com/s/eizfqwg0ouiq4ql/Capture3.PNG vs. the latest .NET install https://www.dropbox.com/s/eizfqwg0ouiq4ql/Capture4.PNG This is a brand new Windows 8.1 computer.
So, uh, can I compile my C# app to an bare x64 .exe file, statically linked with no runtime dependency on the .NET Framework, that will run on Windows 7 and 8? Or not? Edit: This is a much better link: http://msdn.microsoft.com/en-US/vstudio/dn642499.aspx Still not sure though, as they say "only Windows Store apps can be created" which sounds suspiciously like "no".
So, uh, can I compile my C# app to an bare x64 .exe file, statically linked with no runtime dependency on the .NET Framework, that will run on Windows 7 and 8? Or not? Edit: This is a much better link: http://msdn.microsoft.com/en-US/vstudio/dn642499.aspx Still not sure though, as they say "only Windows Store apps can be created" which sounds suspiciously like "no".
"However, apps will get deployed on end-user devices as fully self-contained natively compiled code (when .NET Native enters production), and will not have a dependency on the .NET Framework on the target device/machine."
