It seems the comments area here is full of lots of questions and few answers. Let me try to clear some things up.<p><i>Lets start with how it currently works...</i><p>When you create an application or website in C#,F#,VB.NET or any other .NET language you are not really 'compiling' it per se to native code, you are compiling it to an intermediate language called IL - very much like Java byte code. When your application or website is run for the first time the .NET runtime converts this code to native code on the local computer and then caches this binary and officially compiled native version of your code. The result is, the first time you run your app or a section of the code there is a small performance hit while the .NET runtime converts your code to native. Let me be perfectly clear, this is a one time thing - a first time thing. Once you have gotten past that every subsequent run is going to be as fast as other native code. (Why is it not as fast as something written in c or c++ you may ask - because there are other things the .net runtime is providing for you like garbage collection, but that is a whole other talk)<p><i>So how is this different?</i><p>This preview allows you to skip this JIT process and image caching process altogether. This is first targeted for Windows store apps, when you would first run it on your machine it was slow on first launch because all this extra work was being done. Microsoft decided they could take the server side resources they had and run this JIT and imaging process ahead of time and when someone downloads and installs your app - this work was already done and first launch would be faster - as much as 60% faster. There are also lots of changes under the hood to make this all work better - Andrew Pardoe is on this comment thread further down and mentioned things like a refactored runtime, static-optimized libraries, static marshalling all combining for performance wins.<p><i>Does this mean I can build apps for Unix with C#</i><p>No, Mono is still the best way to do that<p><i>Can I build simple console apps with this and deploy to machines without the .NET runtime?</i><p>No, right now this is only available for Windows Store apps. Besides, unless you have some Windows 98 machines sitting around nearly every PC has the .NET runtime.<p><i>Will this make my app run faster?</i><p>Starting up, yes. Normal operation, probably not. .NET runtime and jitter have been around a long time and they are impressively efficient and fast. This includes some tweaks to parts of the runtime but don't expect to see your text file processing app go from 10 seconds to 2 or something like that.<p><i>Will this help me pick up chicks?</i><p>Depends.
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?<p>Edit: This is a much better link: <a href="http://msdn.microsoft.com/en-US/vstudio/dn642499.aspx" rel="nofollow">http://msdn.microsoft.com/en-US/vstudio/dn642499.aspx</a>
Still not sure though, as they say "only Windows Store apps can be created" which sounds suspiciously like "no".
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?
Was someone from marketing writing this: "the performance of C++ with the productivity of C#" ... on startup. And not even on every startup, but only the first. And not even the first, since, as you know, there already are a lot of (unarguably, productive) features (such as GC etc.) making apps slower than C++ apps.<p>Also, is it just me, but this sounds like a glorified NGen in the usual build process (compiling for production goes straight to native), instead of NGen in the background optimisation service?<p>I am all about getting the new tools, switching to new, more productive ways of development (in fact I was programming in C# for about 3 years), I simply hate when false information is being spread, just because it sounds better to the sales person.
There was GCJ that used to do this for Java. Sadly it has been discontinued.<p>It is interesting how every old is new again, we went from AOT to JIT and Back to AOT again.
It's interesting. It's more like a "static JIT" (BIT?) that does not account for the different data characteristics the instructions will process (which is something a JIT would/should do because it alters the actual program flow), but I find the "fast from the start" idea very compelling. I wonder how long will it take to Oracle (or the OpenJDK folks) to react to it.
This could lead to a way to build a dynamic language on top of .NET and eventually be usable in iOS? I ask because: <a href="http://docs.xamarin.com/guides/ios/advanced_topics/limitations/" rel="nofollow">http://docs.xamarin.com/guides/ios/advanced_topics/limitatio...</a> aka: No Dynamic Code Generation
Only for Windows store? So who thinks walled gardens and feudalization are coming to all desktop OSes in the next 5 years?<p>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.
This is great. I hope they make this available for web apps because we've got 45 second warmup time and CPU spamming due to the massive size of the work the JIT has to do when we deploy. Total pain.<p>I imagine this would help them keep costs down on Azure as well.
Its truly a great thing. A single file deployment would be a tremendous improvement. Also removing the ease with which distributed applications can be decompiled helps as well.<p>Hopefully the marketing people let them spread it to all of their application types.