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.
Related
Currently we have couple projects that are written in Delphi 6. Because of specific components that use in these projects (components also written in Delphi 6) it is not easy to convert it in newer version.
As I prefer .NET development and our new products are developed in .NET, I would like to develop new functionalities using these technologies. C# will be programming language.
My question is: How to integrate new functionalities developed in C# with current code in Delphi? Is this good idea at all and what can be possible issues? If someone have similar experience it would be to hear advantages and disadvantages.
I heard for integration in way to develop .dll with C# and use it from Delphi code.
TnX in advance!
Nemanja
You can use COM (ActiveX) both ways.
So Yes, you can make a DLL in C# and mark it as COM-visible and import it into Delphi.
But you cannot use simple (not COM) DLLs this way.
My first port of call would probably be looking into WCF (written in C#) and have Delphi talk to it.
The dll is not a bad idea, but I just think putting it in WCF is more scalable + portable.
COM would probably be my choice. However, if for some reason you wanted to avoid COM you could take a look at the very nifty Unmanaged Exports by Robert Giesecke.
Unmanaged Exports is an MSBuild task that essentially allows you to export static functions from your .Net assemblies to be consumed as ordinary native DLL exports.
You may want to check out Hydra from RemObjects. It permits native and managed code to be used in the same application.
http://www.remobjects.com/hydra/default.aspx
I need to implement a class in C++ that can call a C# function from unmanaged C++ and return a value. I've done this from C++ to C++ using MIDL/RPC binding over named pipe which works great but now my server application is moving to C# but the client must remain unmanaged C++ (it's an explorer extension).
I've looked at various methods and lots of people suggest COM, it was my understanding that COM was not so much for IPC/RPC but for hosting a served object in a client app. Is this going to be possible with COM, if so, can anyone point me in the direction of a good reference or example?
EDIT:
Just to be clear, I cannot use managed code as the client (DLL) is loaded into Explorer's process space.
What I am trying to achieve is when the user right-clicks on a file the extension will ask a running service (session 0) for some details about the file. This was previously done via RPC in a C++ <-> C++ client/server. Now the server has been upgraded to C# but I'm not sure what my options are. Is COM an option?
Thanks,
J
Use mixed CLR and native C++ DLL. Check MSDN and tools.
Native and .NET Interoperability
I am starting work on a new project where the core product is a Software Library. There is existing code we will be wrapping, written in C++ because it is very numerically intensive; we own and compile this core code.
I believe we will have two prominent client types:
1. App written in C++, probably MFC
2. App written in C#.NET.
The Question: In order to offer an "ideal" interface to both these client types, what technology do we use? For example, we could offer two interfaces, one using C/C++ functions and callbacks for the C++ clients, and the other using C#.NET for the C# clients? Also, in principle, could this be done nicely in one DLL, or will we want two (or more)?
Other info... Client apps are embedded, not a desktop or laptop; assume any UI is not Windows-based. Also we will have to compile and test for both 32-bit and 64-bit, probably C++ on 32-bit and C# on 64-bit.
My apologies here -- I realize this question may have been asked and answered previously, but if so, I was not able to find it.
Interesting question, I'm looking forward to other answers.
One possible solution, if probably not the best: If your library code follows object-oriented practices, you could write the core functionality in C++ and then provide separate COM wrapper classes around the core classes (also in C++). This would allow you to use your library components from .NET via COM interop. I don't know how efficient that would be — I suspect performance should generally be fine —, and COM has some obvious drawbacks (no generics, for example), so that may not be the optimal solution.
If your library is not object-oriented, you can still call single functions exported from any DLL in .NET using P/Invoke... if you go down this route, it's likely that you'll end up with a C# wrapper around your C++ DLL.
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#.
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.