I've seen that NetNamedPipeBinding exists in C# and in C++ (source) and I would like to know if it's possible to use it to transmit datas between a C++ program and a C# application?
There's a good example here showing how to do IPC (Inter-Process Communication) between C++ and C#.
http://www.codeproject.com/Articles/34073/Inter-Process-Communication-IPC-Introduction-and-S
If your C++ compiler is a recent version of Visual C++, with all the extensions to support writing managed code, then you can use WCF easily to pass data between a C++ program and a C# application.
If your C++ compiler doesn't support managed code extensions, you can still do it but it is a lot of work, because the WCF channel stack uses some layered proprietary protocols for message framing, security negotiation and message encoding, which you would need to reimplement on the C++ side if you can't use the managed implementation provided by WCF. See for example this question for the kind of issues which arise.
If you can't do managed C++ it is often much easier to forego some of the benefits provided by WCF and, depending on your requirements, either to:
use a managed COM-visible wrapper around a C# WCF service, consumed as a COM server in the C++ code; or
roll your own IPC mechansim using a named pipe directly, calling the WIn32 APIs on the C++ side and using the System.IO.Pipes types on the C# side.
Related
I want to use both C++ and C# in my application.
C# for GUI design and C++ for processing.
But I don't have any knowledge about this. How to communicate between them.
I don't know where I have to begin and research.
Someone can tell me the overview about this technology? And if someone have document about this topic, please give it to me.
I'm using Visual Studio 2010 for development.
Many thanks,
T&TGroup
The technology you are looking for is C++/CLI, a proprietary language extension for C++, that allows interaction with .Net code.
The basic idea is this: You write your C++ libraries as ever in portable ISO C++. Then you add a thin wrapper in C++/CLI for those C++ components you want to call from C# (or any other .Net language for that matter).
Just be aware that C++/CLI is only intended to write code for interaction with .Net. Don't be tempted to write the implementation in CLI as well, as you will end up with code that is not portable and probably a lot harder to maintain than the pure C++ version.
It depends on what the architecture of your application should be, you can for example create two different application one that is the core and another that is the GUI and communicate through messaging.
On Windows you can use Windows message queue for example, to let the two end point communicate with each other.
You can either use C++ CLI or native C++. C++ CLI is managed code and native c++ will be unmanaged by the CLR. The choice between the two depends on your usage. There are certain limitations with C++ CLI.
It depends totally on the architecture and requirement as well. You can write processing instructions in C++ (lib) use them in GUI. Can be done in VS 2010 as well easily
I have some WCF services running over HTTP and a C++ client using gSOAP to consume them. This works, but we are considering running the service host in the same process as the client, to create a fully local stack.
What is the best way to allow the C++ client to consume these services? Do we still need to use HTTP binding? Or will something like named pipes or NullTransport work? Preferably something that will work with gSOAP or something that we can replace gSOAP with.
if both are in the same process then have them "talk" to each other via direct means. i.e. accessing objects directly. otherwise going over a comms layer is extremely expensive. the same can be said for accessing files on your hard drive via a network share when really going file say c:\foo\something.txt is more productive.
c++ allows you to construct CLR types that are both native code but also CLR-aware. using this technique allows your c++.NET type so to speak from .NET proper. your .NET types will have no idea that they are invoking c++ or vice versa.
have a look in your c++ compiler settings for CLR
We've written a Java program which we are looking to use and interact with from C#. What are our options? Optimally it would be possible to compile the Java application as a library (.DLL) that we could reference from C# perhaps using P/Invoke. This, however, doesn't appear to be an option according to the first few searches online.
We opt to be able to use ASP.NET to built a search engine powered by the Java code, so if this opens up for any other options please let us know.
Sorry, you cannot call java code / classes Directly from C# code.
One way of doing this is to wrap up your java classes in a java Web Service and call classes indirectly through that web service interface in your C# code.
Another way is using
javareg.exe which exposes java classes as COM. You can find it at following location:
C:\Program Files\Microsoft VisualStudio\VIntDev98\bin\javareg.exe
Following posts might help as well
Calling Java Classes Directly from
.NET (uses runtime bridge)
Calling Java from Microsoft.NET
The simplest approach would probably be to publish the functionality of your java library as web services and add a web-reference from your asp.net application.
Java isn't meant to be embedded in another program, so you need a bridge. The most simple solution is to use a socket: Create a Java process which listens for commands on a socket. In the C#, send the commands to the socket and read the answers.
The main problem here is serialization but if you use XML, it's not such a big pain anymore. Try the built-in XML serialization (see this article) or custom frameworks like XStream or Simple.
It is certainly possible to wrap Java in a .dll, and has been a part of the core Java platform for over 10 years. JNI (Java Native Interface) has an interface for embedding a JVM in your code, meaning you can run Java classes using C-style linking. Note that this will require that you write a simple C wrapper, there are samples within:
http://java.sun.com/docs/books/jni/html/invoke.html#11202
As some of these other posts suggest, sometimes it's desirable to be less tightly coupled, so you may want to consider using another design. One option would be a simple database, where the Java application regularly polls for requests from the C# code. If you want tighter coupling, for things like call-backs, you can look at distributed interfaces.
I have some .dll native C++ programs which mainly return int/double values, array structures and string values. These values should be taken by a Web Service program made in C#.
I would like to know if it is really necessary to modify my C++ programs and adapt to Web service, i.e. return values such as a XML string/file together with a XSD string,/file. Personally I think I should not modify them because I think C# can receive C++ values using interop and easily serialize using components of .Net library.
However, I would like to receive comments about the best, fast and effective way to pass C++ values to a Web Service.
Thanks!!
I think you can do it as you stated.
In the past, I achieved the same or similar by writing a C++/CLI wrapper around my native classes and consumed those from C#. This didn't incur the overhead of C# interop, which I've noticed can be quite expensive.
I think P/Invoke is what you want here. It will allow you to pass your simple and composite types between managed and unmanaged code, and you won't have to write any C++/CLI wrapper assemblies.
This (MSDN) is a good start for P/Invoke. If you scroll down here's a section called 'Specifying Custom Marshaling for User-Defined Structs'. This will allow you to pass your user-defined structs back and forth.
Look up MarshallAs and you can see all the primitive native types you can marshall. The DllImport attribute is something you will want to search for as well.
If performance becomes an issue, I would recommend serializing/deserializing into either named pipes or a local socket, but I'm not totally clear on the performance chararistics there. Good Luck!
The best, fastest, most efficient and effective way to expose your C++ application as a web service is to put C++ web service code on top of it.
See GSoap for a very fast, open source, implementation - one that is 3-5 times faster than the .NET and Java equivalents.
As long as you can return it to C#, C# should be able to return it from a web service. You should not have to do any manual serialization at all.
If you choose to go the serialization route you might want to look at 'thrift' (http://incubator.apache.org/thrift/).
From the website:
Thrift is a software framework for
scalable cross-language services
development. It combines a software
stack with a code generation engine to
build services that work efficiently
and seamlessly between C++, Java,
Python, PHP, Ruby, Erlang, Perl,
Haskell, C#, Cocoa, Smalltalk, and
OCaml.
Originally developed at Facebook,
Thrift was open sourced in April 2007
and entered the Apache Incubator in
May, 2008.
I have a C++ Windows application that can be extended by writing C++ plugins, using an API that is exposed by the application. There is also one plugin that translates the C++ API to Python (e.g. plugins can be written in Python).
I want to allow users to write plugins in C# in addition to C++ and Python. Since I'm not very familiar with the .NET world, I'm not sure how to implement the C# plugin system.
What would you recommend to use for this kind of plugin system (host is C++, plugins in C#)? What do I need to learn in order to achieve this?
There are a couple of prior posts that may help you out:
Interfacing using a simple API
Communicating between C++ and C# via DLL interface
Expose your API using COM objects and interfaces and you'll open up your application to many development environments, including C#.
Actually as well as the COM suggestions. If you really want to add 1st class .NET plugin support, its possible to host your own CLR process. There is a very interesting article here about it.
http://msdn.microsoft.com/en-us/magazine/cc163567.aspx
I've done this in various ways in the past. I found that C++/CLI was the best option for building a bridge between .Net and unmanaged C++ (though, as noted by other posters, COM in another option).
The ways I've done this in the past include:
Generating C++/CLI API wrapper code from my C++ API using reflection. Of course, native C++ has no reflection system, so we rolled our own. The generated C++/CLI code was then compiled into an assembly that the C# plugin would reference.
Generating a Dynamic Assembly from my C++ API using reflection (ie, using the Reflection.Emit stuff). The resulting assembly could be used in-process for scripting languages or you could even compile C# code against it at runtime. The assembly could even be written to disk to be used statically. The downside here is that you probably can't emit better IL than a compiler, so unless you need the dynamic generation, don't go down this path.
Hand written C++/CLI API wrappers. If the API is not very large, writing a wrapper by hand is easy enough.
In the end you will have an assembly for C# plugins to compile against. Now you need to load the plugin assemblies at runtime. To do this you must host the CLR.
Hosting the CLR is not difficult, though I've only done it once and that was a number of years ago - perhaps times have changed. If you are not comfortable with hosting the CLR, then push as muc hof your app code as possible into DLLs and then write a small C++/CLI app that brings up your unmanaged UI. Now the CLR is hosted by the small C++/CLI app.