I was watching the Microsoft build conference from October last year and I noticed they announced that for building the new Metro style apps, developers can write native code in C#. How is this possible? I'm just curious. Wasn't C# designed (as part of CLI standards) to first be compiled to intermediate byte code and then run on a virtual machine? How can something that runs on a virtual machine be called "native code"?
It has always been possible to call native code from managed code. Generally any .net app that interacts with windows at some point is handing control over to native components.
Historically, to manually invoke native code we would use PInvoke (Platform Invocation) - which allows managed code to call unmanaged functions that are implemented in a DLL.
What's new now is Windows Runtime, basically an ehanced COM-based API. You can read up about it here - http://en.wikipedia.org/wiki/Windows_Runtime - its just making the process easier / less overheard.
EDIT - to be clear, the presentation was not that c# could be compiled to native code. this is still not possible. they were touting winrt as providing a new (cleaner) mechanism for including calls to native code in c#.
The CoreRT project is an example of trying to natively compile C#.
https://msdn.microsoft.com/en-us/magazine/mt830370.aspx
Related
I'm used to code in .net but I'm kinda new to winRT and have a couple of questions:
When I create a Metro windows store app in c# using winRT and the subset of .net for windows store apps, is this a managed application? (hosted by the clr?) or is it unmanaged and the .net part is simply mapped to winRT.
What happens when there is a reference to a windowsRT component written in c# from an unmanaged language like c++? It makes use of the CLR or is it 100% native?
is this a managed application?
A WinRT app runs as an out-of-process COM server. Large parts of the code you use is unmanaged, anything you use in your XAML for example was written in C++. But that is an implementation detail that is pretty hard to see, it has all been wrapped carefully by the language projection built into the CLR. Which makes all the WinRT interop look like managed classes. Not unlike the way you can add a reference to a COM component and it will look like managed code as well.
For all practical purposes you can call your app a managed app and you'll use the managed debugger to fix bugs.
It makes use of the CLR or is it 100% native?
Native C++ is 100% native. Same scenario in reverse if you write a WinRT component in C# and it is used in a C++ or Javascript app, those apps have no idea that you wrote your code in C#. It is COM that's underneath it, the universal glue that Microsoft uses to allow different languages to talk to each other. The CLR takes care of the interop, just like it does if you write an add-in for an Office app or use Microsoft.Office.Interop.Excel to automate Excel.
Note how a .winmd file is pivotal to bridge the gap, the exact equivalent of a COM type library or .NET metadata that tells a compiler what the interfaces look like in a language-independent way. Also visible in some of the restrictions when you write your own WinRT component, your class needs to be sealed since COM does not support implementation inheritance. And cannot be generic. And you can expose a DateTimeOffset but not a DateTime, etcetera.
I am creating a source code editor for Java using C# in .NET 4. I need to know how I can interact with the jre to compile the java code on my application editor interface from .net. I wish to display the user any errors on the code as well. Any ideas on how to accomplish this will be greatly appreciated.
Note that the JRE is the runtime, and as such doesn't come with the compiler. You will require the JDK to compile.
I think the simplest solution is to spawn off an instance of javac from within your .Net application. Perhaps a preferable solution (however) would be to write your app in Java itself, and you can then make use of the Java compiler API directly within your app.
Perhaps the most natural interoperability method is to run the Java code in a JVM, the .NET code in a CLR, and use a runtime bridge to manage the communications between them. In this scenario, the .NET code calls .NET classes and objects that act as proxies for the Java classes and objects. The proxies manage the communication; the calling .NET classes aren't even aware that they're ultimately calling Java classes. A runtime bridge provides interoperability for a wide variety of architectures, because the Java code and the .NET code can be on different machines, the Java code can run in a standalone JVM or in a Java EE application server, and the solution provides interoperability for any JDK version. As with bytecode translation solutions, you need only the Java bytecodes, not the source.
The code for this article uses JNBridgePro from JNBridge.
I hope that question would not mess with StackOverFlow FAQ rules
So ,when using Libraries which are written in C++ for example ,and that means we have some Code in these DLL's which is going to be executed ,when Software execution cames in that case ,will this Portion of code be executed by CLR ?
I need that because we plan to develop a Software and some Angry Algorithms i think will be better to program them in C++ ,but Visual C# serves us some tools that we cant find in c++ (Linq ,Anonymous etc) .
You can use DLLs created in C++ inside your C# project, and as you already know you have to make an interop call. This switches context to unsafe, so the code is probably executed outside the CLR. This means that you lose the portability options the CLR gives you. For example a C# based app would run on Windows and Windows Phone, but adding interop calls will only make it work on Windows (or whatever system the DLL was compiled for).
But normally this isn't much of an issue.
Also see this thread: http://forums.devshed.com/net-development-87/using-a-c-dll-in-c-107829.html
I know this is a strange question but the idea is simple: I prefer C# syntax rather than C++:
-Setters and getters directly inside a property
-interfaces
-foreach statement
-possibility to declare an implicit cast operator
other small things...
What I really don't know is if is possible to import a c++ dll (expecially std libraries) in C# if I don't use any namespace (even System)
The idea is just to write a program using everything that you will normally use in C++ (nothing from CLR so), even printf for example
Thanks for any answer
No it is not possible to simply import existing C or C++ files into a C# project. They are very different languages and cannot be mixed at the source level.
The way to mix C# and C++/C applications is at the PInvoke or COM Interop level. This works by duplicating the signatures in C# and allowing the C# compiler to determine the binary layout of the native type in order to marshal between the languages.
There's now something close to this
.NET Native compiles C# to native machine code that performs like C++. You will continue to benefit from the productivity and familiarity of the .NET Framework with the great performance of native code.
It's for Windows Store apps only (desktop apps may come in the future):
Desktop apps are a very important part of our strategy. Initially, we are focusing on Windows Store apps with .NET Native. In the longer term we will continue to improve native compilation for all .NET applications.
And
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
No; this is not directly possible. In particular, C++ templates are not supported by C#.
Is there a way to create C# objects and call methods from unmanaged C++, but without using COM Iterop? I am looking for something like JNI (but for .Net), where you can manually create the VM, create objects, etc.
If you are using C++/CLI then you can interact directly with both the managed world and unmanaged code, so interop is trivial.
You can also host the CLR yourself, and whilst the hosting API is COM based, you can then create any managed object. The process isn't a difficult as it sounds as a few API calls encapsulate a lot of functionality. There is a lot of info online, for example the MSDN documentation on "Hosting the Common Language Runtime".
There is a somewhat "undocumented" way of exporting C style API from a .NET class / method.
This ultimately leads to a situation where a .NET dll has exported APIs that can be called from C/C++ or anything that can consume .DLLs for that matter.
If you are into "reading" (beh ;) you can get a book called: Inside Microsoft® .NET IL Assembler where you'll find this technique in chapter 15: "Managed Methods as Unmanaged Exports"
There's also a nice example project on code-project you can use as a starting point for 32-bit environments:
http://www.codeproject.com/KB/dotnet/DllExport.aspx
You can decide file-by-file in your C++ project whether or not to use managed C++. Try changing the settings a file in your project so that it compiles as managed. Put the calls there to your C# object.
There's a cost to crossing the C++/C# border, so you should analyse where to do it. Like, you wouldn't want to do it inside a loop.
I am author of jni4net, open source intraprocess bridge between JVM and CLR. It's build on top of JNI and PInvoke. No C/C++ code needed. I hope it will help you.