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.
Related
After days of experimenting that only led to partial success, I'd like to ask whether I have any chance or I'll invariably end up in a dead end. I have an UWP C# App, the usual framework, planned to be distributed in the Windows Store. And I also have a data package written in C++ (mostly C) that I used earlier. The old, non-managed code doesn't call any Windows API at all, it's just a data format package. But I need to access it directly from the C# side, and its most important type is authored as a value struct, with many overloaded operators (and this is good so, that approach is just perfect for the application domain).
From a WPF application, I wouldn't have any problem at all, a C++/CLI wrapper of a value struct, exposing everything. But the UWP app doesn't want to do the same. If I use the same C++/CLI wrapper, although I can get it to compile by itself, the UWP project will flat out refuse to reference the C++/CLI project.
I also tried the newer C++/CX flavor but that comes with many limitations, no specialized constructors, no overloading. It seems to be sandboxed much more than I'd need.
Is there any solution I missed? Maybe still using the C++/CLI (which has the benefit of being already written :-) ) somehow from under an UWP application?
Starting with version 1803 you should have access to a complete C++ implementation
C++/WinRT is an entirely standard modern C++17 language projection
for Windows Runtime
If you want to consume C++ code from C#, then you probably want to compile it as a Windows Runtime Component, as those can be consumed in any other UWP-supported language.
I think this is demonstrated in this documentation, even through the app consuming it seems to be in C++
In the end, I succeeded. There is an intermediate helper class (not a struct because of the inherent limitations) written in C++/CX, and the actual struct I use is defined in C#, using this intermediate.
The error messages in the process were mostly related to the underlying code being very old, C, not even C++, with all the linking and externing stuff involved. But no matter how old it is, it still works...
i'm exploring the idea of use .net as a scripting language for my program.
i found a lot of examples on internet that shows how to host .net and then, from c++ call functions from .net.
But i need to go on the other way too, from this code in c#, i need to be able to create/call c++'s objects from this c# script, so i need to expose functions/objects to control it from C#.
How can i do it?
Simple Example to show what i'm talking about
I call my c++ method "CreateGUI". It'll call .net code: "InitializeGUI", and this "InitializeGUI" need to check if an object (for example, the texture) is instantiated inside C++.
Can someone help me?
Thanks!
If you use managed C++, you can create a managed C++ component which can be called from your C# code. If you use unmanaged C++, you can either create a C++ COM component and use it through C# via RCW (Runtime Callable Wrapper) mechanism or you can create a C++ dll and call it from C# via PInvoke.
You might also investigate Mono, which is explicitly intended to be embedded and will run any compiled .NET assembly, meaning the full powers of C#, VB.NET, even F# will be available.
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
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.