Live data from Hacker News

Announcing .NET Native Preview

blogs.msdn.com

41–50 of 85 posts

Re: Announcing .NET Native Preview

#41

Earlier quoted context omitted.

It seems like this is basically just the same thing that Mono has done for a long time with AOT. I'm not really sure how it differs from the Ngen tool, though.

.NET Native addresses many of the same issues as Mono AOT but it has a radically different basis. We had the advantage of hindsight :) The biggest difference with NGen is the fact that .NET Native doesn't ever "fall back" to JIT compiled code. There are other differences--refactored runtime, static-optimized libraries, static marshalling, etc.--which can be seen by the perf wins over NGen. We're seeing 40% startup pe…

@apardoe, one question: where will the compilation to machine instruction happen? From some comments in this thread, it seems that it will happen at app store server and not at developer's box. If that is the case then why will I need anything to do any settings in VS for building projects?

Re: Announcing .NET Native Preview

#42
post #41

Earlier quoted context omitted.

.NET Native addresses many of the same issues as Mono AOT but it has a radically different basis. We had the advantage of hindsight :) The biggest difference with NGen is the fact that .NET Native doesn't ever "fall back" to JIT compiled code. There are other differences--refactored runtime, static-optimized libraries, static marshalling, etc.--which can be seen by the perf wins over NGen. We're seeing 40% startup pe…

@apardoe, one question: where will the compilation to machine instruction happen? From some comments in this thread, it seems that it will happen at app store server and not at developer's box. If that is the case then why will I need anything to do any settings in VS for building projects?

@rajeevk, we could compile from MSIL and not tell the developer. But you probably appreciate the chance to test out the app on your own the way your user will run it. After all, you'll want to profile it or maybe find that last on-device, optimized-only bug...

Re: Announcing .NET Native Preview

#44
post #17

Only for Windows store? So who thinks walled gardens and feudalization are coming to all desktop OSes in the next 5 years? 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.

Compiled in the cloud as well:

"Our compiler in the cloud compiles the app using .NET Native in the Store, creating a self-contained app package that’s customized to the device where the app will be installed."

Re: Announcing .NET Native Preview

#45
post #13

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.

The word is, that Microsoft is talking with Xamarin about a possible acquisition.

Re: Announcing .NET Native Preview

#47
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.

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?

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.

Re: Announcing .NET Native Preview

#48
post #2

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…

"It [...] doesn't require that the .NET framework be installed."

Are you sure? You still need the standard libraries, a garbage collector, its security checks when loading other code, and may want to use its compiler from your code. Together, that's a lot, maybe all, of what's in the framework.

Re: Announcing .NET Native Preview

#49

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".

[deleted]

Re: Announcing .NET Native Preview

#50
post #19

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.

> I don't care too much about the windows store

Don't get excited then, this is only for windows store.

Post reply on HN