Category Archives: Web Development
One of the critical components of an Office Add-in is the add-in manifest. This is the xml file that describes how your add-in should be activated when an end user installs and uses it with Office documents and applications. This manifest contains references to URLs where your web application resides and also to other resources for your add-in such as images to show on ribbon buttons and task panes.
Your manifest.xml file is uploaded to a central location where it is made available to users of your add-in (this may be a public location such as AppSource or the Office Store).
When users acquire your add-in a copy of the manifest.xml file is cached onto the host device and is only periodically resynced if the manifest.xml file is subsequently updated in AppSource/Office Store. I have seen this take weeks on some combinations of host products/devices.
You need to be careful if you are modifying your application and the changes involve modifications to the URLs in the manfiest.xml file. Imagine your add-in has been deployed and is in use by many users. The manifest.xml file might look similar to the fragment below (notice the SourceLocation URL on line 13).
That SourceLocation URL (line 13) is the main page of the add-in that gets loaded into the Task Pane when the add-in is launched. Lets imagine you change the structure of this add-in so that the starting page of the app is now https://www.contoso.com/apps/search/index.html
How do you go about deploying the updated manifest file that points to this new URL?
If you update the manifest.xml file with the new URL you then have to go through the AppSource/Office Store submission process to get the new manifest approved. You are far from 100% in control of the approval process so you don’t know when the new manifest will get approved and thus when the new URL will come into effect. So do you need to keep your application running at both the old and the new URL at least until the new manifest is approved? It gets a little worse than that though, it seems the deployment of a manifest change can take weeks to reach “saturation” whereby it had propagated down to all client host product caches and the old manifest is no longer being used. I can’t exactly tell you how long this process takes and if it ever fully reaches “saturation” as I’m still seeing some users hitting my service on a URL in a manifest that was superseded almost 3 months ago!
Rather than keeping your old and new application running side by side, the approach I have taken that works quite nicely is to put in place temporary redirects from any URLs that were present in the old manifest and have changed in the new manifest. I suggest creating these as temporary redirects as you will be able to monitor your traffic over time and know when you have reached saturation and you stop getting users coming in on URLs from old manifests. If you use permanent redirects, this may get cached by the client and next time the client will have done the redirect itself and you will no longer be able to track if the new manifest has been deployed or it’s an old manifest being redirected via a client side cached redirect.
How do you go about implementing temporary redirects? Well this depends on what you’ve developed your website using and how you are hosting it. In my case I am hosting the app as a Web App in Azure, redirects can be configured in the web.config file that is located in the root folder of the Web App.
Below is an example web.config file that would achieve that temporary redirection.
I still find styling HTML elements difficult at times, trying to figure out where the styling is being inherited from and exactly which elements I need to apply styles to. The Developer Tools in Chrome go a long way to assisting with this. For this tip I’ll assume you are familiar with Chrome Developer Tools for inspecting HTML elements and CSS styles.
What I wanted to focus on was those frustrating elements that only exist on the page (in the Document Object Model) while a certain element has the “focus”. This often happens with navigation menu options or dropdown controls, where you have the menu options or dropdown options visible on the screen but as soon as you click something in Developer Tools (to go exploring), the menu options or dropdown options disappear and don’t exist on the page anymore! This is usually because an event such as the blur event is fired when you click outside the element and this removes the elements from the page that you are trying to inspect.
This tip might not work in all scenarios but it has gotten me out of trouble on a few occasions.
Here’s an example scenario. On the left side of the screenshots you can see the OnePlaceMail (Outlook Add-in) displayed in Chrome, on the right hand side is Developer Tools inspector window. I’m using a 3rd party control for my “Content Type” dropdown (it’s the Kendo UI for Angular library)
When collapsed it’s easy to inspect the kendo-dropdownlist element (that holds the selected value of ‘Document’. At this stage the menu options that will appear when I click on the dropdown don’t even exist in the DOM.
When I do click to expand the dropdown, the image below shows that a new kendo-popup element appears in the DOM (and it contains sub-elements to represent each of the options). But the problem is if we now try to use the Developer Tools and expand that kendo-popup element to see those sub-elements then the dropdown collapses (because I’ve click off it) and the kendo-popup element is removed from the DOM and we’re left with nothing to inspect!
So to work around this in the Developer Tools inspector, right click on the element that is driving the elements to appear/disappear (kendo-dropdownlist) and select Break on | subtree modifications.
Now go to the web page and click on the dropdown to show the dropdown options. They are shown (elements added to the DOM) but the Developer Tools inspector now goes into a paused state. The web page is effectively frozen.
While in this paused state, you can now return to the elements tab and we can expand and explore that pesky kendo-popup element that was dynamically created. This time however the dropdown won’t collapse itself as we click around in the inspector.
I hope you find this tip useful