This post was written by Subramanian Ramaswamy and Andrew Pardoe, Senior Program Managers on the .NET Native team.
We’re thrilled to announce the first release of .NET Native. Windows Store apps start up to 60% faster with .NET Native and have a much smaller memory footprint. Our first release is a Developer Preview that allows you to develop and test apps with this new compiler. This preview release of .NET Native offers you the performance of C++ with the productivity of C#. .NET Native enables the best of both worlds!
Download the .NET Native developer preview today and tell us what you think. This developer preview currently enables building apps for Windows Store on ARM and x64 architectures (stay tuned for x86.) .NET Native will soon enable a consistent and converged experience across devices. Today’s preview supports Windows Store applications. We will continue to evolve and improve native compilation for the range of .NET applications.
.NET Native continues to provide a first-class .NET developer experience in Visual Studio. You still get a great edit/compile/debug environment with productivity enhancers like Edit and Continue and code refactoring. You continue to upload MSIL app packages to the Windows Store. 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.
.NET Native optimizes Store apps for device scenarios in all stages of compilation. We optimized the .NET Native runtime (a refactored and optimized CLR) to make apps start faster and consume less memory. The .NET Native compiler uses the world-class Microsoft VC++ optimizer back-end to make your app run faster. .NET Native libraries are refactored and optimized for Store apps. And .NET Native has the capability to link in library code your app uses into the app, allowing the optimizer to work globally across your app’s code and library code. In the end, your app is optimized for your user’s device, whatever platform, architecture, OS or form factor it might be running. The end result –apps just get faster!
Some of the most popular Windows Store apps on Surface devices are already running on .NET Native. This includes applications such as Wordament and Fresh Paint, which are seeing multi-second startup wins.
Tune into the //BUILD conference for more details. Also, check out the Going Deep Channel 9 Video on .NET Native.
Getting started with .NET Native
The .NET Native developer preview installs on top of Visual Studio 2013 Update 2 RC.
Compiling with the .NET Native Toolchain
After your project is loaded, you can enable the .NET Native compiler. Make sure you’ve configured your app to compile for a specific architecture, x64 or ARM. .NET Native compiles to native code, so you need to target a real machine type instead of Any CPU. There are a few ways to do this—in the Solution Property Pages:
Or in the handy dropdowns at the top of the editor window:
Once you’ve selected a supported machine type you’re ready to enable your project for .NET Native compilation. Right-click on the project name and you’ll see the “Enable for .NET Native” option has appeared. (OK, it was always there, but if you selected it without selecting x64 or ARM you’d get an error.)
Selecting this actually causes a few things to happen. First, it creates a new file for your project called “default.rd.xml”. This file contains runtime directives that help the .NET Native compiler understand what metadata and type information needs to be preserved in order for your app to run correctly, so things like reflection mostly just work, even though you are statically compiling everything!
Second, selecting “Enable for .NET Native” builds your app. Visual Studio will also run a static analysis tool on your app to give a quick read on whether you are using any feature that’s not yet in the preview release. This will generate a “.NET Native Code Generation Compatibility Report” that will pop up with information about your app. Also, you can always rerun the static analysis from your project’s context menu.
If your app is like most Store apps, you’ll see this in the Compatibility Report, meaning you’re ready to test your app thoroughly with .NET Native.
If your app uses many complicated patterns or yet to be implemented features (e.g., WCF), you might instead get some workarounds and guidance. We’ll dive into each and every topic but for now if you run into any issues, please send us feedback, either in the .NET Native forum or by emailing us directly at dotnetnative@microsoft.com.
We look forward to hearing from you! Get the new VS Update, download the .NET Native Tools, start making your apps faster and tell us what you think!
Update: A number of the questions that have been asked in the comments are addressed in the .NET Native FAQ.
Will this support a WPF desktop application?
@Sean: The .NET Native Preview released today only targets Store apps but we're working on improving native compilation for all .NET apps. We've already answered this question, and a lot of others, by the way, at the Microsoft .NET Native FAQ: msdn.microsoft.com/…/dn642499.aspx.
Would this require a certain version of the .NET framwork on the target machine?
@John: Also answered in the FAQ 🙂
With the .NET Native Developer Preview, apps will get deployed on end-user devices as fully self-contained natively compiled code, and will not have a dependency on the .NET Framework on the target device/machine. So, no .NET framework required on the target machine with .NET Native.
This is great! And makes a lot sense in the server side, for critical mission applications, where performance matters a lot.
Yes, this could really help our desktop WPF app! Will I be able to compiler a C++/CLI DLL with .NET Native and then link that with my native C++ .exe?
Let's hope the team moves on from WinStore silliness to Desktop asap.
Fantastic! Question: once this is baked, what reason would I have to NOT use it for a store app? What about other apps (once supported)? Why would I want the .NET framework to ever be required on the target machine?
Are there any plans for Azure support?
When a .NET application is compiled for native, are there also some kind of PDB symbols generated as well? I am concerned about supporting such an application after deployment. In the event of a bug / hang / crash, dumps will need to be taken. There must be a reasonable way of mapping the native code back to the original source in .NET. Could you please elaborate a bit on how you plan to support this scenario?
@jps: The .NET Native Preview currently allows development only in C#.
@Kent: There's no reason to not use it for a Store app. Start evaluating it, now! 🙂 This preview only supports the Windows Store profile and the .NET Framework supports a wider set of APIs. Keep in mind that not all scenarios are suited for static compilation, thus, we are also investing heavily in our dynamic compilation story simultaneously (checkout RyuJIT @ blogs.msdn.com/…/ryujit-ctp2-getting-ready-for-prime-time.aspx).
@Jamy: Currently this preview only supports Windows Store apps. However, as we mentioned earlier, we are continuing to evolve and improve native compilation for the wide range of .NET applications.
@Ben: The .NET Native compiler goes to great lengths to make the mapping back to source code possible while debugging, even with native code! The symbol information is passed through at every stage of compilation to make this possible. And yes, the compiler does generate a PDB that allows you to debug crash dumps.
@Subramanian "The symbol information is passed through at every stage of compilation to make this possible. And yes, the compiler does generate a PDB that allows you to debug crash dumps. "
Awesome. Thanks. Was wondering that as well.
I can't find this in the Eclipse IDE?
Will .NET native be able to support dynamically loading assemblies? We have this even in our Windows Store app.
Would be very nice to have this in WPF applications so we can use it in the real world.
This is really extremely good news! Wow, fantastic and really appreciated.
If released in time for standard .NET apps, will that also solve obfuscation / reverse engineering issues? Right now it is really easy to steal the source code of my application with free tools….
Can't wait to deploy this to my clients for desktop apps (not Windows Store apps)!
sound good!
Is reflection supported?
And can I use generic in virtual methods?
I wish it would be available for WPF applications soon …
Can you please stop releasing new technologies as Windows Store only to try and force developers to adopt the crap fest you used to call Metro? Brilliant on a phone/tablet, an abomination on the desktop.
The DirectX AppWizard in VS2013 is another example – how about one for desktop app's?
I'm seriously getting worried about the direction all this is going. After over 20 years Windows development, I'm starting to seriously learn Linux as I begin to see no future employability on Windows.
Nice to see Microsoft admitting that JIT was not the way to go.
For those of us that stayed with native code it just shows we were right.
Now bring back an updated VB6 too.
visualstudio.uservoice.com/…/3440221-bring-back-classic-visual-basic-an-improved-versi
Why hasn't my previous comment showed up yet? It contained to fair questions about perf in specific situations?
All: Many of these questions are addressed in the FAQ: msdn.microsoft.com/…/dn642499.aspx
@Rogier: Because .NET Native uses the C++ optimizer to generate binaries it eliminates the need for an obfuscator in most cases. Do note that you can reverse-engineer even C++ assembly code, but it's far, far harder.
@Belleve: Reflection is supported to the extent that the Windows Store supports reflection. And generic virtual methods are supported as well. Check out the MSDN documentation for some good details there.
@ST: We're actually heavily investing in our JIT as well. Bing for 'RyuJIT' for a lot of details. Different scenarios require different capabilities. We're building best-of-breed on both ends of the spectrum.
@Ultrahead: I'm sorry, I don't know why your comment isn't showing. We don't delete comments. Could you please try reposting? If that doesn't work please send me a mail at firstname.lastname@microsoft.com and I'll post it for you.
Ok, read the FAQ: one of the questions refered to perf imporvements for interop calls, so it has been answered 🙂
Now, about the scenario: let's say I create a library with C# and I want that the apps/games that consume it get advantage of .NET Native, how is the process here for compilation?
I mean, I guess that a .NET project in Visual Studio will not be able to directly reference a .NET Native library, right? Or will it? In case not, and a standard .NET version of the library must be provided for referencing in VS, will .NET Native compiler also compile and link all referenced assemblies to native bits?
There are many, many VB6 programmers who want to see VB6 back in a new version (a parallel version to Visual Studio). I do programming in both VB6 and VB.NET and I think a new version of VB6 would be welcomed.
@Ultrahead: .NET Native currently compiles all referenced code into a single MSIL image that gets compiled by the C++ compiler so you're correct, a .NET project can't directly reference a .NET Native library. Your last statement is correct–an MSIL version of the library is referenced and it's all statically linked in and compiled.
Libraries present an interesting challenge for static compilation as they complicate the heuristics around knowing what metadata and types are referenced. For example, the library may expect to create a generic type out of a type that doesn't exist in the library itself.
Short answer: if you are a library author and you want to help make .NET Native work well for library authors, please mail dotnetnative@microsoft.com. We'd love to work with you.
Unfortunately this is about 10 years too late. .NET is becoming less relevant as focus shifts to the Web and languages such as Typescript take over.
Thanks for the answer.
Actually, I'm a videogame dev and .NET Native really interests me.
When working with C#, my code consumes third-party libs, like for instance, SharpDX (either directly, or indirectly through APIs like Monogame's, WaveEngine's, etc.). So I was thinking of how or to what extent .NET Native can benefit my games by also compiling and linking these third-party libs, resulting in a perf boost with results close to pure native code (even with managed memory).
Would love to see a version of SharpDX optimized for .NET Native compilation. Let's hope Alex is reading this (I'll let him know in case he hasn't yet).
If I compile native my Win Store Application .. can I upload this native app to the store?
If it is possible this means that the app will be much hard reverse – engineered, right?
When you expect the Win Phone 8.1 version to be released? In fact is it now usable for production at all?
@Ultrahead – we definitely aim to have applications that use third party libraries like SharpDX and MonoGame work very well with .NET Native. One of the main ways that library authors can make their libraries .NET Native friendly is to make sure that their use of reflection is self-describing, by providing a library specific .rd.xml file. The preview SDK ships with some .rd.xml files for several popular libraries we've seen in use in the Windows Store (including SharpDX). While improving our ability to automatically detect reflection uses will be a point of focus as the .NET Native SDK continues development, having libraries provide .rd.xml files themselves is the biggest thing that they can do in order to make it easier for applications to use them with .NET Native.
We'll have more information on these library .rd.xml files coming shortly in a series of blog posts by one of the devs on our team who worked on getting store apps that use SharpDX and MonoGame up and running.
can anyone at Microsoft please explain why WPF is ignored in favor of terrible store/modern/metro !
why was VS made so painful to look at ? its like a visual warning say "avoid this crap!"
having spent a lot of time with HTML5 canvas I can see why you can only do solid color/Image brushes without knowing the position of the element , so when you make the argument that its "design language" you lose all credibility with me, we will never,ever, ever develop store apps, its a complete debacle, and when you try to force adoption by not supporting WPF or even responding to direct requests, are you really sitting around in your stupid meetings thinking "We'll just say,blah blah blah [insert BS specious argument here] sorry not at this time", do you think we are Morons ? We have a huge investment in .net/WPF /Silverlight and all we get its more games and double talk from you guys, let me assure you, many more moves like this and the we will have no options but to move on, no matter how painful/expensive !
@Alexander
In the developer preview, we currently do not allow uploading of the native binaries to the store. When .NET Native gets closer to completion, the idea is similar to how Windows Phone apps get compiled. You would upload MSIL to the app store, and the app store will run the .NET Native compilers to produce the native binaries that would download to end user devices.
The final binaries that come out of the .NET Native compilers have code that looks much like the code that the C++ compiler produces, with a similar bar for reverse engineering. (Not at all coincidentally, the native code generated by the .NET Native tool chain is actually produced by the back end of the Visual C++ compiler).
Right now we're focused on Windows Store apps, but as we continue development on the .NET Native tool chain you can certainly imagine that we'll add other natural targets such as the phone. We don't have a date for that at this point unfortunately.
After more than a decade we end up with …. Delphi. A fast compiled language with a nice syntax. Anders must be pleased.
Release it under an opensource licence like MS did with Typescript.
@Shawn: great! Looking forward to it.
First of all this is awesome news and i can't wait to see more and get better performance specially on desktop applications!
Now i have a curious question…. basically this provides the performance of C++ and kinda turn C# into the new C++ of the future right? now…. what would happen to C++ after .NET gets better? i mean… looking at the beauty of C# as well as other nice features it has and now this i personally find hard to even touch C++ myself for future applications. Productivity is a key feature that has high priority in a world that is moving fast but C++ is still used as in some scenarios performance have just higher priority. Now that we have this and if continues to improve i personally see an obscure future for C++ at some point in time, at least on Windows.
Correct me if i'm wrong please.
@John Wernd: As a former member of the C++ team I can tell you C++ still has a future : ) Different languages are great for different scenarios, and C++ still hold the gold standard for consistently fast code (if only because people don't write assembly anymore…) But you're right, the performance .NET Native makes the productivity of C# available to a large range of developers.
So will Microsoft please tell us what the future is for the VB language? .NET Native and Xamarin's product neither support it. Is it over for VB?
@David: VB support is coming, don't fear! .NET Native is in preview. C# first, then the world!
Gotta admit that I love this comment: "…, the performance .NET Native makes the productivity of C# available to a large range of developers."
@Andrew Pardoe: Thank you for the quick response! i work as a C++ developer myself but i have to admit that i'm a WPF/C#/MVVM lover. I didn't meant that C++ is going to die anytime soon but that considering .NET Native improvements over the year in combination with a language like C#, productivity, XAML, MVVM and a hell bunch of stuff it has to offer i see many developers switching in the future and using C# more. One of the primary excuses not to use C# is performance and if .NET native brings such advantages companies will pick up C# quickly as nowdays software need to be done faster. When i think about how easy it is to develope robust apps in WPF and then think about MFC which we use daily at work…. i can only conclude that there are worlds apart.
I love C++ as well but the C# beauty got me many years ago :). The company i work for would love to use C# but due to performance it hasn't been an option. Now with .NET Native things could finally change in the future. Talking of which…. how far can we go in future versions of C# and .NET Native when it comes to low level? i'm not that far with my C# knowledges just yet but will be interesting to know.
I just forgot one last question on my previous comment. What about availability for Linux or OSX? personally i've been waiting to see WPF applications running on something else than Windows. I can see a bright future there because people will still go back to Windows and use Visual Studio and other great tools. Having a compiler for other systems as well as cross-plattform development would be awesome.
I love what Mono and Xamarin are doing but to be honest it feels kinda basic when comparing to the real thing like a robust WPF application rather than some standard designed window on Linux. Is there a future in that area? such a move could be a breakthrough for the recently announced "Unified Apps"
Wasn't this part of the original concept. Somehow I left WinCE 2000 in Denver thinking this was the message being delivered
@John Wernd "The company i work for would love to use C# but due to performance it hasn't been an option." – being on .NET perf team, I would love to know more details about your scenarios that you find slow. Can you please send me email to karel.zikmund@you-know-where.com?
What kind of operating system support?
we all know,the CLR manage the memory ,what about this ?
.NET allocate many Large Object Heap(bigger than 85K bytes) will cause OutOfMemoryException error,even the program that does not leak memory,and which never requires more than a fixed amount of memory to perform an operation.Does .NET NATIVE solved this?!
The Dangers of the Large Object Heap
http://www.simple-talk.com/…/the-dangers-of-the-large-object-heap
about time
one of most restrict 'feature' of managed app has gone
more and more native compiled store app are coming
So how is this different from ngen'ing assemblies, apart from removing the dependency on having the CLR installed?
How does the native code do heap allocation? Does it use a GC or does it somehow use malloc?
This looks very promising. I managed to use C# in a very unusual fashion to get decent performance on a real-time number crunching application (sdrsharp.com). Supposing the same auto-vectorization techniques are used in this new compiler back-end, I expect some parts of my DSP code will leverage the new compiler to compete with hand tuned SIMD code.
Congratulations for this achievement.
Amazing! 😀 Thank you SO MUCH!!! gonna try this today 🙂
Oh why the hell is this for apps only 🙁 Can't make any use of that.. will Winforms & Console be supported anytime soon?
Very interesting…. so C# is now a sugary syntax over the top of the C++ compiler. About time too 🙂
Now, I think I know the answer to this ("no") but can it take a native library and include/import/link it in with a .NET Native application? Would it be possible to expose an ordinary .lib file to a .NET application so we could to this, either directly or by creating a thin wrapper?
If so, you could write all your libraries as native code, and link them to either .NET or C++ programs! And that means I could take some of my favourite OSS libraries (eg ffmpeg) and use them in .NET apps. Please say you'll at least look into this!
Good stuff though, I always said best tools for the job – C++ backends with .NET fronts made sense. Now even .NET agrees with me 🙂
Guys, the NET Native is WRONG THING !!! I fully agree with idea of unlocking more speed from .NET, but NET Native is wrong direction. NET is slow in multiple areas, because you limited options with all-or-nothing philosophy. NET Native is about creating more mess to NET world, than fixing obvious problems within NET itself. You must try to extend NET to reduce overhead and fix wrong paths, than providing convoluted and limited workarounds like NET Native. To be more concrete, you should consider few improvements to NET itself:
Give us ability do disable runtime type checking, array bound checking and others. Best way to do it is to use attributes. Type safety is great when aplication is developed, but when code is flawless, then this feature is useless overhead. Of course, some scenarios requires type checking all the time, but these are minority.
Give us more control on GC and memory management. Most overhead come from checking references betwen objects, and we want to disable this checking on givent object (and his subobjects) to improve performance. Thisa can be done by method GC.SetCheckReferences (obj, bool). Additionaly give us option to remove particular object from memory on demand, by adding method GC.Remove (obj).
These improvements do not break any compatibility and can improve pervormance in multiple areas. On the other hand, NET Native only reduces startup time (in most significant way), which can easy achieved by traditional ngen-izing IL binaries at instalation time. This way NET Native is useless.
Latest lesson MS gained from DX11 vs Mantle, lead to simple equation: more control = more speed. Do it with .NET
Folks, lots of the questions you're asking are addressed in the .NET Native FAQ: msdn.microsoft.com/…/dn642499.aspx
@JadeB: There is a GC included in .NET Native apps. Type safety is important to us, and memory safety is a key part of type safety.
@The_Assimilator: There's lots of good information in the FAQ and in questions already answered here.
@Aron Parker: Windows Store apps right now. It's just a preview, and just a preview for a v1. Everything is on our radar.
@AndyB: All app code currently gets compiled and linked into a single assembly. Download the tools and try them out : )
@TBRMDEV: Thank you for the suggestions. We do want to preserve type safety and we firmly believe that garbage-collected memory can be a performance enhancement over managing your own memory. You might like reading about Raymond Chen's adventures comparing the two. There's a good reference/index on Rico Mariani's blog: blogs.msdn.com/…/416151.aspx
@Andrew Pardoe
"VB support is coming, don't fear! .NET Native is in preview. C# first, then the world!"
Will be Classic VB6 part of the world?
Cheers,
@Miquel Matas: Microsoft will support your existing Visual Basic 6 components and applications through the lifetime of Windows 7 client and 2008 R2 server. msdn.microsoft.com/…/ms788229.aspx
@TBRMDEV "NET Native only reduces startup time (in most significant way), which can easy achieved by traditional ngen-izing IL binaries at instalation time."
We quote comparison with NGen, because having NGen images is typical situation end-users experience with .NET Windows Store apps – NGen images are automatically generated by AutoNGen for all .NET Windows Store apps on Windows 8+ (see blogs.msdn.com/…/got-a-need-for-speed-net-apps-start-faster.aspx).
@Joelihn "The Dangers of the Large Object Heap"
What about Large Object Heap Compaction that was introduced in .NET 4.5.1? http://www.simple-talk.com/…/large-object-heap-compaction-should-you-use-it
Can someone please explain just what is "C++ Performance" when it comes to .net? .Net is a JIT-compiled, not interpreted. Presumably a JIT-Compiler can/should achieve the same, if not better, performance than what an ahead-of-time compiler can achieve since the JIT may know more information about the user's local system.
Why not simply improve the JIT-Compiler to include all of these "C++ Optimizer" benefits that are being touted about?
@Shaun: "C++ performance" refers to the fact that we're optimizing .NET code with the C++ optimizer. We're doing other things to improve the performance–read all about it on the download page at aka.ms/dotnetnative.
We're also improving our JIT compiler. Different technologies suit different scenarios. Read about the new JIT at blogs.msdn.com/…/ryujit-the-next-generation-jit-compiler.aspx
@Andrew Pardoe
Visual Basic 6 "It just works" support is provided on Vista, Server 2008, Windows 7 and Windows 8 – giving support until 2023.
msdn.microsoft.com/…/ms788708.aspx
In practice VB6 applications should continue running as long as Windows uses the Windows API.
But the support is for the VB6 runtime, not the VB6 IDE.
While the IDE does work on Windows 7 and 8.x this isn't really enough. Microsoft should update VB6 to include the 64bit modifications added to VBA7
It is expensive to rewrite legacy VB6 applications, and this fact is holding back many XP users from upgrading to Windows 7.
visualstudio.uservoice.com/…/3440221-bring-back-classic-visual-basic-an-improved-versi
Will this remove .NET Framework dependencies? e.g will this work on an XP machine without installing .NET framework?
It's time I'll start to learn C# :O
In the FAQ i see this "Even though the binaries are natively compiled, we maintain the benefits of managed code type safety (and thus Garbage Collection) and the full C# exception model". I don't understand who manage the memory and code if it says too that no need .Net Framework (ig no CLR).
@Sten2005: UserVoice is the best suggestion I can give you for VB6 support. Sorry o_o
@Johnattan: There is a GC included in every .NET Native app.
Hi guys,
I'm the development team lead of WaveEngine and this is so interesting for us, if there is a possibility to participate with you to check .NET native with our engine, let me know who I can contact.
Thanks
This looks absolutely awesome. Hope this continues to be supported and developed fully.
@Javier Canton Ferrero, please send mail to dotnetnative at Microsoft dot com. I'll pick it up. We're looking forward to working with library vendors!
YESSSSSSSSSSSSSSSS!
Hey,
great work with the library! I was trying to do some startup time measurements in my app based on your suggestions here: msdn.microsoft.com/…/dn643729%28v=vs.110%29.aspx ("Measuring Startup Improvement with .NET Native").
I made 2 versions of my app, one with standard compiler, and the other using .NET Native compiler. I was able to measure startup time using standard compiler – the events AppInitialized and MainPageInitialized showed up in the PerfView log. As soon as I switched to the app compiled with .NET Native, those events were not showing up in the log anymore. I am using the same AppEventSource class implementation, and calling the Log in the same places inside the app. (ManifestData event still shows in the log for both apps, but that's not very useful…)
Any ideas what's wrong? Did I miss a step somewhere? I appreciate your help!
Igor
Is the native managed runtime open source:
MRT.dll (Managed Runtime)
For core complier and language runtime techology MS needs to be open source end to end. Like Apple is with Clang/llvm. (The Windows Runtime – the core of the Modern experience – can be closed source. As Apple is with the GUI part of its platform).
Will it support CodeDom? I mean would I still be able to compile code at runtime and make NATIVE executables?
I have been asking for this compiler for years, so I'm glad to know about this project.
http://www.gamasutra.com/…/Regarding_the_future_of_C_.php
So, now that SIMD is around the corner for the upcoming Jitter, will we also have SIMD for .Net Native code?
@SharpDev: Currently CodeDOM isn't supported. CodeDOM requires compiling code during execution so it doesn't work in a fully static environment. When we bring .NET Native to scenarios requiring CodeDOM we'll make this work but it necessarily requires dynamically creating the code (e.g. JIT) that the program emits.
@Ultrahead: SIMD is available already in the RyuJIT CTP3. .NET Native will use vector instructions in its generated code.
@Igor
Sorry about the trouble using the EventSource class. You uncovered a bug here. There’s an issue that prevents events that don’t have event arguments from being emitted. This means that calls like WriteEvent(1) won’t work on this release of .NET Native. (Note that '1' is the event ID and not an event argument.)
The workaround is to just add a dummy argument to the event. Just use one of the other overloads of WriteEvent to do this. For example, take calls like WriteEvent(1) and turn them into WriteEvent(1,"").
I have filed the bug for this internally and I expect it to be fixed in the next release of .NET Native. We’ll also update the documentation in the interim.
@Andrew Pardoe
"UserVoice is the best suggestion I can give you for VB6 support. Sorry o_o"
The lack of VB6 support from Microsoft has been with us for a long time.
With good news from Microsoft on .Net Native and the open sourcing of Roslyn I can only assume that VB6 wasn't mentioned because no one in Microsoft thought about it.
According to the Tiobe index, VB6 is still more popular than VB.Net – 16 years after the latest release.
So why don't Microsoft either update VB6 or, if they won't do that, open-source it.
At least Microsoft could give an answer rather than passing the question around.
Remember there are lots of VB6 applications out there still in everyday use – this is one of the reasons end-users aren't upgrading from Windows XP.
Here is the issue on UserVoice:
visualstudio.uservoice.com/…/3440221-bring-back-classic-visual-basic-an-improved-versi
@Andrew Pardoe [MSFT]
"We do want to preserve type safety and we firmly believe that garbage-collected memory can be a performance enhancement over managing your own memory". In most cases – yes. But experienced programmers can use sugested featurec, to reach performance levels unreachable today.
@Karel Zikmund
You can improve ngen with this 'superior c++ back end compiler' and copy these optimized CLR libraries to user machine. This way you can also avoid 'duplicate the same code with each generated assembly' problem. Result is the same as NET Native without limitations.
I do not see benefit with ablility to run natived apps withoiut installing of NET. Is there any windows without .NET installed ?
If NET Native convert IL to CPU code, why it is limited to C# (even if temporarily) ?
@Sten2005: Yes, there are well over 5000 votes in support of bringing back VB6. I'm sorry I don't have a better answer for you. Soma and ScottGu both have blogs 🙂
@TBRMDEV: We believe in the benefits of garbage-collected memory, not just the performance aspects but also the correctness aspects. We believe our optimization strategy will benefit apps in these scenarios. And we see a benefit to deploying apps independent of the installed runtime. I'm not sure what I can say except that we think we made pretty reasonable design decisions with .NET Native and we'll adjust those as we see how it works.
As for why C#, even if temporarily, we have a limited number of resources and potentially infinite work. .NET Native is in preview. Some things are missing right now, such as other languages and x86 support.
@TBRMDEV: It occurs to me I can address your last point a bit more specifically. Each managed language generates slightly different patterns in MSIL. The VB compiler generates exception filters, for example, and F# generates a bunch of tail calls. MSIL from one language is a subset of all valid MSIL so it was less work for us to focus on one language first.
@Andrew Pardoe, to be honest i'm not sure if i get your answer quite right,
Most of my applications (Desktop) compile and create temporary EXEs at runtime. I know that is currently not supported. but is there a plan to make the same thing possible with .NET NATIVE?
I rather have all my applications compiled to native, but if that is not gonna be possible then i'm afraid i will be staying with current .NET framework.
@SharpDev – this developer preview of .NET Native is targeted at Windows Store apps for the time being. Windows Store applications code against the .NET Core profile, which does not include the CodeDOM types. Therefore, apps which use CodeDOM currently will not work with this tool set.
That being said, this is an early developer preview and as we expand our scenarios beyond Windows Store we will need to look at all sorts of dynamic code scenarios including CodeDOM to see how they fit together with .NET Native.
@Shawn & Andrew
Is the native minimal runtime (mrt100.dll) open source?
@kevin – the runtime portion of .NET Native is not open source at this time.
@shawn
Open sourcing the native runtime would definitely help get developer buy in. It's the missing piece of the puzzle.
can silverlight code be compiled with .net native?
@iamveritas – the current developer preview is for Windows Store apps for Windows 8.1 only. As we continue to develop the product, we'll prioritize and consider other scenarios as well – but for now only store apps are supported.
So why can't this just be a better set of pre-jit optimizations? Seems silly to me.
THIS IS YET AGAIN SHAMEFUL – VB.NET IS SENT TO THE BOTTOM OF THE LINE YET AGAIN AND TREATED AS A SECOND CLASS LANGUAGE.
There is no way in hell I would ever go back to C# to write code, just the idea of coding in C# takes all my motivation to code away. I absolutely love coding in VB.NET, a modern language, not outdated by 40 years like C/C++/C#.
If MS burns us with this and VB.NET isn't supported in .NET Native 1.0 RTM, I am totally leaving the .NET Framework, I've almost had enough of being treated as an after thought, especially when during 2001 .NET Launch, VB was the popular language and the tech heads at MS single handedly (each one of them individually, without orders from anyone) did their bit to kill VB and popularize C# by using C#, giving examples in C#, coding for C# first etc… even when VB was the popular language, and this is what happened.
I'm so sick of it, people are forced to use C# because of people like you making decisions like this.
"WHEN WILL WE GET VB.NET SUPPORT?"
I feel your pain, after the Sept 2011 Build conference I jumped on the "power and performance" modern C++ bandwagon and have invested much time and energy in learning it (since then). I was surprised to not find it supported (as yet) and am reading the signs carefully – they read that C# is where the investment is going to be made and if you want to play this is the place to be.
I think misery loves company because at least we know we are not suffering alone. What was a turning point for me (in excepting that I can never become an expert) was Rocky Lhotka's article "Keeping Sane in Wake of Technology's Pace", an excerpt follows:
"In 2007 I found myself becoming increasingly unhappy, feeling more and more overwhelmed by the rate of change. I felt like I was slipping farther and farther behind. However, the rate of change is outside the control of any of us individually. So this year, rather than fight or despair about it, I’ve chosen to embrace and revel in the change. "
visualstudiomagazine.com/…/keeping-sane-in-wake-of-technologys-pace.aspx
I'll embrace the change and hope my framework can be completed before this one becomes obsolete, i.e., a new one doesn't come out in the next year and I jump on that bandwagon…..
We've definitely heard the feedback regarding VB support. One thing to keep in mind is that this is an early developer preview of .NET Native, and it is by no means yet a feature-complete product. This first preview focused on C# Windows Store apps as a way to get .NET Native boostrapped. Over the coming months, we'll be looking at our list of prioritized scenarios and continue to bring those online. You should in no way take away from the fact that .NET Native does not yet have VB support anything about if it will ever have VB support in the future.
-Shawn
@WHEN WILL WE GET VB.NET SUPPORT?
"THIS IS YET AGAIN SHAMEFUL – VB.NET IS SENT TO THE BOTTOM OF THE LINE YET AGAIN AND TREATED AS A SECOND CLASS LANGUAGE."
And that's exactly where it belongs.
You will never learn! Visual Studio team will waste a few more years and after that a smarter Visual Studio team will bring back Visual Basic 6.0. I do not understand how you can be so blind! Like you intentionally sabotage Microsoft ! For now, Visual Studio team spends money without any results and any feedback from us.
You will never learn! Visual Studio team will waste a few more years and after that a smarter Visual Studio team will bring back Visual Basic 6.0.
I do not understand how you can be so blind! Like you intentionally sabotage Microsoft ! For now, Visual Studio team spends money on VB.NET without any results and any feedback from us.
It is not nice to censor my comment … the general opinion is there already …
Open sourcing the .NET Native runtime would be the utimate act of good faith from MS.
I haven't been interested in MS tech since 2002 when I first checked out .net – but decided Web 2.0/ajax was a better client side route.
But native .net unified apps are really compelling. But this core tech needs to be open source in it's entirety.
Once this is released for Desktop apps, will the native executables be compatible with older version of Windows?
@Ivan – right now the preview tool chain targets Windows Store for Windows 8.1. It's difficult to say what the requirements would be when new scenarios get added in the future, since those haven't yet been sorted out and designed.
For our information when we start working on those designs, what versions of Windows would you be interested in us supporting?
Having this only for Windows Store apps is like not having it at all. None of my customers want Windows Store apps. They want WPF. They would love to use the Windows Store SDK as long as they could deploy the apps themselves, but no dice.
So, when it is available for WPF and ASP.Net, and WCF, and everything else in the Microsoft world that actually matters, get back to me and I'll be delighted to try it out.
I dont see this .NET Native option anyware. I opened up a new vb.net windows store application and changed the architecture to x64, but I dont see the option anywhere!! What else do we need to do.
@John – The current developer preview SDK supports C# Windows Store apps only, so the menu option to enable .NET Native will not show up for a VB.NET app yet. VB is on the list of items that we are prioritizing for future preview releases, but in this current version you'll need to use a C# project in order to experiment with .NET Native.
Yes, .NET NATIVE is a great thing, if it also works for desktop. This is the question.
The FAQ reads as if this was the case, but will it happen within a reasonable time? Because, I think, this is what many people are interested in, due to two crucial advantages .NET NATIVE offers:
Performance
And let's be honest: Most commercial programming is done for the desktop as it THE platform designed for productivity.
So can you tell us something about your priorities-list and whether the desktop is a near or rather far away target for .NET NATIVE?
Hey Shawn,
I guess you mean, when desktop-support "comes". As I understood, .NET NATIVE does not support desktop right now.
However, I share your opinion reagrding the necessity of desktop-support. And I also am very interested in some kind of timeline or priority that tells us, if and/or when we can expect .NET NATIVE for desktop apps.
We're absolutely interested in getting many of the benefits of .NET Native to desktop applications. This project is still in its early phases to be sure – what we gave out at //build is an early developer preview of .NET Native. One of the benefits we have from starting with .NET applications in the Windows Store is the fact that the .NET Core profile is a limited subset of the full .NET Framework. That allows us to boostrap those applications more quickly since there is simply less functionality that we need to build to get those applications working.
WPF applications have access to the full .NET Framework, which is a much larger target and therefore requires much more time to get up and running. I can't predict future timelines, but I would say that you should expect .NET Native to come online for the smaller profile frameworks first as it works its way up to bigger frameworks.
That being said, we definitely know that desktop WPF application developers are very interested in the benefits of .NET Native and getting those benefits to you is something that we do want to do in the longer term. One thing that will help guide us is to see which of the benefits are most interesting to you as a desktop developer. From Shawn's comments it looks like he's interested in being able to distribute native code without IL, and get the performance of the code generated from the C++ compiler. Is that the same functionality you're interested in Timothy, or are there other features of .NET Native that are appealing to you?
Absolutely.
Performance is always welcome. However, one must admit that there has been a great progress since the first .NET version reagrding execution time. Combined with the progress in computer technology, I think that for most applications (except "niche-apps", for instance in finance), execution speed is at least sufficient.
Code Security, in my opinion is a much more important advantage for commerical application. And offering the same natural security in C# that C++ offers, would be awesome.
Bring back VB6 in parallel with VB .NET.
If NET Native app is independent from NET framework, can it work on Android / ios ?
@Tristan – currently .NET Native runs on Windows only. However, you might be interested in checking out Xamarin which provides an ahead of time compiler for C# code that does build for Android and iOS targets.
@ShawnFarkas, we would like to see .NET Native support for WPF desktop apps in order to improve cold startup time. More importantly though, we do embedded development work. We would love to be able to share more code between desktop apps and embedded apps but .NET CF on certain ARM chips runs like a pig. Having .NET native compilation for .NET embedded software seems like a great fit to enable these apps to run on resource constrained (read cheap – very cheap) processors.
A big +1 for adding native compilation to desktop apps as soon as possible.
When will IIS be available for ARM processor 🙂
is support on win 7 or in the future?
Really looking forward to .NET Native for Desktop applications. It will provide significant advantage to startups as we can leverage the advantages of C# i.e. quick development time, extensive set of base class libraries etc, while protecting our code dissassembly – which is the only reason we are currently using C++. Please make it available for Desktop apps asap! Right now, general developers just arent aware of this initiative otherwise there would have been a lot more vocal supporters.
This ".NET Native" seems to be yet another JIT compiler. If MS is the only one that can compile native images, it is still a JIT compiler.
It is not the "Native" compiler desktop developers have been waiting for. ".NET Native" still requires the entire application's IL code to leave the vendors hands. I hope it turns out to be more than just “smoke and mirrors.”
I am sure that speeding up Windows store applications is a high priority. But, I would think that MS could spare a few programmers for developing comprehensive code protection software for vendors. Many vendors have already spent thousands on obfuscation products which simply cannot obfuscate all important code due to reflection and other .NET features. A native compiler for vendors would not have to support the entire .NET desktop library if the unsupported parts could still be used as IL and obfuscated. Perhaps that would require collaboration with the RyuJIT team?
Yes, speed is important too.
I understand… Microsoft's concentration is on "the cloud", subscription services, mobile devices, and enabling every "Tom, Dick and Harry" to write simple applications. I get it… that is where the money and power is. Money from commercial developers cannot possibly compete with all of the subscription fees and the commissions for every application "Tom, Dick and Harry" sells. Commercial developers have been "left out in the cold" for many, many years now. I do not see that ever changing.
Microsoft is a big company… can't they "take over the cloud" and also throw desktop / client server software developers a bone? Some applications just do not belong "in the cloud."
OK… my soap box has collapsed. 🙂
I think one of the next targets for ".NET Native" should be the .NET Micro Framework. It is even a smaller subset of .NET. A native compiled app linked to the native framework that is stripped of unused code would make .NET MF smaller and much faster. Including the JIT compiler and the unused framework code could still be an option. Visual Studio native compilation for non-.NET source code sections is really a necessary feature for .NET MF to succed.
Later, add in easy Visual Stuido setup for the popular in circuit programmers and a Microsoft debugger / profiler. These features along with intellisense for the native code libraries would give Microsoft a very desirable embedded systems programming environment.
I have the weirdest boner right now.
6 Months and still not for VB.NET and desktop ?? !!
when you prepare this tool for all .NET apps?
thanks.
Are there any update about the native compiler project? When will it be officially released to public?
This is all cool and great.
I am waiting to see this working and hope there are no bugs.
However, I would love to see all the .NET Framework functionality in an unmanaged environment without GC, reflection, etc. What I mean is: you at MS have left C++ too far behind in time while caring only for .NET. If C++ had all these shiny functionalities well organized into libraries as in .NET, you would make A LOT of people happy. What I mean is having, for example, a C++ class called "Path" with static members like "Combine()", "Exits()", etc, without having to dig into header files and calling global Win32 functions as you would normally do.
I really like C#, but honestly, I doubt that any C# app will ever run as fast and efficiently as a native C++ app. What you try to do is cool, but it also complicates things. It might be also good to have a cool native API that is somewhat friendlier and more productive what C++ had so far (namely: Win32 API, STL, MFC, etc). I think that most of the .NET namespaces could be transfered (as a functionality) into C++, allowing people who have the abilities to write apps in 100% native C++ to do so, but in a more humane programming world. C++ is still good, only its libraries are relics of the past that need to be replaced ASAP.
It is the base code of .NET Framework that holds most of the joy, not .NET itself. Missing things like reflection, etc could be handled/worked-around with much more ease in an unmanaged world compared to what you are trying to do right now in .NET for making apps run faster.
At least that's my take on this.
Certainly Apple and Google don't think that native code or C++ is dead, unlike MS.
If fact, and correct me if I am wrong, I think that they don't get along with managed languages so much.
And from your direction, I guess that you are starting to notice that your apps are not as performant as theirs.
I think it would be best if you created a variant of the C++ language that supported some syntaxes/features of .NET as you did with C++.NET (e.g. namespaces, foreach, etc) and just let it be native from its System namespace bottom up to its top. Then make it work with XAML for its UI and I am sure many of your disappointed developers with be happy again.
And one more thing: do not stop improving WPF.
All your technologies that you leave for dead, like MFC, WinForms, WPF, etc are still used to develop apps and they will still be used in the future. Declaring them idle/dead/whatever does not promote you phone market, but turns developers against you.
I am writing too much.. I know…
It think its too late for announcing this great tool at least for desktop. Currently all Windows Vista, 7, 8 and 10 already have .NET installed. But from optimizing view, it's still a great tool.
Is the Preview free to download?
What are the timescales for expanding this to work with windows forms apps?
bleh, this takes forever to release on desktop platform
disappointed
Will this eventually support native compilation in Visual Basic.NET? I hope it will!!
Do you have a ballpark date for desktop application?
@GypsyPrince: Visual Basic is now supported for Windows 10 UWP apps. Try it out in VS 2015 RC!
@GeoffUnique: Unfortunately, we don't have a date to share for Desktop support. VS 2015 will only support Windows 10 UWP applications, but we're going to look at expanding to other scenarios in future versions of Visual Studio.
We've had native compilation in Delphi since 1995. Anything less is, well, less. M$ catches up 20 years later.
.net native how I feel microsoft not too likely to provide it?