I've submitted my outlook add-in 6 times now and every time the certification failed for a different reason. The last rejection reason I got was that my add-in didn't work on Office 2013 and Office 2016 (which they also refer to as O365 Perpetual).
I develop on a Mac and I have no idea how to go about debugging why my add-in is not working on those older Offices. Can't I just drop support for older Office suites? How could I test these environments?
I'm pretty close to quitting and just not publishing my outlook addin. I have never experienced a worse app review process.
If you want to be published on the Office Store, you need to support all the platforms for the minimum Outlook API Requirement Set in your manifest.
If you do not need to support Outlook 2013 or Outlook 2016, you can set your minimum API requirement set to 1.5, which will drop support for those versions (1.4 was the last version supported by those versions of Outlook). When you submit to the Office Store, please make a note that your minimum API set means that the add-in will not run in those Office clients.
Related
I am trying to create an Outlook add-in with the onSend function. I can see on the GitHub onSend Tutorial that onSend is only supported on Outlook web and 365. Has this been updated now (the readme is 2 years old)? I am trying to debug mine on Outlook desktop 2016 (using Visual Code + Edge extension) and the debugger never reaches the function I created and that is supposed to be reached during the onSend event.
If still not supported, can I still deploy this add-in via 365 (admin) and get it reflected on Outlook desktop 2016?
Thank you very much.
The On-Send feature is supported by the desktop editions of Outlook for Windows. Make sure you deal with the supported version of Windows, Exchange server, Outlook. Read more about that in the On-send feature for Outlook add-ins article.
OnSend is not supported in Outlook Desktop 2016.
I work on an add-in for Microsoft Outlook, and recently we’ve received reports from some users that they can no longer click on buttons in the taskpanes of add-ins. Other add-ins, not just ours, have been affected by this issue. Affected users can still open the taskpane without issue. Our taskpane web view loads correctly, but then any clicking inside the taskpane has no effect. We are not seeing console errors when this happens.
To help narrow things down further: we’ve seen this issue occur in Outlook 2019 and Outlook for Microsoft 365 MSO with Office 365 accounts so far. We’ve seen this issue happen when the taskpane is opened from Compose view. One affected user was using Outlook 2019 version 16.0.13127.20266 (32-bit). Affected users have been running Windows 10, version 2004. A team member was able to reproduce the bug by updating to version 2004, but the bug disappeared for them after a subsequent system update on the same version 2004.
Has there been any recent change to add-in taskpane behavior that could be causing this issue?
This issue was fixed, and the fix should be available in Windows build 19043.1266 or later. Note that it is the Windows Build that matters, not the Office build.
We are seeing the same thing since updating to Windows 10 build 2004. For us, the add-in task pane freezes when the user tries to reply to an email (which is also compose view I guess).
Would be good to get an update on this as it is breaking the add-in for our users.
We are using Outlook Version 2009 (Build 13231.20200)
This is Outlook for Microsoft Office 365 MSO (16.0.13231.20146) 64 bit.
Can we deploy outlook web-addins for O365 accounts using centralized deployment as described here ?
Three/Four months before, if I tried to install outlook add-in using this method, installation itself would fail. Now, I don't get any errors while installing, but the add-in does not appear in Outlook clients (Outlook 2016 in Windows and OWA in browsers).
Are centralized deployments supported for Outlook add-ins now? Also, are there any client side requirements? I found some related information here. But I am doubtful if it is up-to date.
Thanks for the query bala. Centralized deployment for Outlook add-ins is not supported as of now and will come very soon. There are no specific client requirements other than minimum requirements for add-ins.
I am having a horrible time getting started at creating an add-in for Outlook. I want to use the new html/javascript/manifest approach. I have been able to create a manifest and application which works great with outlook.live.com. Where I am completely getting stuck is with desktop Outlook. How do I install/debug my add-in with desktop Outlook?
I cannot find anything in the UI which will let me add this style of add-in. Additionally the Microsoft documentation did not make things any clearer. Their docs seem to hint using this type of add-in is only possible if you are connecting to an Exchange server.
Any help would be greatly appreciated.
Yes the add-in will load on Outlook desktop only if your mailbox is Exchange. I am not sure the add-ins work with a personal Microsoft account (e.g hotmail.com, outlook.com) and Office desktop. Keep in mind that the support of mail add-ins for personal account is relatively new (officially announced in march 2016).
To develop your add-in I suggest you to use a organizational account (i.e. Office365 account). Support for organizational account has been released in 2013 and is a much more mature solution for you to get started. You can have a free dev account at dev.office.com.
Edit: October 2016 personal account are supported now by "Personal mailbox accounts" aka outlook.com accounts
Let us keep in mind that a mail add-in is not installed on a mail client (desktop, OWA) but on the mail account. When you "install" an add-in you only set a xml file on your mailbox that basically says "there is a web add-in out there called X and that is served at this url...". Then, if you install add-in X on your mailbox smaclell#mytestcompany.onmicrosoft.com, this add-in will load the add-in web iframes whether you are consulting your mailbox with Outlook Web Access (OWA) or Outlook Desktop.
To install the add-in for one user mailaccount, you have to use the Outlook Web Access. See this blog post. Note also that you can install the add-in for the whole organisation (Admin > Exchange Admin > Add-ins). Finally, Visual Studio is also able to push the manifest to your office 365 mailbox. To have this you need Office Development Tools.
For debugging in Outlook Desktop, I know two approaches.
Use the Office Developement Tools with visual studio
and select your sample add-in project as 'Starting project' and in properties select 'Office Desktop'.
Plain web development.
Personally, I do not use really much the Office Development Tools. I install manually my add-in with "https://localhost:XXXX" for url and I start the web project on IIS express to do the debugging. For stepping into the source code, I use the debugger of my browser (Chrome, Edge, IE etc.) when browsing in OWA. When I need to step into source code specifically on Desktop (For windows or for Mac) I use Vorlon.js see also this blog post.
My advice is also to test/debug frequently with IE 11 (still available in Win10!) and OWA. Indeed, the browser used internally by Office Desktop for the add-ins is IE.
I have created a small application to send emails via Outlook. The application opens an Outlook mail item with various pre-configured templates.
Now, the application was first build for Outlook 2010 using the Interop version 14. When testing on Outlook 2007, the application fails to create the required MailItem. I was assuming that the Interop would be backwards compatible, but that doesn't to be the case.
I have already tried using the Interop v12 instead, but then the application doesn't work on version 2010.
How can I make this application work with both Outllok 2007 and 2010.
Cheers,
Martin
You need to develop using the lowest supported version of Outlook (2007).
What exactly does not work when running under Outlook 2010 when you are using the 2007 interop?