Develop Reference

Using a C++/CLI/CX/etc data package from an UWP C# app

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

About .net and winRT

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.

How to use cross platform C++ with a WPF C# GUI

I'm currently in a project that need to work both on Mac and Windows. We are using standard portable C++ for all the application logic. However, since we want the app to feel totally native on both platform, the GUI will be written with C#/WPF for Windows and Objective-C/Cocoa for Mac.
However, for the windows part, I am wondering what is the best way to use the C++ code with C#. C# is managed, and I know that we can use managed C++ too. However I worry that using C++ inside the CLR may introduce unexpected bugs, or that we will need to put an awful lot of #ifdef WIN32 everywhere in the C++ code to make it work both with the managed CLR and the unmanaged environnement of Mac OS X (note that we sure expect to put some ifdef, but we'd like to keep it under control if possible). So basically, what is the best way to use the C++ code with the C# code? Right now, I'm thinking of three solutions
1- Compile the C++ as C++/CLI and directly use the classes and function from C#.
2- Compile and wrap the C++ in an unmanaged win32 dll and call it from C# using DllImport
3- Wrap the C++ in a COM wrapper and use the .NET COM Interop to link it with C#
Which one is the best way? Or, if there is a better solution, what is it?

C++/CLI has several restrictions over standard C++ that don't always make it easy to recompile standard C++ as C++/CLI. Keep in mind that you'll have to distinguish 'managed' and 'unmanaged' pointers, for starters. As these are using different symbols, you've got your first set of #ifdefs right there. And then you get to ref and value classes and all that sort of fun.
You can however use C++/CLI to bridge the gap between native code and the .NET world. The last time I did something along the lines of what you're planning to do, I used C++/CLI to write the bridging layer that did the necessary translation and conversion work between .NET types and classes and the native world. The C++/CLI layer can obviously be used from any .NET language.
You can't always use (2) - this depends very much on the data types you're trying to exchange between the two worlds. The .NET marshalling code is pretty good at dealing with C PODs but anything more complicated and you've got a problem.
(3) is overkill IMHO and introduces another point of failure, plus you're then doing .NET <-> COM <-> native instead of the simpler .NET <-> native if you created your own bridging code. Not to mention that you add complication to your code that won't benefit the other OS you're targeting, namely OS X.

Our development team has been using C++/CLI compiled code with ASP.NET and WPF front ends for while now.
The first major issue we had was build time. The code base would be 150k lines (40+ projects) and took forever to link (due to linker issues we could not build the individual projects as DLL's). We were only able to resolve this issue by wrapping the code with managed C++ classes and building our projects as assemblies.
The second major issue was performance. We originally compiled with /clr (before pure option existed) and this resulted in double thunking of most of our calls that occurred in the managed C++ layer. We fixed this by switching to /clr:pure. By doing so we ran into an
issue where our assemblies resulted in having too many 'global' methods in the assemblies so they would not load. We had to split our assemblies further to solve this issue.

Best and easier way is to do it with .NET <-> COM because COM has much stronger bridge compared to native dll access inside .NET because it may lead to lots of memory issues and lots of troubleshooting time. Its easier to test COM inside any MFC project and get the trace information for debugging and when the component is ready it can be easily used inside .NET.
CLI will not let you use all features and unfortunately its fairly new so less documentation is available and you will not get good support for your questions.
Win32 dll and DLLImport has problems mainly to troubleshoot, because the exception thrown inside Win32 dll will not travel further along the stack instead it will simply crash and you will not get the reason. Where else in COM you can catch exception internally and the COMException thrown inside .NET will not crash your entire application.
COM will be little slower in performance, but it will be more organized and good design pattern to develop.

Visual Studio 2008 - Sharing Data in C++/C# Multi Project Solution

I have a solution with 2 projects:
a c++ main project
a c# project (display simulator)
Today these 2 apps share data using a loopback TCP client/server connection, but that's not very optimal (timing issues..).
I was wondering if there was a way to access the c# data from the c++ project directly and vice versa? (It seems to be possible with 2 c# projects..)
If it's not possible, what's the best way to implement this with shared memory?
thanks!
Michael
EDIT: thanks for the answers. The 2 projects used to be independant solutions and are both executables - I'm actually trying to merge the 2 into 1 solution / executable.
For info: The c++ app is a PC version of an embedded app - the c# app is a lcd/HMI simulator.

Converting the C++ project to a C++/CLI project might be the easiest way to go. Note however that some code doesn't play well with C++/CLI (we've had problems using libraries that use boost::thread in a managed executable).

