The existing product is based on C++. The C++ client calls into a COM DLL to obtain object references and perform necessary processing.
The customer expects both the C++ client side and the C++ based COM DLL implementation to be migrated to .NET. (Note - the complete source code on both client and COM must be migrated - no use of RCW etc.)
In such a situation is there a direct need for considering the concept of IUnknown when migrated to .NET ?
Please let me know various other considerations while performing the migration. (The C++ COM based DLL is now expected to be a simple .NET based DLL)
In such a situation is there a direct need for considering the concept of IUnknown when migrated to .NET ?
Based on your original post my answer would be no. The only reason you would do that is if you were to have unmanaged clients for your .NET component/dll. With regards to other considerations...I would say you need to think of it as re-writing the component rather than migrating...
Nelo is correct. I would also add that you can add a reference to a COM visible component in a .NET assembly and use the types as you would any others. Is there really a good business case for rewriting the entire DLL? Why not just use it in the new .NET client app as-is?
If you liked my post go ahead and give me an upvote so that my epee.... ahem, reputation will grow.
The C++ client calls into a COM DLL to obtain object references and perform necessary processing.
To me this suggets that it might be better to have both sides either managed or unmanaged. One would expect a performance hit every time the managed/unmanaged boundary was crossed. This may not be the case in this particular scenario so BigEd781's suggestion may be the best until it is categorically proven that the system is responding more slowly as a result of the interactions across the CRL boundary.
Is there really a good business case for rewriting the entire DLL? Why not just use it in the new .NET client app as-is?
The customer wants everything on the managed platform because of lessened development and maintenance complexity. Besides, they visualize some updates in the component (that is now C++ COM) in future and would like to have it in C# to make work easier.
The customer wants everything on the managed platform because of lessened development and maintenance complexity. Besides, they visualize some updates in the component (that is now C++ COM) in future and would like to have it in C# to make work easier.
Well...if the functinality is not complex that seems like a valid argument. On the other hand the level of difficulty depends on the people working on it. I guess the assumption is that in the long run you are more likely to find C#/.NET developers as opposed to C++ COM developers...
There is this X.dll(native) which is implemented complete in C++ and needs to be migrated/re-coded in C#.NET.
Now, X.dll(native) uses a static C++ library called Y.lib as part of it's compilation and link process.
Y.lib is a third party static library and the only information that we have available is nothing but the .lib file and it's header file (.h).
From the .h file, we realize that Y.lib actually implements some classes which are being used in the code that compiles to form X.dll(native).
Given that X.dll(native) needs to be rewritten in C#. NET, how would you tackle the problem of including Y.lib in the C# .NET implementation. (Remember, we do not have the code for Y.lib)
One Solution - Write a wrapper COM based DLL around Y.lib and uses the classes in Y.lib via the COM interface. Generate a TLB and import it in the C# based implementation of X.dll(managed).
You have a few options - but all involve C++ - how good is your C++ ?
Firstly you can write a C++/CLI dll which links with the .lib file and presents a .NET interface to it.
Secondly you can write a pure native C++ dll and expose __declspec(dllexport) methods which interface to the .lib functionality. Then use p/invoke (platform invoke) to call into the dll.
Personally I wouldn't use COM for this - mainly because of
(1) Installation issues (all those registry keys...)
(2) COM isn't out-of-the-box side-by-side (although you can get side by side COM these days...)
(3) Speed - translating from .NET types to COM types to C++ types and back again.
My personal preference is (2) i.e. have a pure native C++ dll which you p/invoke into. Mainly because I like having the native and managed parts completely separate.
However C++/CLI is a language which was designed to help you do just this sort of thing so you should definately consider that.
Darwen.
www.pinvoker.com - PInvoker - the .NET PInvoke Interface Exporter for C++ Dlls.
My personal preference is (2) i.e. have a pure native C++ dll which you p/invoke into. Mainly because I like having the native and managed parts completely separate.
Darwen, the problem is that Y.lib currently implements a class and not just functions. If it were functions, then it would make sense to create a pure native C++ dll as you have mentioned.
But, the code in X.dll(native) instantiates instances of the class implemented in Y.lib which I suppose rules out use of PInvoke.
Are you sure that Y.dll exports classes and not just functions?
Arjay, currently we do not have a Y.dll yet. (Y.dll is a solution that I am proposing to help .NET interface)
Currently, we have a Y.lib (which is a static library) which implements a class. There are no C style function interfaces implemented in Y.lib.
The C# implementation of X.dll (managed) should be able to instantiate and use the class implemented currently in Y.lib somehow (we cannot rewrite Y.lib in C# as we do not have access to the code).
Managed to implement a C++/CLI wrapper (by including the static library). The wrapper class is now accessing from C#.
I have attached the solution here with the following information :
MyLib - Native C++ static library
Managed - C++/CLI Wrapper
ManagedCodeClient - C# code accessing C++/CLI reference DLL
Though this is a sample workspace, the actual Native C++ library implements a class whose public interfaces take std containers like list, multimaps and also istream, ostream etc. as parameters.
Considering the flow of a call to the final implementation, from C# to C++/CLI and then to the native C++ implementation, this seems to be a tremendous performance overhead - that will anyway need to be absorbed.
Wondering how a C# stream can ultimately be mapped to a std::istream parameter ?
* The Best Reasons to Target Windows 8
Learn some of the best reasons why you should seriously consider bringing your Android mobile development expertise to bear on the Windows 8 platform.
Reply With Quote
Originally Posted by humble_learner
