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.
Related
I need your help in deciding the best strategy and technology to choose from for the continuing development of a successful in-house VBA application.
In our company (a web-based distributor of financial information), over the years, we have developed a VBA XLA Add-in application for use only inside our company, which helps in the linking of our database of financial information with Excel worksheets, through the use of several UDF's, supported by ADO/SQL and other business objects logic. This app became a solid, fast, and useful tool for us, somewhat similar to old DDE links, but much more sophisticated and flexible than that.
Recently we replaced the ADO/SQL portion of the system with a SOAP based Web-Service and XMLHTTP MSXML 6.0 technology, literally putting our database into the cloud. The goal was to transform the application into a product which could be used outside of our company. That work is already done, and its behaving quite well, with all functionality, load at startup, user authentication and session control login/logout, seamless integration with EXCEL, user-friendly messages, all done in a single 2.036Kb XLA Add-In file, spanning more than 15.000 lines of good VBA code. However, we feel that it cannot yet be distributed like it is...
We feel that in order to be successfully published as a product to our clients, this application must be transformed into compiled code instead of the interpreted VBA. There are many reasons to justify doing that, including security, speed, robustness, etc.. but we don't need to go into these details right now.
Our fist thought was to use VB6 and Automation Designers to quickly transform our VBA code into a VB6 Automation Add-in. Apart from the fact that VB6 is old technology, it seems that Automation Add-in's are not the ideal solution, for our app requires some interaction with Excel events and the End-User, at least during the "login" and "logout" into the web-service based database (and some other functionality that requires user interaction through forms), BUT is seems that Automation Add-ins are not suitable to anything other than UDF's only. Here we would like to learn about other's experiences with Automation Add-ins and end-user interaction.
So, COM Add-in's are the next option. Again, these allow interaction through menu buttons and commands, but do not allow UDF's in the worksheets. Or so we've read. Also, we have read that COM Add-ins can be made as Automation Add-ins (allowing UDF's after all), but that they will work as two separate entities inside the Excel environment (one COM and one Add-In), one half not communicating with the other. That's not acceptable to us. Again, we'd like to learn more about other's experiences in that regard.
Then there is Managed Code (.NET, Interop, and VSTO) as other viable options. However, while simple to get started with, it is not clear that Interop came to stay, and it is not clear what is the best strategy with managed code. Again, we'd like to learn about other's experiences in this realm.
So, the questions final is: given our requirements (i.e., load at startup, access to data through SOAP based web-service (MSXML 6.0), UDF's functions, login/logout session control, user-friendly error handling, etc.), and the fact that we already have 15.000 lines of good VBA code, which is the best technology for us to continue to develop this Excel component, in order to make it into an easily and safely distributable product? All comments and thoughts in that regard are very welcome.
I would take a look at Excel DNA: https://github.com/Excel-DNA
I had a very similar problem developing a VBA add-in that communicates with an ASP.Net Web API. Couldn't really give all the code out in VBA, so we needed a way of giving out compiled code. Connecting to the web service was freezing up excel making it harder for users working with massive spreadsheets with multiple API calls.
You can develop them in visual studios easily using VB so a lot of the code could just be copied and pasted over then changed slightly to fit the later version of VB you're using.
Add-ins compile to .xll 64-bit and 32-bit versions.
We handle all login and connection to the API in the Ribbon: https://exceldna.codeplex.com/wikipage?title=Ribbon%20Customization&referringTitle=Documentation
And you can use newer VB forms which are more user-friendly.
Connect to other .dll files for sharing logic across multiple add-ins.
The UDF we use which call the API can all run asynchronously freeing up Excels main thread.
https://exceldna.codeplex.com/wikipage?title=Asynchronous%20Functions&referringTitle=Documentation
It can run any VBA specific or CAPI code by queuing as a macro.
Pretty much do everything that you could do in VBA plus more.
Govert the Developer https://stackoverflow.com/users/44264/govert is very active on StackOverflow and forums. He's helped us out loads in the development. And Excel DNA is still being updated and worked on.
Let me know if you want some more details.
great summary of your project.
I'm also curious what other thinks about the "right" solution for such task. It won't be an easy decision though.
My short answer will be "stick with VBA" unless you are really concerned about stealing your code from the great VBA add-in.
The reason I'd go for VBA is that the longer I've been working with VSTO/COM the better I've found VBA to be the best for handling tasks that are closely related to Excel (understand MS Office) object model. I'm saying that even I have written almost zero lines of VBA code in last 4 years. I do understand that you are using webservices and other dependencies but I'd say that if you have good progress and the add-in is working as expected I'd NOT throw myself to a completely new world of development (VSTO & C#) just to be cool, you will gain not too much value of this, especially if you know that
deploying managed code is harder that just copy your add-in to a
folder, set registry, done
troubleshooting is a way harder with managed code, basically you will have to log much more and trying to reproduce issues that may not happen in your environment but happens in clients
re-engineering of managed code is not such hard so if people really wants to steal your code they can do that unless you use obfuscation
and the last and probably the most important for you as much as I'm aware there is no easy way to do UDFs in VSTO
I have very minimal experience with VB6/ COM Automation so I'd love to hear opinion of guys who have done something similar before
Re: the VSTO & UDF, at my job, we have a VSTO add-in that somehow handles UDFs for a large project. I'm not the main developer of the application but I believe we use Excel DNA there so do check it to explore the managed code option further
Hope that helps
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
One of my customers asked us to develop a "VBA macro". However, in the 2010s, it seems weird to me to still use such outdated language, and I'm thinking about trying to convince the customer to use VSTO dev instead. However, as I'm new to both worlds, I need help to fill a pro/cons page to be able to argue this.
Of course, the answer can't come without the actual requirement, let me try to resume:
Target : Word 2003/2007 (but I'm suspecting 2010 as a not yet known requirement) edit 2010 requirement confirmed
An external publishing system requires .doc file as input. The .doc file must have some specific styles applied : "Custom Header 1", "Custom header 2", etc.
The user can build documents, using Word, using two possible ways:
Start the new document using a .dot file deployed on the computer
Transform any existing document to match the target template
Users can "apply" the styles "simply" (simple UI): context menu, styles menu, custom action pane, etc.
By now, I see the following pro/cons:
VBA
Pros:
?
quick and dirty development (quick part of the sentence)
The customer has already some in production macro
Cons:
hard to find skilled developer
quick and dirty development (dirty part of the sentence)
VSTO
Pros:
benefits of the .Net language (compiled, typed, rigorous, class library, etc.)
security model more flexible and powerful (trusting code signed with a trusted authority)
bridge to WPF panes possible
You work in Visual Studio and have access to its full set of features: refactoring, source control, etc.
Cons:
requires installation of the .Net framework (probably not an issue today) and VSTO runtime
harder to deploy
slightly more work at the start (but less in long term)
I am not familiar enough to .NET but here is my humble opinion about VBA:
VBA
Pros :
easy to deploy and to make it work with the Office apps
quick and dirty development (quick part of the sentence) - agreed
Cons :
hard to find skilled developer
hard to select a skilled developer and explain your customer he needs to invest in this skill
quick and dirty development (dirty part of the sentence) - partial agreement. It will be dirty if:
you give the project to a VBA beginner and don't frame him/her
your project gets too big in terms of requirements
requires to have the .Net framework installed (probably not an issue today) I don't think so (maybe a CONS of VSTO?)
I would say that if you only want to have some code or add-in to merge some syles, you could easily do it with VBA and it won't be dirty (unless you really want it to).
I'm answering myself to the question, as the project is finished.
I finally decided to write the application using a VBA macro. Here is the post-mortem conclusion of this choice :
Pros:
The team that will maintains the application has no C# knowledge, only VBA (main reason of my choice).
Poor security model : it's a pro because there is no other setup that putting the files in the right place.
No runtime prerequisites
Cons:
The deployment was supposed to be simple.
I was counting of the possibility to play with Word options "User-template directory" and "Startup template directory". But it wasn't possible, because the app is not related to a specific entity in the customer organisation. I wasn't allowed to "take ownership" of this settings for this application.
I ended in writing a custom NSIS script to deploy the application on the correct folders. With VSTO, a simple setup project (clickonce?) would have done the job.
The language is so prehistoric ! Collections index starts to 1, array to 0, no OOP, poor out-of-the box language and library feature. That is not always a problem, but in my case, modeling the business rule was a bit painful (representing hierarchical data in a tree was not an easy job)
Very limited integration with source control (code, as it's embeded in the .dot files, was not historisable. Only the full .dot was)
Error management very limited with VBA
Poor IDE
Remark:
As an experienced C# developer, the pros/cons may be partial a bit.
I am a heavy Excel VBA developer.
VBA pro:
One of the major hurdles for me switching over to VSTO from VBA - and believe me, I love C# coding - is that there's no debug-on-the-fly which my userbase has got used to. I often jump straight into a VBA problem on the user's PC as it is happening, but with VSTO, that's not possible. (Unless someone can correct me.)
If your users have no such expectations this might be something you can easily live without.
VBA con:
VBA is one of the those languages that are easy to play with and thus easy to make a mess with. It doesn't enforce "clean coding" principles which means while decent programmers can make great applications with them, VBA can become associated with hackjobs and sprawling, organic code due to its low bar of entry. VBA developers are often considered a lower class of developer for this reason, when really there is a failure to distinguish between those that use it wisely and those that don't.
I doubt anyone chooses VBA as their career language of choice, it just sort of happens to them. Aside from being hard to find skilled developers, too much VBA work might turn away potential hires as they don't want to be associated with the "quagmire of another unmanaged VBA sprawl". Some people take use of VBA as a statement about how "serious" you are about technology.
(I tend to see Perl in the same light; great for short scripts but when someone used to using for scripting starts to use for a larger piece of work - you tend to get something that's a bit unwieldy.)
In this article I tried to summarize similar questions, in the context of Excel. Same arguments apply for all of the Office applications including word.
According to my observations :
VSTO :
CONS : that if we have developed Addins ribbons control for word 2007, we can only deploy with word 2007, but we can not deploy with word 2010 or word 2013.
This is major drawback for me to develop Addins for word and excel for all its versions like 2007, 2010 and 2013. plz correct me if am wrong or suggest me how could I develop Single Addins for all office version.
I am planning to do an add-ins project for Outlook 2007. I am pro developer in C#, WPF.
Please suggest books or sites for me to learn Outlook programming with C#. Any help would be appreciated.
Thanks.
Professional Outlook 2007 Programming ISBN:9780470049945
Programming Applications for Microsoft Office Outlook 2007 ISBN:9780735622494
I am NOT an employee of this company - but I really really like Add-In Express (http://www.add-in-express.com/).
It basically lets you write WinForms style code, embed your WinForms components, deploy and update using ClickOnce (HUGE feature), supports multiple versions of Office products, no VSTO dependency or deployment necessary, easy designer, standard automation model.
To answer your question, reading their tutorials and documentation was sufficient to get started doing extensive Office/Excel/Outlook dev.
Like anything, it has its bugs, but I really like it.
What are the software/ Wiki you use to write and share your specs about the developers, testers and management?
Do you use Wiki system, and if so, what Wiki software you use?
Or do you use Sharepoint to manage and version the specs? One problem with SharePoint 2003 as specs platform is that it's very hard to collaborate among different people.
For backward compatibility sake, I would also like to have the platform able to import Microsoft Word seamlessly. And it would certainly help if the interface is similar to Microsoft Word.
Any idea?
I've used Confluence at a number of places, it's a pretty powerful wiki and very good for creating specifications that can be shared amongst various parties. See:
http://www.atlassian.com/software/confluence/
There's some more information here on the advantages of using Confluence:
https://stackoverflow.com/questions/170352/confluence-experiences
EDIT: I've updated this to deal with the Microsoft Word import feature you mentioned. Confluence supports this through the Office Connector here:
http://www.atlassian.com/software/confluence/plugins/office-connector.jsp
There's also a Sharepoint connector:
http://www.atlassian.com/software/confluence/plugins/sharepoint-connector.jsp
plus a whole bunch of plugins:
http://www.atlassian.com/software/confluence/plugins/sharepoint-connector.jsp
Some of these are user contributed also. I can't recommend Confluence enough as a commercial wiki.
I've also used JSPWiki, which is open source. it's ok but not as good as confluence, see:
http://www.jspwiki.org/
You could try Google docs - I have successfully used this in the past. It supports import / export to MS Word, and it has great support for multiple user - see http://www.brighthub.com/internet/google/articles/8236.aspx.
It supports versioning, allows you to chat with other people who are currently working on the document, and shows you a list of all the changes others have made to the document (without needing to close / reopen the document).
If you want corporate support, Google also provides that - see Google Apps for business.
We use SharePoint -- it's not ideal, but it does a decent job. If I were you, I would seriously look at getting off SharePoint 2003 and on to MOSS (SharePoint 2007). It's not perfect, but it's substantially better. Here's a little bit on using MOSS as a wiki. I think in general wiki's are a good tool for getting people up to speed on your system. We used to pass around "getting started documents" and now we have all that type of stuff in our developer portal.
Per John's comment, I looked up this feature comparison. I have to go back and look at what features I'm using that are not in WSS -- I might be paying for licenses I don't need! :)
We use email. I know it isn't elaborate, but it is easy to use. Everyone has it installed and there are no licensing issues. All spec changes are sent to an super set email distro indicating the updates and the location on the network share where the spec can be found.
We use Alfresco, in its Community version, from both its Share and Explorer web interfaces.
Quite useful, with a document library, wiki, forum and calendar.
We curently host about 1.8 Go consisting mainly in docs, versionned and sometimes automatically converted to PDF (by creating an automatic content rule).
FTP, WebDav and network share are also used to access to the same repository.
You could take a look at Microsoft Groove - the collaboration software that Microsoft bought a few years back.
It's bundled free with premium versions of Microsoft Office.
You can customize the workspace with discussion boards and can fairly seamlessly store collaboratively-edited Office documents.
We use MediaWiki for dos & specs. Wiki definitely wins anything like Microsoft Word or SharePoint - it allows you to develop a documentation in "first refer, then describe" = "divide and rule" way. Perfect for developers - they used to think the same way. The process of developing a documentation is almost ideal: you start from TOC and drill down until you write the document for every link you put earlier.
MediaWiki is quite customizable - there are lots of extensions there. The most necessary ones are:
Source code highlighter - CSO_Source
Our own templates integrating wiki with class reference.
Others are InterWiki, FileProtocolLinks, YouTube (we use customized version of it to display HD video), ReCaptcha, SpecialDeleteOldRevisions, Maintenance.
Some integration examples are here.
And we use Google issue tracker to track the issues. Its main advantages:
Imput usability: the process of adding\changing the issue is really convenient there. Earlier we tried Track Studio - the same actions require 2-3 times more time there, so it died fast simply because most of us hated to use it.
Customizable grids. See the examples. Really helpful.
Atom\RSS support. So everyone knows what's going on.
There is a Gurtle tool integrating it with TortoiseSVN. Really helpful.
Its main disadvantage is that it can't be closed from the public access. This makes it simply unusable in many cases.
If you want a UI similar to Word, why not use Word with SharePoint 2007? You're on 2003 so the experience is there. Upgrade to SharePoint 2007 and you can have the collaboration, Word features, document sharing, and so on.
This is the kind of thing Microsoft wants people to use Office for, so there's a ton of doco out there about how to configure your SharePoint and Office environment to support collaboration.
There is something that Google do in this direction and it looks really cool: wave.google.com. It would be a great step in collaboration and worth to wait it.
Here we use Google Docs it makes the documents available to everyone write or read only, public or private among people that have or not Google accounts, it also can import Word docs, not to mention that it runs directly into the browser so it has high availability with zero cost and zero setup, also its computer/OS agnostic, we have a nice experience with it.
Also perhaps you should take a look at Basecamp or Backpack at 37Signals, any of then might also fit your bill.
We use DocBook for all of our specifications (and other customer-facing documentation). DocBook is an XML format that lets you easily generate documents in just about any format, including PDF, which is how we distribute things to clients to get them signed off. We can divide a document into files (by section) and commit everything to our source control system (Subversion). Because it is all XML (i.e. text-based), Subversion's automatic merging and conflict resolution works great if two people work on the same file. We have a set of stylesheets that all of our documents use, so all documents share the exact same style/format, with no extra work on our part.
And if you don't like editing XML files directly, there are GUI front-ends that provide a reasonably WYSIWYG-like experience. I believe that most people in my office use XMLMind. Still, we happen to all be technical people so if we had to write XML directly it wouldn't be an issue.
As a sidenote, we also put out release notes. We have some XSLT that lets us write documents like this:
<bugs>
<bug id="1234" component="web">JavaScript error when clicking the Kick Me button</bug>
</bugs>
We then have a script that runs through our Subversion repository doing an svn log from the previous release tag to the current release tag, and some Bugzilla integration to automatically generate release notes on-the-fly.
(also, for most internal-only documentation, we use MediaWiki, which is also a great way to collaborate.)
We use OnTime. It was originally only used for defect tracking, but we've started using it to track features as well. These can be used to document the feature as it evolves during development. Features can be grouped together into sprints or releases, and time can be tracked against each feature. If you are using SCRUM, you can also plot burn-down charts for each sprint. It also has wiki functionality.