11–20 of 85 posts
Earlier quoted context omitted.
CLR apps require just in time compiling which can take a little time to first run. So this should speed up opening the apps.
Sure, but ngen solved that problem years ago: http://msdn.microsoft.com/en-us/library/6t9t5wcf(v=vs.110).a...
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…
What is the difference between this and NGEN? Anybody?
What is the difference between this and NGEN? Anybody?
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.
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".
In the future, a store / certificate authority will be able to arbitrarily revoke your right to run anything on your computer that isn't approved.
Earlier quoted context omitted.
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…
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...
Earlier quoted context omitted.
No. Second entry in the FAQ ( http://msdn.microsoft.com/en-US/vstudio/dn642499.aspx ).
Damn, that's awesome! For the longest time that was the only thing that really bothered me about writing .NET code.
What is the difference between this and NGEN? Anybody?
NGEN caches native code on the machine. You're still running from the CIL executable and you still need to have the framework installed, it just loads the machine code from the cache instead of JITing it. This appears to generate a native executable.