Technical Changes

As we are about to release the new version out our Outlook Email for Jira add-in, we want to give you a technical overview on what changed. This is also a good point to re-evaluate which add-in is right for you. In case you upgraded to Office 365 you might want to check out our Office Add-in as well.

The main advantage of the new version is, that it shares most of it’s code with the modern Office add-in. The actual native COM-Add-in only has a fraction of the complexity of the old version, making it much more stable by design.

This article will walk you trough the differences between the old and the new add-in.

Changes Outlook Add-in

Requirements

In this part of the guide you’ll learn about the changed requirements on the clients. Changes are marked with yellow.

.Net Framework requirements

As Windows 10 is gaining more and more traction, so are high DPI environments (4k displays) with different scaling factors - even between different monitors. We tried to keep the minimum .Net Framework requirement as low as possible, but since we wanted to have a great experience even on high resolution displays, we couldn’t get below 4.7.1 as a minimum requirement. It was released almost two years ago and does support even Windows 7, so we feel this is an acceptable compromise. Please do let us know in case this is a problem for a deployment in your environment.

Internet Explorer / Web-View requirements

Our old add-in already used web views for rendering all parts of the UI. However, we bundled a custom version of Google Chrome, which we unfortunately were not able to update along the way. Therefore, as new versions of Windows and Office were released, this proved a liability, since it made Outlook unstable (more on this later). The new version uses Internet Explorer 11 web views, or, if certain criteria are met, Microsoft Edge. You can read more about this here: COM Addin Details. Therefore, IE 11 is a hard requirement for the new add-in to work correctly.

Performance & Stability

If you deployed the old version of the add-in across many clients, you probably heard the occasional “My Outlook crashed” story. We did too, so we needed to do something about this. There was no easy fix, since this had a variety of reasons, some based on core technology decisions we made with the old add-in. We tried to fix all of this with the new versions and are pretty confident we did.

The main problem was the aforementioned web view runtime. We used a custom version of Google Chrome, shipped with our add-in, since at the time we built the original version, the Internet Explorer web view was in no place to be at all useful. We would argue it’s still not, but as Microsoft also uses this view in their modern Office add-ins, so it’s a target browser we need to support anyway. In recent versions of Windows 10 (1809+) we are also able to use Microsoft Edge, which offers much improved performance.

The problem with the old add-in was also, that the web views were loaded into the Outlook process, which increased the memory consumption of Outlook right from the start by a huge margin. Also, when a critical error occurred, Outlook would just crash, leaving us no option to catch or mitigate the problem. To solve this issue, we additionally moved all web-view related UI parts into an own process. In the installation folder of the new add-in, you’ll be able to see two new .exe-files:

• jiraDialogHost.exe (uses IE 11 web view)

• jiraDialogHostEdge.exe (uses Microsoft Edge web view)

If you open the new sidebar or open a dialog (e.g. New Issue), the actual rendering will be done by a new process, based on these files. This allows us to keep the main Outlook process as lean as possible, massively decreasing the required memory. These render processes are also very fault-tolerant (they will just restart, leaving Outlook untouched) and short lived, making it possible to re-gain memory often.

Of course, there cannot be only upsides, so on older machines with a low performance, you might see some regressions:

• Opening a dialog (e.g. New Issue) takes a bit more time than before, since a new process is started

• IE 11 is not as fast as even the old version of Chrome we used before, so it might take a bit longer to render dialogs + the sidebar

We will work to improve this in the future, but we decided to prioritize stability and performance of all other tasks you do in Outlook, over a bit of performance in our UI.

Features

To learn about what changes have been made to user-facing features, please check out our non-admin article on the new version: User Guide: What's new.

Installation / Deployment

As with version 2, there are two variants of the COM add-in installer (see below), both available as either .exe or .msi file. The .exe-file does contain a bootstrapper, which will make sure that all required dependencies are installed. If you are using the .msi-file, you will need to make sure all requirements are available manually. For more detailed information, please check our deployment guide.

Per-User Installer - RECOMMENDED

This installer is usually the best way for small to midsize companies, without a central IT department managing a software roll-out. It can be installed by each user individually and requires no administrative rights to install.

It also comes with an automatic updater, which will keep it updated with the latest fixes & features.

Per-Machine Installer

This installer is best suited if you are using a Citrix/Terminal Server environment, or if your IT department is managing the software roll-out centrally. This version has no automatic update, so you have more control on how the software behaves.

Automatic Update

We are planning on rolling out v3 to users of the old Outlook add-in via the automatic updater by the end of the year (current estimate). The roll-out of this update will not be fully automatic, as we are aware this is quite a big change to test and communicate to your users. Therefore, before updating the Outlook add-in from v2 → v3, we will require a sign-off from a Jira administrator, that the update should be deployed. This will give you full control over the update schedule.

We will communicate the availability of the automatic update via our newsletter and the release notes of the Marketplace app, we recommend watching the app in the Atlassian Marketplace to be notified of updates.

Changes Jira App

This section covers topics that are related to the Jira admin part & settings of the app.

Licensing

In the past we have been pretty liberal when it came to updates to the Outlook add-in - even if you did not have an active supported license, we rolled out fixes to everyone more often than not. The update to this new version will however require an active license, with support. The Atlassian Marketplace will allow you to renew your subscription, or if necessary, purchase a new license. Though this is standard practice when it comes to Jira apps, we still want to mention this, because the Outlook add-in technically is a separate piece of software.

Breaking Changes

Before you update the Jira Server / Jira DataCenter app from the Atlassian Marketplace, please be aware that there is one breaking change. If you have active templates (e.g. for defaulting values) that are being used in the old Outlook add-in, you will not be able to adjust those templates anymore with the new Jira app.

During the update, the Jira app will migrate the existing templates to a new format and save them in your Jira instance. Going forward, the new Outlook add-in only use these locally stored templates, whereas the old add-in will still use our server to access the templates.

There should be no other breaking changes, so if you are not using templates, you should be free to just update the Jira app.

Application Link

During the update, we will create a new application link (on Jira Server / DataCenter). This application link will be used by the new Outlook add-in. The old version will continue to use the existing application link.