We have COM dll which was written in C++ and has been used by the apps written in vb 6.0. My company plans write the newer versions of apps in .Net platform.
As far as the performance is concerned, when using a COM dll in a C# project, what should I choose from the 3 options listed below
Just adding the dll as a com reference
Writing a wrapper dll with C++/Cli
Generating a wrapper dll using TlbImp.exe
Or are there any other options?
Thanks.
Writing a wrapper in C++/CLI isn't that likely to be faster, the COM interop marshaller in the CLR is heavily optimized. It auto-generates machine code stubs from the interop library that you create when you add a reference to the COM server. A does a lot more work that's pretty invisible and very hard to do yourself, related to exceptions.
It makes sure that failure HRESULTs are properly converted to managed exceptions and that managed exceptions cannot leak into the COM server code. The "make it fast" resolve you'll have when you do this will make you cut corners like this. Now you've got something that's fast but unreliable. Getting a managed exception in unmanaged code is brutally hard to diagnose, all the context is gone.
Options 1 and 3 are the same thing. Both generate the interop library, the IDE simply runs the equivalent of Tlbimp for you.
The usual guidance applies here. Do the simple thing first, the interop library is incredibly simple. Only contemplate doing the really hard thing when you can actually measure perf problems and have a realistic idea what to do about it. I've never once seen anybody decide that a C++/CLI wrapper was necessary.
Option 2 is more performant, but not much, especially considering the DLL itself is in VB6.
Not sure if option 3 works at all.
I would personally use option 1, but just keep the interop somewhere safe so that I just keep reusing the same interop and not creating it everytime I add the reference.
Another option is to use new dynamic features and late binding (using Activator to create the object) but that is definitely less performant of all.
Since the component is using COM, it will be easiest to add it as a reference and let visual studio build the proxies. This will be very strait forward and transparent to the .net code. It will not be quite as performant, but most likely it will suit your needs. I would do this first, since it is so easy, and then see how it performs.
If the component was not a COM component, and just a standard c++ dll, then the other two method would probably be a better choice.
A call to COM is slow because of the marshalling of the data. With slow I mean, compared to a call where you do not cross a Managed or COM boundary.
If you need to do a lot of small calls to your COM component, in a performance critical piece of your application, you could wrap (and combine) them with C++.
If the number of calls is minimal, or when they are not performance critical (but aren't all calls performance critical?) I would simply add a reference to the COM dll.
Summary Go for the refence to the COM dll, and test the performance. Since you migrate from VB6, you will get an enourmous performance boost already (string handling in .Net is sooooo much faster).
Related
We have a large project mainly written in C# (services, multithreading etc.). However, the core number crunching algorithms are written in unmanaged C++ to be fast (OpenMP etc.).
Unfortunately, at the moment we have to do a lot of effort to exchange data between these two worlds. I.e., we have to write wrapping classes in C++/CLI for each of the C++ classes. For (virtually) any required setting (Properties) in the C#-"world" there is a copy in the C++ world (a header file) and an explicit conversion back and forth in the wrapper class. This architecture seems very inefficient and quite error-prone.
Primary question:
Is there a way to share a C#-class with properties somehow automatically in unmanaged C++? (we have to read and write!)
Secondary question:
Could you give any advice of how to improve the architecture in a case as described above. One consideration of ours was to completely switch to C++, but having to find appropriate libraries and write clean code for all the (system-)things we do in .NET at the moment does not feel good.
Many thanks for your help and best regards,
Jakob
I am dealing with similar issues at my work where my primary task is to write managed interfaces to certain high perfromance, low latency dlls, this involves simple cases where I have to wrap the native classes using simple c++/cli containing a raw pointer to the native class or more complex issues where the native code is a server side publisher and the managed code has to subscribe to it using delegates ie they have to be converted to native callbacks.
.NET under the hood is a sophisticated COM server as far as I know. It is possible to write .net assemblies with the ComVisible attribute set to true then it acts as a classic COM component and then it is possible to use it from the native C++ code as a COM component. The reverse that is to use native code from managed can be achieved using the DllImport attributes and all the Marshaling can be fine tuned by the various attributes like the StructLayoutAttribute (http://msdn.microsoft.com/en-us/library/system.runtime.interopservices.structlayoutattribute.aspx) and the MarshalAsAttribute (http://msdn.microsoft.com/en-us/library/system.runtime.interopservices.marshalasattribute.aspx)
I am also using sometimes the unsafe keyword as well. I have to deal with high performance code so in some cases it is that after profiling that I know which is the best solution. Whether it is the warpper class solution that you have mentioned or the classic COM way, or some kind of hybrid with some caching, object pooling etc.
Hope that helps. :)
Apologies if that looks a bit disorganised. It is very late here. :)
a common example to illustrate the benefits of DLR is to use it with legacy components such as COM and having the ability to call methods that are not visible at compile time.
is the point of this to skip the COM Interop step? Because once the component has been Regasm'd the compiler will have the metadata.
and let's say we do skip the Interop step, any changes to COM signature (that is used by .net) will still require re-compilation.
if i had to make another guess, the DLR also provides caching of the calls, so any subsequent calls should be faster than those using regular reflection.. so maybe that's one benefit of the DLR here.. but syntactically i'm just not seeing it..
is the point of this to skip the COM Interop step?
Not, it just simplifies the calling of methods which could be quite a pain with Reflection. No matter whether you use Reflection or C# 4.0 dynamic, both use Interop to communicate with the unmanaged code.
and let's say we do skip the Interop step, any changes to COM
signature (that is used by .net) will still require re-compilation.
It depends. If you rename a COM method you will need to recompile the .NET calling code because it will break at runtime when you attempt to call an non-existing method.
It is specifically useful to interop with latebound COM. The kind where you don't add a reference to a COM type library or PIA. Very painful to do in C# before the dynamic keyword became available, it requires reflection code. If you have a type library then you almost always want to use it since it is a lot faster, catches mistakes at compile time and supports IntelliSense. The only reason you would not want to use one is when you try to make your code flexible enough to handle different versions of the COM server. It is however quite risky with a runtime exception always around the corner to ruin your day. It is in fact rare to not have a type library, almost all COM component authors provide one since the advantages are so great.
Regasm is the exact opposite, you only use that when you write your own [ComVisible] server in C#. There's no benefit to dynamic then.
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.
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.
I'm trying to understand my options for calling a C# library implementation from unmanaged C++.
My top level module is an unmanaged C++ COM/ATL dll. I would like to integrate functionality of an existing managed C# dll. I have, and can recompile the source for both libraries.
I understand from reading articles like this overview on MSDN and this SO question that it might be possible to create a "mixed-mode" dll which allows the native C++ code to call into the C# library.
I have a couple of questions about this approach:
How do I go about setting this up?
Can I simply change some properties
on the existing COM/ATL project to
allow use of the C# modules?
How will these mixed-mode calls
differ in performance from COM interop
calls? Is there a common string
format that may be used to prevent
conversion or deep copies between
the modules?
If this dll is created
mixed-mode, can it still be
interfaced/used in the same way by
its COM clients, or do they need to
be mixed mode aware?
Will inclusion of the CLR impose substantial
overhead when loading this COM object?
I'm new to Windows development, so please comment if anything in the question statement needs clarification or correction.
Thanks in advance.
How do I go about setting this up? Can I simply change some properties on the existing COM/ATL project to allow use of the C# modules?
If you fully control that project, so changing such settings isn't an issue, then sure. All you need is to enable /clr for this project (In project properties, open the "General" page, and look for "Common Language Runtime" support). Now you can use managed handles (^) and other C++/CLI bits in your project as needed. All existing code written in plain C++ should just keep working (it will be compiled to MSIL now, inasmuch as possible, but its semantics will remain unchanged).
How will these mixed-mode calls differ in performance from COM interop calls? Is there a common string format that may be used to prevent conversion or deep copies between the modules?
A mixed-mode call will be faster, because it uses faster calling conventions, and doesn't do any marshaling the way COM interop does (you either use types that are inherently compatible, or do your own explicit conversions).
There's no common string format - the problem is that System::String both allocates and owns its buffer, and also requires it to be immutable; so you can't create a buffer yourself and then wrap it as String, or create a String and then use it as a buffer to output text to.
If this dll is created mixed-mode, can it still be interfaced/used in the same way by its COM clients, or do they need to be mixed mode aware?
It can be interfaced the same, but if it's entered via an native entry point, it will try to load the CLR into the process, unless one is already loaded. If the calling client had already loaded CLR prior to the call (or the client was itself called from managed code), then you'll get the CLR that is already loaded, which may be different from the CLR that your code requires (e.g. client may have loaded 1.1, and your code needs 2.0).
Will inclusion of the CLR impose substantial overhead when loading this COM object?
It depends on what you define by overhead. Code size? Runtime penalties? Memory footprint?
In any case, loading the CLR means that you get all the GC and JIT machinery. Those aren't cheap. That said, if you need to call managed code ultimately anyways, there's no way around this - you will have to load CLR into some process to do this. The penalties aren't going to differ between COM Interop and mixed-mode C++/CLI assemblies.
I can't say much about the details like e.g. the string issues, since I never actively used this approach.
But you can easily consume any COM interface from any C# code by simply letting a VS wizard create a proxy for you, there is no performance overhead to it except the one that you always have when invoking COM and .NET.
The other direction, you just have to set your C# assemblies' ComVisibleAttribute to true (in VS it's a simple check box in the project properties), and then the compiler will automatically create COM interfaces for you. Again, there's no additional performance penalty.
HTH!