none
GENERAL QUESTION: ATL/COM vs C++/CLI for building Office Add-Ins RRS feed

  • Question

  • I have a lot of experience writing Add-ins using ATL/COM.  However, that was under 2010 and earlier releases of Office.

    How does writing an Office Add-In using Managed C++ compare with using ATL/COM C++?

    I'm currently researching a project that doesn't seem to require any .NET; just accessing and manipulating the COM objects in Outlook (e.g. Appointments, Meetings, MailItems).

    I'm looking for responses based on practical experience instead of theoretical answers based on articles.

    (Note:  C# will not be used)


    • Edited by GermanEZI Tuesday, September 5, 2017 2:58 AM Clarification
    Tuesday, September 5, 2017 1:54 AM

Answers

  • This thread is beginning to drift a bit from my original question.

    I'll just go ahead with ATL/COM C++  since I don't see any objections to it in here.
    • Marked as answer by GermanEZI Wednesday, September 13, 2017 7:44 PM
    Wednesday, September 13, 2017 7:44 PM

All replies

  • Just out of curiosity, if unmanaged C++ is not an option, why did you decide to use managed C++ instead of C# unless you have tons of existing C++ code that you will need to use in your addin?

    Dmitry Streblechenko (MVP)
    http://www.dimastr.com/redemption
    Redemption - what the Outlook
    Object Model should have been
    Version 5.5 is now available!

    Tuesday, September 5, 2017 4:15 AM
  • Unmanaged c++ is my Preference.   It's C# that's not the option.
    • Edited by GermanEZI Tuesday, September 5, 2017 5:38 AM clarification
    Tuesday, September 5, 2017 5:37 AM
  • Hi GermánH,

    it depends upon your requirement.

    you can try to check which one is most suitable for your project.

    we don't have any idea about your project.

    if you try to post your requirement then we can try to check it and try to provide suggestion based on that.

    Regards

    Deepak


    MSDN Community Support
    Please remember to click "Mark as Answer" the responses that resolved your issue, and to click "Unmark as Answer" if not. This can be beneficial to other community members reading this thread. If you have any compliments or complaints to MSDN Support, feel free to contact MSDNFSF@microsoft.com.

    Wednesday, September 6, 2017 6:04 AM
    Moderator
  • The project will only be manipulating the following objects:  AppointmentItem, MeetingItem, and MailItem.

    The criteria will all be held within the objects (Times, Subject lines, key words I'll be looking for).  Nothing requiring anything from .NET

    For example:  I'll be sending special replies to emails coming from specific addresses.  Basically, I'll be doing a few things that setting up Outlook rules won't be able to neatly handle.

    ATL/COM seems to be just fine and I won't have to deal with RCWs.  

    It's been a few years since I've done this sort of programming.  I just want to make sure, I'm not about to use a technology that's either no longer supported, or "painting myself into a corner" by using a technology that is not easily extensible should the requirements change in the future.

    Wednesday, September 6, 2017 2:16 PM
  • Hi GermánH,

    you had mentioned that," I just want to make sure, I'm not about to use a technology that's either no longer supported, or "painting myself into a corner" by using a technology that is not easily extensible should the requirements change in the future."

    you had posted the issue in Outlook for developers forum.

    this forum handles Outlook VBA, Outlook Object Model using C# or VB related issues.

    so here I want to inform you that the support for Outlook VBA , Outlook Object Model using C# or VB will be continue in future and it will not going to discontinue.

    the support for older versions may be discontinued according to support policies and also new versions of Outlook are getting launched.

    so support for that will be added too.

    Regards

    Deepak


    MSDN Community Support
    Please remember to click "Mark as Answer" the responses that resolved your issue, and to click "Unmark as Answer" if not. This can be beneficial to other community members reading this thread. If you have any compliments or complaints to MSDN Support, feel free to contact MSDNFSF@microsoft.com.

    Friday, September 8, 2017 1:16 AM
    Moderator
  • so here I want to inform you that the support for Outlook VBA , Outlook Object Model using C# or VB will be continue in future and it will not going to discontinue.
    Are you saying that support of COM add-ins written in unmanaged C++ will not be continued?
    Friday, September 8, 2017 1:24 AM
  • I do not think that is correct - Outlook supports COM based (IDTExtensibility2) addins. Whether they are written in unmanaged C++, Delphi, or any .Net language (including C# or VB.Net) Outlook does not know or care.

    Dmitry Streblechenko (MVP)
    http://www.dimastr.com/redemption
    Redemption - what the Outlook
    Object Model should have been
    Version 5.5 is now available!

    Friday, September 8, 2017 1:58 AM
  • Hi RLWA32,

    you had asked,"Are you saying that support of COM add-ins written in unmanaged C++ will not be continued?"

    it will be supported as it was before.

    but the focus of this forum is more on VBA and object model related issues. but it doesn't mean that the forum will not support com add in related issues. it will also be supported.

    Regards

    Deepak


    MSDN Community Support
    Please remember to click "Mark as Answer" the responses that resolved your issue, and to click "Unmark as Answer" if not. This can be beneficial to other community members reading this thread. If you have any compliments or complaints to MSDN Support, feel free to contact MSDNFSF@microsoft.com.

    Friday, September 8, 2017 3:23 AM
    Moderator
  • This thread is beginning to drift a bit from my original question.

    I'll just go ahead with ATL/COM C++  since I don't see any objections to it in here.
    • Marked as answer by GermanEZI Wednesday, September 13, 2017 7:44 PM
    Wednesday, September 13, 2017 7:44 PM