I am willing to develop an Outlook add-in for both, the web and the desktop version. My questions are:
When I upload a new version of the add-in, is it automatically updated (per default) in the users' devices / outlook web accounts?
Is it the same add-in for both, web and desktop, uploaded to office store?
If you are only updating the source code of the add-in (HTML, JavaScript, CSS) on the web server where you host it, then all users will get that right away since like Dmitry explained, Outlook will download the page like a browser would download it. So you should be careful updating the page of the production add-in - users will get the updates right away (although keep in mind that user's system/browser may cache previous version of the page for some time), so if you break the page or functionality of the add-in, users will get affected immediately, which may result in negative reviews for your add-in in the Office Store.
If you are updating the manifest XML file of the addin, then you need to publish new version of it to Office Store. Once it's published, that new version will automatically be updated for users who already installed an earlier version of the add-in. This automatic update will happen after they login to any of their Outlook clients that support add-ins.
Yes it is the same add-in for both web and desktop - that's the beauty of the new Office add-ins!
Hope this helps.
Web addins are never even stored locally, (desktop) Outlook downloads the addin source code every time it starts up.
Related
We have a custom Outlook VSTO add-in. We publish to a location which installs based on version, and it has worked perfectly for years. For some reason, the new version we pushed today is not running properly. It installs fine, it appears to be running (i.e. shows in the list of Add-Ins, has delays ignored, and shows as active) but the icon that should show up in the ribbon for a meeting is not appearing. It does work on the developer machines. No errors are logged anywhere, including Application Event Viewer. The install package does seem considerably larger, but there are no massive upgrades, and the machines with the issues have .Net 4.8 as do the development machines.
but the icon that should show up in the ribbon for a meeting is not appearing
By default, if a VSTO add-in attempts to manipulate the Microsoft Office user interface (UI) and fails, no error message is displayed. However, you can configure Microsoft Office applications to display messages for errors that relate to the UI. You can use these messages to help determine why a custom ribbon does not appear, or why a ribbon appears but no controls appear. See How to: Show Add-in user interface errors for more information.
Also you need to make sure that images are available on the end user machine.
I have an Add-in I have written for Microsoft Outlook. The Add-in runs in a task pane. I have a button on the html in the page that opens a new window using Office.context.ui.displayDialogAsync. This button works fine in the web client, but when clicked in the full Outlook client, a window appears and disappears in a split second. This Add-in was developed outside VS so not sure how I can debug apart from in web client, which not does have the issue.
The domain is the same, and the domain is in the appDomain of the XML manifest. The URL is also https.
Does anyone have any ideas, have I missed something that says this isn't available in full client and only available in web client?
About Outlook version:
Version 2102 (Build 13801.21004 Click-to-Run)
Microsoft Office for Outlook 365 MSO (16.0.13801.21002) 64-bit
If I clock Office Updates, it tells me Office is up to date.
Update
I have another machine with Outlook installed, and I have discovered the dialog opens fine on the full outlook client. Looking at the version for that version of outlook (logged in to the same Office 365 account), the version shows as:
Version 2110 (Build 14527.20226 Click-to Run)
Microsoft Office for Outlook 365 MSO (Version 2110 Build 16.0.14527.20168) 64-bit
So it looks like maybe the earlier build had an issue in Outlook?
Would you like to share a screen recording in the machine where the API is not working?
Besides, you could also try a test add-in with this: Manifest.
It's an app command so you can click "Show Taskpane" first, and then click "launchDialogSameOrigin" button in the taskpane. You can observe whether the dialog is working correctly in this add-in.
Thanks.
We developed an add-in for Outlook which is published in the store already. It has paid and trial versions. License checking in the add-in works fine if the add-in is used from a browser, Outlook for Mac. But if it is Outlook for Windows or outlook.live.com (versions where "add-in commands" feature is enabled and add-in is opened in a side bar) then no license information is passed.
Example:
This correct URL is navigated from Outlook Web and Outlook Mac:
https://serverurl?et=%3cr+v%3d%221%22%3e%3ct..............
This is how the URL looks like for Outlook for Windows:
https://serverurl?_host_Info=Outlook|Win32|16.01|en-US
So, since Outlook for Windows does not supply license information we have to refuse add-in access for our clients on Outlook for Windows.
I found related questions for Excel and Word, but none of them was answered yet. The problem is that it is Outlook that needs to send the data, so we can do nothing in our code to troubleshoot.
Guys, any ideas where the problem is or what to check in the manifest?
Here is the link to the add-in listing in the Office store (TextMiner) if it may help to answer.
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 an outlook 2007 add-in project in vs2008, targeting .net 3.5, then migrated the project to vs2010.
I have then published the project from vs2010 to a web site, and installed the add-in using click-once to a virtual machine running xp, .net 3.5 sp1, and outlook 2007. This all works great and I can see my add-in within outlook. Publish update settings are set to update the add-in at startup rather than every 7 days.
However when I then make a simple change to the add-in, update the AssemblyVersion and AssemblyFileVersion of the add-in project, and then publish the updates, when I run outlook it doesn't detect that there is a new version, and just runs the current one that is installed.
I can see that the publish has generated a new setup.exe and added a new folder to the 'Application Files' folder with the current (autogenerated) publish version.
Can anyone suggest how I can get the update to be deployed to the client?
Edit:
I left the VM without outlook running for a while (over lunch) and then came to start it up and it detected the latest update and installed it. However now when I make another change and re-publish it is not picking it up. I wonder if this has something to do with caching of the files. I have deleted all the temporary internet files on the client vm, but that didn't help.
The reason it is not detecting published updates was due to iis caching the pages.
I added the expiration common header in IIS7 manager and set it to expire immediately, and after that the addin detected each change as it was published.
Double-check and make SURE you have it set to check every time they open the application and not just once a day.