Andrei Smolin

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.


  • 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

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#)


  • Eugene Astafiev says:

    Hi Andrei,

    As always, good thoughts! Microsoft gives add-in developers a big red flag simply saying be ready for changes and don’t expect COM add-ins working for store apps. This awkward support for COM add-ins in the bridge edition looks like somebody forgot to cut the functionality in a hurry…

    The “Desktop bridge” editions of Office apps are not the same as the Universal Windows Platform (UWP) versions of the Office apps that were in the Store. Microsoft representatives wrote a year ago that they intended to reposition the UWP Office apps as Office Mobile apps recommended for phones and tablets with screen sizes less than 10.1 inches.

    Do you think COM add-ins will be supported in the final releases (not bridge) of Office apps? ;)

  • Dmitry Kostochko (Add-in Express Team) says:

    Hi Eugene,

    Thank you for sharing your thoughts!

    I personally think that COM add-ins will be supported. Will see… :)

  • Suleman Muqeed says:

    Hi Andrei,

    Thank you for sharing such important information. I was looking for what limitations this new office might bring.

    Can you please tell me how can I get the sample plugin? I’m not able to download it. Is it necessary for me to be an active ADD-IN EXPRESS user to test it?

  • Andrei Smolin (Add-in Express Team) says:

    Hello Suleman,

    You can download a trial version of Add-in Express for Office and .net from the Visual Studio Marketplace. You don’t need to be an Add-in Express customer to install the trial version.

  • Fabrice says:

    Do you know how we can detect (in our add-in) that we’re using office installed from store ?

  • Andrei Smolin (Add-in Express Team) says:

    Hello Fabrice,


    Note that our testers report that it is impossible to install the Microsoft Store flavor of Office any longer: such an attempt ends with installing a regular Click-to-Run Office. In other words, it looks like Microsoft either abandoned that idea or delayed it for a while.

  • Fabrice says:

    Hello Andrei,
    Thank you for your reply.
    We still have customers with new laptop and Office from store installed. I still need to investigate how these Office get installed (maybe from an disk image) but currently we’re still facing the problem.

  • Andrei Smolin (Add-in Express Team) says:

    Hello Fabrice,

    We don’t have that Office version. We have a few end user stories: they tried to solve some problem(s) and called Microsoft supporters who removed the Microsoft Store version and installed a regular Click-to-Run version of Office.

  • Varun Sharma says:

    Hello Andrei,
    Thank you for sharing such an amazing and informative article with us.

  • Brandon says:

    The MS Store version has issues with shared or network drive locations. Saving to shared drives throws permission issues as soon as the click-to-run version is installed no issues at all. Has anyone been able to work around that?

Post a comment

Have any questions? Ask us right now!