Basically I have a bunch of unmanaged VC++ static libraries. And the VC++ GUI application which uses those and it is based on MFC.
The goal is to replace the GUI app with the one done in C# instead but using all the same static libraries.
The question is if this even possible, and if yes, then what is the right way to accomplish that?
Suggestions, anybody?
Thanks.
Yes, it is possible using C++/CLI for managed C++ code. You would write a C++/CLI WinForms app and simply link in your static lib as per normal.
However, if there is a lot of tight coupling between the GUI code and the libraries then this can get a bit messy. You will need to worry about converting some data types between the managed and unmanaged world, particularly strings. If you need to pass managed objects/arrays
There is a good introduction on Wikipedia and lots of documentation on MSDN.
Rob is correct - you can do it in C++/CLI entirely, but we found it most useful to wrap some native classes in a managed WinForms User Control class. This managed class contained an instance of the native class, and not only marshalled data like strings in method calls, but also converted native callbacks (implemented with boost::signal) to .NET events. The whole solution for this signal-event translation is spelled out in this question. The .NET WinForms User Control also trapped native exceptions and re-threw them as managed exceptions, and also did some translation of non-.NET interface (methods returning iterators) to a more .NET-styled interface, which you can read about in this question. We were then able to use the .NET class directly in a WPF application. Note that if you wrap it as a .NET class it will have to go in a DLL to be used from C#.
Related
I'm a regular .NET developer aiming to integrate a C++ library into a .NET project. I have a few ideas, but since I'm new to C++ in general I don't know the limits of the technology I'm trying to work with. The C++ project is essentially a fast sound renderer that can playback multi-track audio files with a bunch of different postprocessing tricks. All of this is cool, but considering I have a simple .NET WinForms app I want to integrate with, things start to look messy.
Firstly, the C++ project has no .NET bindings or ActiveX/COM integration. Its a plain 'ol MS VC++ 9 project. If I am to work with the project in my .NET app I'll have to somehow interface with it, ie. create class instances, set properties, call methods, marshal data in and out, etc.
Secondly, its built to run as an independent Windows app and manages its own windows using the MS Windows API. This is fine, but somehow I need the .NET VM running in the background, managing the show and running all my C# code. I don't write C++ so I need to stick with C# to build an app around this lib.
Thirdly, whether I'm running in the same process as the C++ lib or not, I need a way to build/interface/debug these 2 separate apps as if they were one. I have no background in C++ programming except for the fact that I have written a couple C++ DLLs for high-performance data manipulation.
So, many questions and no idea how to start!
I can fully compile this lib and get it into a VC EXE, but how do I co-compile my .NET code into it? Or alternatively, how do I compile the C++ code into the .NET EXE so it runs within a managed environment? Note that it wasn't designed for this and may misbehave if I attempt to change too much.
The main problem is interfacing with it. How do I expose some C++ classes to be accessed from .NET? I know exactly which classes I need and I'll need only a couple dozen classes along with their relevant methods/properties to be available from .NET. I don't mind handwriting wrapper classes in .NET to help the .NET VM understand the class structure of the bytes transferred back and forth. I'm hoping I can directly work with C++ objects from a managed environment so most of my code can remain in .NET.
Even if I run it as an independant app, would I have to resort to sockets or something to communicate with it? This is the absolute worse case and I'll do anything to avoid this.
Any help or pointers are appreciated, I hope I made myself and my task at hand clear and that my questions are specific enough and answerable. Thanks for any help!
Edit: If I write wrapper classes or generate them, can I use P/Invoke to create class instances and call methods on them and have them run native C++ code in the background? Where will the memory for such C++ objects be stored and managed? Within the .NET heap or outside it?
You can write managed C++ (C++/CLI) wrapper to unmanaged C++ code. It would be the most flexible solution. Basically, you write a .NET assembly in C++, the assembly exposes managed classes which call your unmanaged code. Then you can reference this assembly from your C# projects.
There is a very basic article how to do that: http://www.windowsdevcenter.com/pub/a/dotnet/2004/03/29/mcpp_part3.html
This might be helpful as well:
http://www.multicoreconsulting.co.uk/blog/c-snippets/how-to-call-unmanaged-cplusplus-from-csharp/
And MSDN article .NET Programming in Visual C++.
Option 1
If you intend to use unmanaged C++ objects, it is probably better to write a managed wrapper in C++/CLI that has the same interface as the class that it's wrapping, but has a managed constructor and destructor to clean up the unmanaged resources. In C++/CLI you create unmanaged objects just like C++ that you have to delete yourself, or you can create managed objects with the gcnew keyword. The .NET facing side of the wrapper would take managed objects. The Native facing side of the wrapper could operate on all of the unmanaged data types that you already have.
For example, consider the unmanaged class Frobber. In C++/CLI, you would create a class called ManagedFrobber that would have all of the same methods as Frobber and contains a private instance of a Frobber. In the ManagedFrobber constructor, you would create your private Frobber instance. In the ManagedFrobber destructor, you would delete your private Frobber instance. Every method in your managed wrapper class would simply call methods on the private Frobber instance.
Option 2
If all you intend to call from the C++ world are c-style functions (static in the C# sense I guess), then P/Invoke is probably the way to go because then you don't have to worry about all of the nuances of a wrapper class. For example, if you pass an array from the Managed world into the Unmanaged world using a wrapper class, you have to worry about things like pinning the array in place so it doesn't get moved around by the .NET runtime while the managed world is messing around with it. With P/Invoke most of these nuances are handled for you.
Is it even possible to create GUI layer in C# and rest of application in C++? If I am not wrong one of antyvirus software had GUI made in Delphi. How it could be done ?
You have several options for doing it, including:
Use P/Invoke to call into the C++ DLL from C#.
Expose a COM interface from the native code, and call it from C# using COM interop.
Write a native Windows service and call into it from managed code.
Use C++/CLI to write a managed library in C++, which you can easily link to from C#.
If you're starting from scratch, option 4 is probably your best option. (Aside from just writing the whole thing in C#, that is.) The first three options all involve some additional wrangling and overhead, and probably aren't worth the hassle if you don't have a compelling reason such as needing to interact with an existing native library or having some need for a service-oriented architecture.
If you write your business logic in C++/CLI, and your UI in C#, it shouldn't be a problem. If you want to write in pure ANSI C++, you might have to write C++/CLI wrappers around the objects you want to expose to C#.
write the app logic in c++ dll, then use pinvoke from c# to talk to the dll.
See this answer. It seems to answer your problem
I need to add a new component to a C++ Win32 application (no CLR support) and I would like to implement the new component in C# and use WPF. This new component is basically a window with some controls, which I need to launch quickly from an option in the menu of the Win32 application. The new component and the existing application share some int values and both can modify these values and the other should be notified of changes.
What would be the best way to achieve this?
Thanks
If you want to do this without changing your C++ compilation you might look at calling the .NET assembly as via COM. MSDN describes how to expose .NET Framework Components to COM.
The way I've done this is basically:
Make a COM friendly class and interface in C#
Export the TLB from the DLL
GAC the DLL
Register the DLL using regasm.exe
import the TLB into my C++ code
CoCreateInstance using the __uuidof my C# class
However I haven't tried to do this with a UI component. If the WPF form is a modal dialog you should be OK. If not then I don't know if WPF will be happy with your message loop; you may need to give it a seperate thread so it can run its own loop.
Have you seen the MSDN docs on this subject?
A cursory read implies this is not possible without enabling /clr on your C++ code. if you are able to move to this model then the things you want seem do-able.
btw I would not implement update/signalling code on both sides of the managed/unmanaged boundary for your shared data. Decide where the data lives, and have that code provide a) thread-safe accessors and b) 'update event' wiring that are used by whoever needs to write the data and know about updates.
Check out Observer pattern for a description of how to implement notification to multiple consumers. This may be overkill for your case but useful background.
EDIT:
Until you get the two modules coresident, discussion of event notification design seems premature. If you really cannot build your native code with /clr then I don't see how your WPF component can be used without a separate process, and resulting complexity in interaction and performance hit. Can you re-implement this WPF functionality in native code?
On the other hand - if you plan on making more mods to this codebase, perhaps it's worth considering how hard it would be to port the native code to be /clr-ready. Inline assembler does not prevent use of /clr but it does make it harder, as I am sure you have seen here. My guess is that this would be less work than wiring up the WPF code externally.
The path of least resistance at this point may be to replicate your WPF component in native code. Long term taking the pain of converting your app to /clr may provide a better foundation though. Sorry there is no simple answer.
One way to achieve this is compile your C++ application as a C++/CLI application. Once it's a C++/CLI app, you can mix managed and native code easily, and even talk to managed components with ease.
Rather than mess with COM, I'd prefer to use C++/CLI as a glue layer - that does not require recompiling your entire app as C++/CLI.
That means:
Write the C# code you want.
Write a thin C++/CLI wrapper. This can reference (i.e. dynamically link) to the C# app. All it does is expose a native API around the .NET API. It takes some getting used to, but you can do pretty complex stuff here, including fairly fancy automagic interop via marshal_as. You'll compile this into a dll - a mixed mode DLL.
Your main app now links dynamically to the mixed mode DLL and includes the headers for its API. It can call functions as usual.
This is quite a bit nicer that COM, I think: it doesn't require the GAC, it has a lower overhead should performance ever matter, and exchanging complex datastructures including callbacks & deep object graphs is possible (though there is a learning curve here) quite cleanly by adding custom marshal_as templates/overloads.
I was wondering if I can use a library -written in C++- in C#
The problem is that library has its own structures and classes..
Will I be able to use it in C#?
Thanks
EDIT This library is open source..
so if my requirements needs something special in C++ code, I will be able do it...
You cannot directly use C++ classes in managed code. The chief problems are not being able to use the same memory allocator as used by the C++ code and not being able to invoke the constructor and destructor easily. A Microsoft employee posted a blog post to show that it is not impossible. I would not recommend doing this.
COM is a solution but that invariably requires a fairly big rewrite and good COM programming skillz. A managed class wrapper in the C++/CLI language is usually the best solution. You could take a peek at the SWIG tool to consider auto-generating those wrapper classes. Beware however that this tool can easily create more problems than it solves.
There are two ways, both using an Adapter (which maps C++ classes to .NET classes):
C++/CLI
COM
The former avoids going via COM, and much of the C++ code might be able to be just compiled with the correct switches.
Additional: In theory P/Invoke might be possible, but all the C++ semantics would be lost, you would need to handle C++ object lifetime manually (and instance references as IntPtr). Plus of course you would need to call the mangled names...
Another option is to write a managed wrapper in C++/CLI. I prefer that instead of using P/Invoke.
Is it possible to share references to C# objects between C# and C++ code without massive complexity? Or is this generally considered a bad idea?
The best solution for sharing a C# object between native and managed code is to use COM interop. This allows you to essentially share an interface of an object between managed code and it's equivalent signature in C++.
As for the complexity side of things. The majority of COM interop scenarios are straight forward and really are no more complex than good old COM programming. On the managed side it looks really no different than a normal interface.
Once you introduce multiple threads or start playing around between COM apartments though, things can get a bit tricky.
In my experience, the easiest way to get this working is the following.
Define an interface in C# that you wish to use in C++
Mark the interface with the ComVisible(true) attrbute
Run tlbexp on the assembly which generates a TLB file
Import the TLB into your native project
This will get the interface definition into both of your projects. How to pass that between the projects requires a bit more detail into your architecture.
Another solution I can recommend, from personal experience, is to use a managed C++ interface between the two if the C++ code you want to access is too large or too complex.
For example, I am using the RakNet C++ network library in a C# project. The solutions are to either create a massive wrapper class in C# to access the required C++ functions, create a C++ wrapper around those functions which can than be used as a COM interop or use Managed C++ (Visual C++/CLI).
I chose the latter which allows me to use C++ to access the RakNet library, but the classes created can be used directly in another .NET project as if. So the main logic has been created in those Managed C++ classes, which also allow me to use the .NET framework and some of its wonderful features. In my C# project I simply need to call the Managed C++ library which provides me with all in all 20 functions I need to perform everything.