I currently have a VSTO Outlook addin which uses the interop libraries to read/send/delete emails.
Will these interop libraries be affected by Microsoft's move to stop support on November 2022, for REST APIs and enforce the use of GRAPH APIs instead?
This may be a stupid question, but I have not read any conclusive documentation that interop libraries will be unaffected by such change.
Thank you very much in advance.
No, your VSTO addin won't be affected: Outlook does not use REST API. It does use MAPI, MAPI-over-HTTP, EWS, and Graph internally, but none of that (except MAPI) is directly exposed through the Outlook Object Model and VSTO API built on top of it.
Related
As per the documentation by Microsoft, there is a property to check whether the presentation is completely downloaded or not in office VBA Reference.
Presentation.IsFullyDownloadedhttps://learn.microsoft.com/en-us/office/vba/api/powerpoint.presentation.isfullydownloaded
Is there any way to do this in a C# VSTO addin?
The 'Presentation' class in vsto solutionhas all the other properties as in the vba presentation class but not "IsFullyDownloaded".
If you can use it in VBA for your PowerPoint installation (that means it is implemented by the host application) you can call it using the late-binding technology available in .Net via Type.InvokeMember from any applications including VSTO add-ins.
I am using word 2007 Version and came across one problem and looking for a solution to it.
I am using Grammarly Add-in for word and I am looking for a way to accept all the suggestions that Grammarly add-ins provide. I try to record a macro so that I can have some insight into the possible solution. But the macro recorder does not record anything while working within that add in.
The best what you could do is to contact Grammarly add-in developers to provide any public interface implemented in the COM add-in and which can be consumed by third-parties. The following walkthrough demonstrates how to expose an object in a VSTO Add-in to other Microsoft Office solutions, including Visual Basic for Applications (VBA) and COM VSTO Add-ins - Walkthrough: Call code in a VSTO Add-in from VBA.
I am about to develop my first ever MS Outlook add-in (following this MS guide).
As I create my new project, I see this ...
Was there really such a change between these versions of Outlook? Does this mean that I will have two develop two copies of my add-in? Is there no forward/backward comparability?
Am I even following the correct guide? Should I be developing a VSTO? This question has an answer by Outlook Add-ins Team - MSFT (although their profile does not actually any actual MS affiliation), which starts
We recommend using the web add-in framework, instead of COM, for
writing an Outlook add-in. The web add-in framework enables developers
to:
Write once and have their add-in run across supported Outlook clients
enabling the add-in to reach millions of Outlook Desktop, Outlook for
Web, Outlook for Mac, and Outlook Mobile users.
The short answer is no, a 2013-2016 VSTO Addin will work with 2010. If you need it to work with Office 2007 you'll have to add the assembly Outlook 2007 Primary Interop Assembly (PIA).
Background:
I have come up with an idea that will make things easier for the company I work for. They even seem excited about the idea. The idea is to make an addin for Outlook to help with a task. So after doing a bit of research (obviously, not enough). I downloaded a trial copy of VS2010 pro and created a VSTO addin.
After creating the addin, it was time to package it for a small test deployment. That's when I found out that this is a much more difficult thing to do. It seems MS does not ship Office 2010 with the runtime needed to run VSTO, so i'd have to package that as well. In a company environment, this is not something simple to do.
So, I might have to go back to the drawing board.
Meat of the question:
I've never created an addin for office before, I really want more of a "drop in" solution. I'm not sure if VBA is the right solution. It seems more of a "document" level application (or macro?). Does any one know what would be the best type of solution for this?
Outlook API is not native .NET framework. To interact it with, .NET relies on marshaling and interrop assembly thus making it much more prone to errors and unstable.
From what I've seen so far with my outlook API experience, I would stick with VBA and you should consider retrieving a third party library that exposes outlook extended MAPI if you run in to much of trouble.
NetOffice is pretty good - it is a set of managed .NET libraries that handles the COM API with Office and only needs XCopy installation.
The best part is it tracks all runtime callable wrappers ('RCWs') you create when accessing objects through COM and automatically releases them when you dispose the top-level object (the Application in most cases), so you won't get the issue of an orphaned COM 'handle' preventing you from closing Office.
Alternatively, the Office Primary Interop Assemblies should be on any computer that has the relevant version of Office installed (at least for >= Office 2007). But there are cases when it won't so you will have to cover that possibility. VSTO redistributable should already be installed on any computer with Office 2010 or 2013. For Office 2007 you will need to install it. But again, better safe than sorry so you should include it in your installer in both cases.
For details on deployment options look at http://msdn.microsoft.com/en-us/library/bb386179.aspx
As for VBA, I don't have experience for Outlook addins so I leave that to others to explain. Other VBA Office app addins (Excel/Word/Visio/PPT at least - not sure about the others as I haven't used them) can be installed either using registry keys or through XCopying the addin to a trusted location and then telling the user to open Options/Manage addins and tick the tick box.
I highly recommend Add-in Express. They have tools that go beyond what Microsoft provides via Visual Studio.
Their features for Outlook development greatly reduce the amount of effort required to build Outlook add-ins
I'm about to work on some Outlook add-ins. It's been years since I did this; and probably several object model revisions!
Can anyone recommend some references to help get me started: blogs, sites, books??
Thanks
If your budget can afford it (ie. the product is making money), I would highly recommend Add-in Express. Lots of samples, documentation, and support -- but requires using their tooling. (It makes Outlook ever so slightly-less of a PITA to deal with.)
However, if you prefer to stick with a (free with VS) Microsoft solution -- it works fairly well, but is missing some "niceties" -- then check out the VSTO on MSDN page as a first stop an follow the links out. There are also some good sample projects, templates, and VSTO tools on codeplex.
Happy coding.
Edit: I guess I must be bored :-) Here are some selected links that I found helpful. some of these are very specific/advanced, and some are more general. The arrangement is in no particular order.
MSDN Outlook 2010 Top-Level. Links to documentation (MAPI, PIAs) etc.
SGriffin's MAPI Internals. Lots of details wrt MAPI. Generally on low-level access but also a good source to find out about changes, new documentation or tools, etc. He could probably rewrite MAPI from memory.
MFCMAPI Program & Source Invaluable tool for inspecting MAPI folders, properties, and whatnot. Is Microsofts "reference example" for most "How do I do x in MAPI?".
OutlookSpy Program. This isn't free, but there is a trial. It may or may not work better than MFCMAPI for particular needs. This was written by the author of Redemption, a supplement/replacement for the PIA OOM access. Dimastr has also answered a number of (advanced) Outlook/MAPI forum posts online -- always a good person to look out for.
Outlook 2010 Messaging API (MAPI) Code Samples - Covers basic (wrapper) implementations of the providers (address/store/transport). All native C++.
OutlookCode.com Site promotes some Outlook books by Sue Mosher. I can't vouch for the books, but the site is a mixed-blessing with some good links, some useful advice, and some downright ugly code :-) Also has a forum.
Visual Studio Tools for Office in VS2010 has come a long way. I used to make (and sell) an Outlook add-in for Tablet PC's and it was very complicated back then. A properly designed add-in in .NET would need to set up a separate AppDomain to avoid stomping on other add-ins and implement all kinds of workarounds to avoid leaving orphaned Outlook processes when the main window closed.
VSTO does all this "out of the box" now.
Outlook Solutions in Visual Studio
Don't forget this MSDN forum as a great resource:
Outlook for Developers Forum:
http://social.msdn.microsoft.com/Forums/en-US/outlookdev/threads
BTW, #pst: you can still use late-binding to work with the newer Object Models within a version neutral ADX project.
#Josh: VSTO already loads each add-in into it's own AppDomain
#everyone: I work for ADX, feel free to ping me for any questions.