legacy to managed RRS feed

  • General discussion

  • I have a typical architecture related doubt. The following lines will depict the picture


    Product A Framework => Legacy code(written in VC++ 6.0 ATL),

    Product B Framework => Written in WCF.

    There are two approaches.

    1. Create a wrapper service in WCF(which will talk to Product B), consume it from product A and vice versa

    2. Create a general C++ dll(which will talk to Product B), consume it from Product A and vice versa


    Any insights on this? or even another solution which might ease the development at product A???

    Wednesday, June 15, 2011 10:53 AM

All replies

  • You have two products that need to talk to eachother? Are they both installed on the same machine? Are they running in the same process?
    Richard Blewett, thinktecture -
    Twitter: richardblewett
    Wednesday, June 15, 2011 11:19 AM
  • Its an interesting situation. There could be additional approaches as

    1. Exposing product A Framework as service

    2. Exploring possibility of converting VC++ to managed C++

    The criterias for making a choice could be

    1. Which framework has more usage?

    2. Dependecies among them

    3.Marshalling overheads not eating up the benefits of legacy application

    4. Existing Interoperability and future interoperability - any unmnaged clients still in force

    5. Time and money investment for reengineering the legacy applications

    6. Performance and scalabity considerations

    7. Available skillset

    8.Modifiabilty and changebility, extensibility considerations

    Hope this helps.

    Please mark this as "Answer" or "Vote as helpful" if it has resolved your issue/question/problem.

    • Edited by Vishvvas Wednesday, June 15, 2011 11:22 AM Editing
    Wednesday, June 15, 2011 11:21 AM
  • Yes, currently the two products A & B will be installed on the same machine. However, they might be distributed to different machines also!

    The communication shall be bi-directional i.e. A(VC6.0 ATL)<--->B(WCF).


    Both are completely different products, but the their background concept is same.

    Wednesday, June 15, 2011 12:04 PM
  • 1 & 2.These two options are ruled out since it is not possible to convert to a SOA/Managed C++. Another reason would be Product A will be replaced by Product B in near future.

    All other points mentioned by you are fair enough to make a decision about the tech.


    However, which method would you prefer among the 2methods  mentioned in my original post!!!

    Wednesday, June 15, 2011 1:54 PM
  • So Product A is going to sunset. Then I would vote for approach 1 as it will consume minimal effort and the service wrapper would be resusable too. But as mentioned in approach 2, it would consume far more efforts for C++ dll and any way it would need to be thrown out too.

    Hope this helps.

    Please mark this as "Answer" or "Vote as helpful" if it has resolved your issue/question/problem.
    Wednesday, June 15, 2011 3:00 PM
  • @Vishvvas:

    Do you for see any technical difficulties which might arise with option 1 & 2. What kind of precautions we might need to take care during those options dev???

    Thursday, June 16, 2011 2:41 AM
  • As you identified: putting a WCF facade in front of the ATL product product would be the best approach ongoing. Two things to bear in mind:

    1) I assume you will be using COM Interop for the service to talk to the product. You have to be very careful about lifetime management with COM interop because COM and .NET and different and conflicting lifetime management models. Judicious use of Marshal.ReleaseCOMObject and explicit breaking of circular references are critical. If you can get away with using standard DLL imports rather than COM interop I'd go that route as the model is generally alot simpler and less error prone

    2) You will also need to provide a COM exposed WCF proxy for Product A to talk to Product B - again beware of COM interop issues 

    Richard Blewett, thinktecture -
    Twitter: richardblewett
    Thursday, June 16, 2011 9:12 AM