You can use COM Interop or Platform Invoke to access native code in C#.
If that's not what you're asking for, please elaborate.

Named Pipes?
For interprocess communication via named pipes you can check out the .NET 3.5 feature
http://msdn.microsoft.com/en-us/library/system.io.pipes.aspx for the C# side. From the C++ side, I assume you know the equivalent :).

There are two ways I know of to get direct access to memory between c++ and c# without the overhead of marshaling/demarshaling and com. If it is required to keep the c++ part of your code native then the only way I know to achieve this is to host the clr from your c++ application. A relatively complicated undertaking. Google "hosting the common language runtime". Then you can load your c# code as an assembly, call into the c# code and provide a common shared memory style interface. Although you will have to write all of the shared memory support yourself as I have found no direct support for shared memory in c#/.net.
The other way is to compile your c++ code with common language runtime support. This is by far easier and will allow you all the power and glory of c++ while allowing access to clr based data types, and the ability to call back and forth between your c++ and c# code. See "Language Features for Targeting the CLR" in your VS2008 documentation. pin_ptr will become your close friend and ally in this process.

Is it theoretically possible to access any library from C# (aka what does PInvoke do under the hood)?

Like a lot of places my workplace has legacy code floating around along with more modern applications. For example we have a server application that still uses the Microsoft Fortran77 compiler. The less old parts of the application are written for the Visual Studio 6 C compiler and lately there have been runours of writing some new libraries with VS .Net 2008 C++. The programs/libraries have a number of different mechanisms to consume/communicate each other including static linking, shared memory (Windows memory mapped files), name pipes and TCP sockets.
What's to stop a C# application from being able to use any old library such as one of the Fortran77 ones written in a procedural langauge?
If my C# application understood the file format of a Fortan77 or C library and was able to locate the procedure call it wanted could it marshal the managed objects across, call the procedure and unmarshal the result?
If I copied a .so library file from Linux to Windows and my C# application understood the file format could it call functions from that library?
I think the answers are to do with the various Fortran, C etc. runtimes that are needed to initialise each library/program. If that's so then at a fundamental level are those runtimes the broadly similar to the CLR (realising they have different features such as memory management etc. etc. in the CLR's case)?
Edit:
To put my question another way. If an alien dropped in and gave me a binary library file and a file format specification could I use it from C#?

If the DLLs are valid DLLs and the functions exported use well-known calling conventions, then there should be no problem as long as you get the method signature in .NET right i.e: correct argument types and return type. CLR doesn't (and can't) care what language was the library written in.
As for the Linux shared libraries, if you have the sources of the libraries, it should be possible to compile them for windows using either Cygwin or MiniGW.

I don't know about Fortan77 or .so library from Linux, but I do know that you can use PInvoike with C libraries for method calls. Also you may want to look at the unsafe keyword in C# for the shared memory applications. It allows you to drop out of memory management, which may be what you need. Named Pipes and TCP sockets can be done from the System.Net namespace.
Basically everything you have said can be done. I don't know how hard or easy it will be to accomplish, but you should be able to access all these native apps from your C# application.

You can also create a C++/CLI DLL (/CLR option when compiling) which will allow you to write both in managed and unmanaged code. This allows you to do just about anything you could do in native C++, and also interact with .NET components. I am doing something like this to bridge an old C application with a C# DLL by having the C++/CLI dll essentially sitting between them.