I want to create a custom Addon/plugin for Outlook 2003, to support integrated functionality with a task management system.
I am unable to find many good development resources for the same.
Can someone please explain Outlook 2003 architecure and development of a plugin.
Good links/resources are also welcome.
Here is a tutorial on outlook architecture getting started building Outlook 2003 plugins from MSDN:
http://msdn.microsoft.com/en-us/library/aa289167.aspx
There is also a huge list of resources here: http://www.microeye.com/resources/res_tech_vsnet.htm
Good luck!
What you want can be done.
The bottom line is that you need to use Visual Studio 2005 or Visual Studio 2008 plus Visual Studio Tools for Office (VSTO) plus Outlook 2003 (of course) to build an "Adddin" for Outlook.
Addins are quite complicated to write mostly because Outlook has eccentricities that are not well documented. For example, a method Outlook.MailItem.GetHashCode() is not always the same even for the same object despite what you might expect from something as seemingly absolute as a 'HashCode' for an object. Knowing that and many other quirks of the VSTO+Outlook API are for what the professionals get paid. There are MANY quirks. If you are learning then you will need to start with the resources Gdeglin has provided.
Also look at the MSDN VSTO forum:
http://social.msdn.microsoft.com/Forums/en-US/vsto/threads <- very active!
And Outlook code: http://www.outlookcode.com/
Also here is a Google search on MSDN for various VSTO 'tips'.
Related
I am new in Office add-in development and little bit confused about creation JS plug-ins for Outlook. Actually we can create one add-in which will be available on all platforms: Outlook on Mac/PC, Outlook.com and Outlook 365.
But what about tools for it? According Outlook development documentation, we can use Yeoman generator for creating Office add-ins. However in my VisualStudio Community 2015 is type of project like "Web add-in", where I can chose Outlook add-in. So is there some difference between Yeoman generator and VisualStudio Web add-in projects?
Visual Studio is the main tool for creating Outlook plugins. You can also use Visual Studio Code for developing web-based solutions.
Office add-in is nothing else as "manifest.xml" file + your web application (HTML + JS). Web application is what your VS Code is help you to create. The manifest part is something which you able to write yourself, coy it from an example or use YO Generator to produce it for you. More on how to build office add-ins: Office Add-ins with VS Code and how to use generator: Yo Code - Extension Generator
To answer your question "is there some difference between Yeoman generator and VisualStudio Web add-in projects?": There is no fundamental difference. First choose whether to develop your Outlook Web Add-in with VS or with some non-VS tool. If you use VS, then use the project templates in VS. If you use any other development tool, use the yeoman-generated templates.
Occasionally, templates can get out-of-date. For example, recommended practices may change, or the manifest XML schema may be expanded. As a general rule, the yeoman-generated templates are updated more frequently than the ones generated in VS. For this reason, there may be small differences in the templates (besides the differences that are inherent to the differences in the tools).
Several years ago, I did some pretty serious Office add-in development for Office 2003 (Word, Excel and PowerPoint). I created some shared COM add-ins in C# using Visual Studio 2003. At the time, I looked at VSTO, but decided for reasons that I can't fully remember that it was not suitable for my needs.
My add-ins are due for an upgrade now, and no longer need to support Office 2003 - though they do still need to support Office 2007, not just 2010.
I know that things have moved on significantly, and that Visual Studio 2010 has better support for Office development. I'd like to determine whether I should re-implement my add-ins using VSTO, or continue with the shared COM add-in route.
If anyone knows of a nice summary of the pros and cons of each approach (beyond the marketing hype), I'd love to hear it.
Things that I found very frustrating first time around (not using VSTO, but may apply anyway):
the need to manage COM references explicitly (and call
ReleaseComObject everywhere)
the need for a COM shim to get the security model to work
visual studio installation projects just plain didn't work; I ended
up building my own MSI-based installer
lack of documentation, particularly on all of the above; I spent
weeks of trial-and-error and searching random blogs; the MS-supplied
example code completely ignored all of these real-world issues
It's also worth mentioning that minimising the amount of stuff that needs to be installed prior to my add-ins is important. I think that one of the things that put me off VSTO was the need to deploy additional stuff (though since I never went down that route I don't know if that concern was justified). And I'd really like to be able to deploy on a standard Windows 7 (or Vista) build without the need to first install (say) .NET 4.
Partial answer but too long to fit in a comment:
Parts I can comment on:
Setup projects for VSTO addins now do actually work and there is a very good walkthrough available on how to create them properly.
Documentation in general of the office object model is poor imho and that should be equally annoying for com and c# development. Because a lot of the objects are now returned as dynamics if you use .net framework v4 you loose intellisense which does not help. The workaround for that is to be explicit in casting to known types where possible.
In order to run it obviously needs the relevant framework installed (v4 is FAR better for this than earlier version because of dynamics, optional arguments that were added under pressure from the office group and the NoPIA setting) Besides that it also needs the VSTO runtime installed.
All of these dependencies could be incorporated into the installer but they are required
You haven't specified what you used to create those com addins (My guess is c++ or vb6) and I can't tell how large they are and how much overhaul they need so it's not really possible to give advice if now is the time to make the change. One of the areas where moving to c# will certainly be far cleaner and nicer is anything related to ribbons. But again I can't estimate how relevant that is for you.
Is it possible to create an add in that works on all office versions?
I searched the msdn and different forums but there is nothing specific about this issue.
Difficult if you use VSTO, because you'll need to deploy/assure different runtime libraries. See the VSTO entry in Wikipedia, not to speak of different development and test platforms (which you may already have, if you aim for it).
There's a MSDN Blog from Mary Lee the migration of 2007 to 2010 projects.
Please see also this blog from Andrew Whitechapel: Can you build one add-in for multiple versions of Office?
From a pragmatical point of view ("time-to-market"), you may consider the use of a third-party-tool (www.add-in-express.com), which allows the creation of version-independent add-ins.
In relation to this stackoverflow question, how would I go about creating my own Visual Studio 2008 plug-in?
I've checked the Visual Studio Developer Centre on MSDN, but the amount of info is overwhelming. There are loads of project types, and I don't even know where to start.
Where should I start looking if I want to write something which meets the following requirements:
A plug-in that runs like a "service" in Visual Studio, and is able to poll Visual Studio for information, and handle Visual Studio events.
The info I'd like to access from VS are things like, what projects are currently open, who has them open, and other solution/project file based info.
The events I'd like to be able to handle are things like, the opening/closing/editing/creating/deleting of Solutions / Projects / individual files.
I'd also like to be able to handle any interaction with VS on a per solution basis. So, I'd like to handle any interaction with files, even code editing, but also, just other interaction, like with the menus, or just the IDE itself.
As well as these, I'd also like to be able to store data somewhere. Where is this usually done? Can I add Metadata to the Solution file? Or, does it make sense to save this info to a small local instance of a database, that is somehow attached to the solution..?
I just need a push in the right direction, is any of this possible? What part of the Visual Studio Developer Centre should I focus on? What APIs should I check out?
cheers!
An add-in can do most of that. There's a template in VS2008 for creating a base add-in.
I have an add-in that you can download that hooks into the solution/project load events etc - it is free and comes with source code ( http://www.huagati.com/projectloader/download/huagatiprojectloader.zip ). This particular add-in detects when projects/solutions are loaded and pre-loads referenced assemblies to work around a CLR bug that can cause VS2008 to crash. Anyway, the source code for it shows how to detect some of the events you're looking for.
Other than that, the definitive resource on add-in development and all the little quirks and tricks involved is Carlos Quintero's blog ( http://msmvps.com/blogs/carlosq/ ) and the "howto" article series on his website ( http://www.mztools.com/resources_vsnet_addins.aspx ).
Craig Skibo's blog ( http://blogs.msdn.com/craigskibo/ ) also has some useful tips.
You want:
Visual Studio Extensibility Developer Center
VSX Forum
Visual Studio 2008 SDK
Professional Visual Studio Extensibility by Keyvan Nayyeri
Buy the book, if nothing else.
Can someone give me a quick explanation of when I would use Visual Studio 2008 Outlook 2007 Ad-In project type? and how would that compare to developing a bunch of outlook macros directly in outlook?
Basically, I want to have some sort of application read email (with attachments) from a pop3 email box, do some filtering/editing/validation of the subject/sender/content and then if certain conditions are met, save the attachments to a local file, and then add an entry into an SQL server database table (i.e. date/sender/subject/message).
Seems there are at least 10 different ways to do this....so between an outlook macro and a VS Office Project, how do I pick?
I am not clear, if I create this solution as a Visual Studio outlook add-in, where does it run? Is it loaded into outlook, does it run as a separate process and communicates back and forth with outlook? if outlook is not running, does it start it?
An Outlook Add-on is a compiled component that uses the Outlook API to perform the tasks you need. A macro/VB script is an interpreted script that actually uses the same API. The add-on approach is better if you want to deploy your functionality.
When you work on an Outlook add-on in Visual Studio, you'll be creating a .NET component, which integrates into the Outlook application, which is written in C++ so uses COM. You'll have to be careful about managed/unmanaged types and releasing objects you retrieve from Outlook.
I have recently completed just such a tool, but I chose to use Add-in Express (http://www.add-in-express.com/). These guys provide a layer of abstraction over the [challenging] Outlook API and also provide some excellent support if you're stuck.
In my case, with Add-in Express, I "run" by setting Outlook as the application command to run, in the Project properties. Add-in Express sorts out the installation of the add-on within Outlook. So when I press "Run", Outlook starts and my add-in is displayed, which may be debugged in the normal fashion. I'm not sure how VSTO (Visual Studio Tools for Office) works in this respect - or at least, I can't remember.
This is an example of an outlook add-in..
Personally, I don't see macros distributable.