Office from Microsoft Store: a spreading source of issues

The number of users having the Office version installed from Microsoft Store increases every day as computer vendors install it by default; see e.g. this support article from Dell.

Per-user add-ins and some per-machine add-ins may run into a severe issue with that Office version.

The issue is: the add-in uses old versions of files or registry keys/values after you install an add-in update.

Prerequisites:

• Office from Store is installed.
• An add-in installer creates a file in AppData or registry key in HKCU.
• The host application, the add-in itself or the user (via the host UI) modify that file or registry key while working.

In this blog, we describe the issue in detail and demonstrate some experiments. In the next blog, we’ll discuss workarounds.

Office installation details

Install Microsoft Office from Microsoft Store. To make sure you have this version, start any Office application (e.g. Excel) and open File | Account. The version string mentions Microsoft Store:

We’ve found out that each Office application gets installed as an app package similar to what is described in Behind the scenes of your packaged desktop application on docs.microsoft.com.

Say, according to that page, each app package provides an AppxManifest.xml of its own. Indeed, you can start Excel and use File | Open | Browse to locate that file in this folder(s): C:\Program Files\WindowsApps\Microsoft.Office.Desktop.{Office application name such as Outlook}_{version string such as 16051.11231.20174}.0_x86__{a GUID-like string}.

Office from Store is only available as a 32bit application.

How Office from Store deals with files and registry keys

The page above explains how such an app package works with the registry and file system:

All writes to the user’s AppData folder (e.g., C:\Users\user_name\AppData), including create, delete, and update, are copied on write to a private per-user, per-app location. This creates the illusion that the packaged application is editing the real AppData when it is actually modifying a private copy.

All writes under HKCU are copy-on-written to a private per-user, per-app location. Traditionally, uninstallers are unable to clean HKEY_CURRENT_USER because the registry data for logged out users is unmounted and unavailable.

An experiment with files

I’ve written a simple add-in and Windows Forms application sharing almost the same code; the code lets me read/create/delete the text file located in Environment.GetFolderPath(Environment.SpecialFolder.LocalApplicationData) + @"\" + @"MyTest.txt" (VB.NET developers should omit the @). The difference is that when the file is created, the add-in and the application write different text in it; when the file is read, the text lets me identify the origin of the file.

I start the test application and create the file. I start the Office host application and read the file; this works as expected: the add-in reads the file created by the test application. Now the add-in deletes the file; the test application can still read it; this is in agreement with the citation above. The strange thing is that the test application cannot delete the file since it is “locked by some other process”. I close the Office host application; now the test application deletes the file with no problem. I start the Office host and find that the add-in and the test application now independently operate (create/update/delete) on two different files having the same path and name; the files have different contents as specified by the above-mentioned difference in code.

An experiment with the registry

A test add-in is registered and loaded. I open the COM Add-ins dialog and turn the add-in off; as you know, this modifies LoadBehavior in HKCU\Software\Microsoft\Office\{Excel or any other Office application here}\Addins\{your add-in}; that is, this modifies this key. I close the host application, unregister the add-in, start the host and find the add-in missing in the host’s UI. That’s expected. Now I close the host, register the add-in, start the host: there’s no add-in in the UI. This isn’t something that you would expect with a “normal” Office.

I run a VBA macro that checks Application.COMAddins(strMyaddinProgId).Connect. If run in the host application of my test add-in, it reports that the test add-in is off; this is exactly what I see in the host’s UI. If run in another Office application (=outside of the host application of my test add-in), the macro reports that the add-in is on.

A side note: you should be aware that accessing properties of Office.COMAddin may produce an exception if you do this outside of the host.

Also note that Add-in Express modifies the ADXStartMode value in the key above when the add-in is loaded for the first time. With Office from Store this means the key itself immediately becomes copied to the private store and no code external to the host application is able to turn the add-in off.

A performance test

The experiment with the registry made me check the performance. Here’s a method that fills cells in Excel and prints time stamps; the method is for demonstration purposes only:

Sub FillCells(ExcelApp As Excel.Application)
Dim dt As Date, dt2 As Date
    dt = Now
Dim i As Integer, j As Integer
    For i = 1 To 1000
        For j = 1 To 200
            ExcelApp.Cells(i, j).Value = i + j
        Next j
    Next i
    dt2 = Now
    Debug.Print dt, dt2
End Sub

On a test machine with Office from Store installed it takes 4 seconds to run that method. I would expect it to be run a bit faster; still no surprise here. When run from Word, the same VBA macro reports 6 stunning minutes!

Another experiment with files

The test add-in is installed in AppData. I start the host and check files in the add-in installation folder: open any FileOpen dialog, navigate to the installation folder, make sure that the dialog uses the All Files (*.*) filter. Now, I close the host, uninstall the add-in, start the host and check the add-in files: you’ll see that all or some of the files are still present.

An experiment with folders

No code is involved. I start the host application and use any FileOpen dialog to create a folder named FOLDER1 under AppData; I use the same dialog to create SubFolder1 under FOLDER1. Then I start the File Explorer (Windows Explorer) and create a folder named FOLDER1 under AppData; this step is impossible if the normal Office is used. Anyway, I create SubFolder2 under FOLDER1 in File Explorer. Now I open any FileOpen dialog in the host application, navigate to FOLDER1 and see SubFolder1 only.

Discussing the experiments

You can imagine two stores for AppData and HKCU: private and common. In these terms, all applications (e.g. an installer) use the common store. The Office host saves all changes to the private store and then looks for them in the private store ignoring the common store.

Getting two different copies of the same file implies that your update installer is unable to update a file modified by the add-in, host application or the user (if the change is done via the host)! Consider the add-in settings stored in a file. Getting the file locked and an uninstalled add-in’s files still visible by the host means that the host application must be closed while your add-in is being updated and this is an absolute must!

As you can see, the modified registry key produces the same issue: you are unable to modify it while updating the add-in. Consider the add-in settings stored in HKCU or the add-in turned off by the Office application. As you can see, you won’t be able to turn the add-in on (or off) from an installer; you can only do this from a service add-in, or you’ll need the user to do this manually. I suppose there should be policies that allow doing this but there’s no documentation confirming this idea.

Oh, do you have an experiment to suggest?

The sample add-in

We provide a solution containing a sample add-in project (C#) and a setup project. To rebuild the add-in project, you must have Add-in Express installed. To rebuild the setup project, you must have Visual Studio Installer. This tool is built in VS 2010. For VS 2013, you need to install this extension; for VS 2015, see here; for VS 2017, see here. There’s no such extension for VS 2012.

You may choose not to rebuild anything: just use the installer located in {ZIP}\ TestAddinForOfficeFromStore\TestAddinForOfficeFromStoreSetup\1.0.0\Debug.

This add-in displays two buttons: Toggle Button 1 and Toggle Button 2. To set the state of Button 1 at startup, the add-in reads settings from a file in the add-in installation folder (by default, this folder is in AppData); the state of Button 2 is read from HKCU\Software\Default Company\TestAddinForOfficeFromStore\Settings.

Modify the states of the buttons and click Save Settings. Then restart Excel: the button states should be preserved. Now uninstall the add-in; with the normal Office, this removes the file and the registry key. Install the add-in once again; with the normal Office, this creates the file and registry key. Start Excel and find the default settings not applied; instead, the add-in uses the last saved settings.

This is okay to get settings preserved. But the same issue (settings are not updated by the installer) will not let you introduce new settings.

Will discuss possible solutions soon.

Available downloads:

This sample COM add-in for Excel was developed using Add-in Express for Office and .net:

Sample Excel add-in project with installer (C#)