I have C++ Qt application together with a lot of .net C# assemblies, that I would need to use in the C++. Before doing any research I was expecting there is existing solution to generate C++/CLI wrapper DLL for usage in pure C++ app, but to my surprise I wasn't able to find anything except SharpCpp, but that's just experiment.
As the amount of classes that need to be exposed might be pretty extensive, I was looking for as much as automatic solution possible ( like what I'm used to when wrapping C++ for Python using shiboken)
As far as I can tell my possibilities are (as just compiling the app with /clr is not an option):
Manually write C++/CLI bridge DLLs, but this could take a lot of time.
use COM, but that would also mean a need to implement the COM exposure to all C# assemblies also. Or is there any automated solution?
use CLR Hosting. Not an option without automatic generation of the wrapper also.
try using something like Alter-Native or cs2cpp, but I don't know how much production ready this is.
So I was wondering, if someone was facing similar problem, and what turned out to be the best, and most maintainable solution.
Related
At the moment, I am working in a C++ environment. There are many in house programs, SDKs, and DLLs. What I want to know is, moving forward, would I be able to wrap that code into something C# could use? I'm still learning about wrapping code for other languages, and haven't found a decent source for going from C++ to C#.
As far as cross-language interop goes, the C#-C++ interop is actually quite usable. Check out the official documentation. "Managed" is Microsoft-speak for everything in the .NET runtime, i.e. your C# code; "unmanaged" or "native" means your C++ code.
Microsoft has extensions to C++ called C++/CLI that make it easier to build wrappers for .NET languages.
Good day,
I want to take an existing C# project and wrap functions into a C++/CLI DLL. I need to be able to read this DLL from VB 6. I choose this route because I won't have to register a .net DLL in order to use it with VB 6. Frankly I have no experience with this kind of thing so I would greatly appreciate a good example. I know there are plenty of similar questions like this but I haven't been able to find anything simple enough for me to understand.
This is a fairly unwise route to pursue, making C# code [ComVisible] is pretty trivial and Regasm.exe should not scare you. The usual mistake with Regasm is to forget to use its /codebase option on your dev machine.
If you insist on not taking advantage of this then you'll need to find a way to get the CLR loaded yourself so it can execute your C++/CLI and C# code. There are three basic ways to do so. You've written off COM interop and hosting the CLR yourself isn't very practical if the host app is VB6. You however can take advantage of the C++/CLI compiler's ability to generate unmanaged DLL entrypoint stubs that load the CLR for you and switches to managed code execution. Do so by writing a static function that you decorate with __declspec(dllexport). The technique is shown in this answer. Beware that it isn't particularly performant and you'll have to live with the restrictions imposed by the VB6 Declare statement.
Also check this post-processing tool that can inject these stubs directly into a C# assembly. Not sure how reliable it is, I haven't used it myself.
Be a man and make that DLL under a couple of different compilation/linking/function-call-protocol configurations. Then go ahead and try a couple of different referencing configurations in your VB6 project. Post what works. Contribute, go forth!
Take a look at Export Managed Code as Unmanaged
and C# Project Template for Unmanaged Exports
I have worked extensively with C#, however, I am starting a project where our client wishes all code to be written in C++ rather than C#. This project will be a mix between managed (.NET 4.0) and native C++. Being that I have always preferred C# to C++ for my .NET needs, I am wondering if there are any important differences I may not be aware of between using C# and managed C++?
Any insight into this is greatly appreciated.
EDIT Looking at Wikipedia for managed C++ code shows that the new specification is C++/CLI, and that "managed C++" is deprecated. Updated the title to reflect this.
C++/CLI is a full fledged .NET language, and just like other .NET languages it works very well in a managed context. Just as working with native calls in C# can be a pain interleaving native C++ and Managed C++ can lead to some issues. With that said, if you are working with a lot native C++ code I would prefer to use C++/CLI over C#. There are quite a few gotchas most of which could be covered by do not write C++/CLI as if your were writing C# nor write it as if you were writing native C++. It is its own thing.
I have worked on several C++/CLI projects and the approach I would take really depends on the exposure of different levels of the application to native C++ code. If the majority of core of the application is native and the integration point between the native and managed code is a little fuzzy then I would use C++/CLI throughout. The benefit of the control in the C++/CLI will outweigh its problems. If you do have clear interaction points that could be adapted or abstracted then I would strongly suggest the creation of a C++/CLI bridging layer with C# above and C++ below. The main reason for this is that tools for C# are just more mature and more ubiquitous than the corresponding tools for C++/CLI. With that said, the project I have been working on has been successful and was not the nightmare the other pointed to.
I would also make sure you understand why the client is headed in this direction. If the idea is that they have a bunch of C++ developers and they want to make it simpler for them to move to write managed code I would posit to the client that learning C# may be less challenging then learning C++/CLI.
If the client believes that C++/CLI is faster that is just incorrect as they all compile down to IL. However, if the client has a lot of existing or ongoing native C++ development then the current path may in fact be best.
I've done a project with C++/CLI and I have to say it was an abomination. Basically it was a WinForms application to manage employees, hockey games, trades between teams, calendars etc, etc...
So you can imagine the number of managed controls I had on my forms: calendars / date time pickers, combo boxes, grids etc.
The worst part was to use only C++ types for my back-end, and use the managed types for the front-end. First off you can't assign a std string to a managed string. You'll need to convert everything. Obviously you'll have to convert it back...
Every time I needed to fill a grid, I serialized my C++ collections to something like a vector<std::string>, retrieve that in my UI library and then looped trough that and made new DataGridRow to add them to the grid. Which obviously can be done in 3 minutes with C# and some Linq to SQL.
I ended up with A+ for that application but lets be honest it absolutely sucked. I just can't imagine how pathetic the others app were for me to get that.
I think it would've been easier if i used List<Customer>^ (managed List of some object) in my C++ instead of always converting everything between vectors of strings. But I needed to keep the C++ clean of managed stuff.
/pissedof
From using all three areas (.NET, C++/CLI and C++) I can say that in everyway I prefer using .NET (through C# or VB.NET). For applications you can use either WinForms or WPF (the latter of which I find far better - especially for applications that look far more user friendly).
A major issue with C++/CLI is that you don't have all the nice language features that you get in .NET. For example, the yield keyword in C# and the use of lambda (I don't think that's supported in C++/CLI - don't hold me to that).
There is, however, one big advantage of C++/CLI. That is that you can create a bridge to allow C# and C++ to communicate. I am currently working on a project whereby a lot of math calculations and algorithms have already been written (over many years) in C++, but the company is wanting to move to a .NET-based user interface. After researching into various solutions, I came to the conclusion that C++/CLI was far better for this. One benefit is that it allowed me to build an API that, for a .NET developer, looked and worked just like a .NET type.
For developing an application's front end, however, I would really not recommend C++/CLI. From a usability point of view (in terms of developer time when using it) it just isn't worth it. One big issue is that VS2010 dropped support for IntelliSense for C++/CLI in order to "improve general IntelliSense" (I think specifically for C++). If you haven't already tried it, I would definitely advise checking out WPF for applications.
I am developing a complex library in C++ and i plan on having a C interface so others can load up the DLL and easily access the lib. I haven't tried writing code in C# that access C code. I did a quick google and found code that uses a lot of attributes.
What can I do to keep my interface simple enough to not cause a headache trying to keep .NET in sync with it? Is there some kind of header generation tool i may use? Do i only use simple POD structs? I'm unsure how i should handle types as they are passed around as pointers. I am also thinking maybe i should avoid using anything that is a not an int/string or array.
I am developing it using MSVC but mostly using it with GCC. I know i should use the calling convention __stdcall. Beyond what i said i am totally clueless. I actually dont know how to load the DLL into .NET.
What can i do to ensure everything works correctly when writing my C lib and getting it to run with .NET?
Consider putting together a COM interface. Consuming COM from .NET is marginally easier than P/Invoke; at least you won't have to spell out prototypes for all functions in C#, the COM typelib importer will do that for you.
Currently, we are working on a C++ legacy code base, which consists of several software components.
One of the components, are written in a way that is extremely difficult to maintain. (For example, memory allocation is done in X place, but memory de-allocation is done in Y place. This make memory management a painful job). Till now, we able to solve (or workaround) all the memory leakage issues.
However, after several rounds of bug fixing, our feeling is that, due to the high maintenance cost of this software component, we are unable to go too far from current milestone.
I know it might be bad to rewrite the source code : http://www.joelonsoftware.com/articles/fog0000000069.html
However, instead of re-factor the current code, we forsee it will be better to re-write from scratch due to
Till now, no one in the team can fully understand that software component code.
The legacy software component is a small piece of software. 20k lines, I guess
Our teams are pretty clear on the requirement and what we are trying to achieve
Hence, we are planning to go for a managed code, at least make memory management a painless job. We plan to choose C#, as
All our C++ code are compiled using Microsoft VC++
We are using MFC, in other software components. (in DLL form) Every DLL, do have their very own resource.
I am from C++ and Java background, and know nothing much on C#.
How well C# to interface with MFC DLL, with some of the DLL functions will invoke MFC GUI?
Anything I need to pay attention on it?
Will the interfacing with legacy C++ DLLs be easier, if we are using Managed C++?
Thanks.
I am in a similar situation and I also did some experiments mixing C++ and C#. The problems in my application however were that:
the application is not clearly split up in different modules, making it hard to move specific modules from C++ to C#
the application is quite cpu-intensive and experiments revealed a big overhead in calls from C++ to C# or C# to C++
Additionally, you cannot call C# directly from native/unmanaged C++, which meant that I had to introduce an additional intermediate C++/CLI (or is this called C++.Net?) layer.
Therefore, I chose not to move to C#, but stay with C++.
So, if you want to move from C++ to C#, make sure:
that you have clearly separated modules
that the transition (calls) from C++ to C# or vice versa are in a place that is not used that often (so not during cpu-intensive tasks)
Additionally, remember that if you are not the sole developer of the project, that all (or most) of your developers should also learn C#. You don't want to delegate all C# code to your latest junior developer, because if he leaves, you will be (or could be) in trouble.
How well C# to interface with MFC DLL, with some of the DLL functions will invoke MFC GUI?
Not well at all. You can't P/Invoke to a C++ library -- it works with C exports only. You would need to write a wrapper exposing a C library interface for you to P/Invoke from C#, or you'd need to recompile MFC using C++/CLI. There's little reason to do this though as Winforms is a comparable library to MFC for .NET code.
Anything I need to pay attention on it?
I don't understand that question.
Will the interfacing with legacy C++ DLLs be easier, if we are using Managed C++?
Considering you can't do it using C#, yes. You'd have to recompile those C++ DLLs to have them expose a C interface, or you'd have to recompile them from source using C++/CLI.
Note: No matter what you do here, you're still going to have to worry about memory managment and object lifetime of anything going on inside native code. The CLI does not automatically manage native resources for you.