Recently, I have started to develop an Excel Web Add-in. When I first created the project in Visual Studio and tried to run the project, Visual Studio kept insisting that the application associated with this project type isn’t installed on this computer. Now I know that it isn’t true, since I was the one installing it. I thought maybe it is caused by the fact, that my Office version isn’t correct, or perhaps it is not running in English which messes with Visual Studio. While searching, I found this question on Microsoft Q&A asking the same question, but the user went one step further, and analyzed the file system actions Visual Studio take with Process Monitor from Sysinternals—a step I usually also do in desperation—
and highlighted access to a peculiar path:
C:\Users\user\AppData\Local\Microsoft\WindowsApps\Microsoft.Office.Desktop_8wekyb3d8bbwe\excel.exe
I tried it out as well, and it was the same for me, based on what the user shared, but I also noticed that Visual Studio first probes for the path. While the folder existed for me as well, it was empty. What is this? If you are only interested in an answer, then go to the answer I give to the question or read the conclusion of this page. If you want to see the basis of my reasoning for my actions, you can read about my knowledge on
the matter in this article.
Brief History of Known Path in Windows
One important aspect of an operating system, especially nowadays, is to be able to host multiple users in a single installation, which has been an important aspect since the dawn of computers, especially in a business setting. We don’t want users to mess with files that aren’t their own, especially to cruicial system files.
We want them to be able to execute applications, we just don’t want them to initiate a command something like format c: /y or cat /dev/null > /dev/sda, both of which will erase your drive and the later even wipe your primary hard drive clean, so it is obvious that you shouldn’t do it. To limit their access, we can set permission on files and folders, and to make our life easier, the operating system groups certain files based on future usage of the files, while also can set up exceptions, if the provided system is not suitable—though it usually is. There is a lot more to this, but here I am solely focusing on the file system structure. Before Universal Windows Programs Windows 1 through 3.1 wasn’t such a system, and users didn’t even appear until Windows 3.11. In fact, it wasn’t even its own operating system until Windows NT 3.5, or the more popular version, Windows 95, and later Windows NT 4. Windows 3.11 introduced networking functionality and
was only capable of handling users for networking purposes and had no effect of user isolation.
These versions didn’t have much of a folder structure either, storing everything under C:\Windows, except third-party applications, which were installed under their own folder of the root of C: drive. Well, C:\Windows was partitioned further, but it was so long ago I have ever used Windows 3.11, that I cannot trust my memory on that.
Since Windows 95, for every developer dismay, a system wide folder tree was introduced, with various known folder location, but for this article, I am focusing on three:
This makes me wonder. Could we install application by default under C:\Users\user\AppData\Roaming\Programs? Roaming local app data “travels with you” when you switch PC within the same domain your username is assigned to. Though home users can’t really utilize this, nor is it recognized by Windows as a known path.
After Universal Windows Programs
Microsoft with Windows 8 and later Windows 10 wanting to be “everything at once,” introduced Universal Windows Programs (UWP) to make programmers life easier by letting them write a single program and allow that program to be run on a supported list of architectures. The programs are now being reinterpreted as application packages, similarly to what you would have on Android or iOS, and are now further isolated from the system, so these applications are less likely to harm your system or your personal files. To allow this, Microsoft introduced new sets of folders for these, to most of which you have limited access, but usually you wouldn’t even want to access them under normal circumstances, as it is only needed by the applications to function.
I found it neat, that there is a near parallel in the structuring of UWPs with classic windows programs.
Interjection: Python from the Microsoft Store
Interestingly, I found a python.exe file under my C:\Users\user\AppData\Local\Microsoft\WindowsApps folder, which is a symbolic link to the following path: c:\Program Files\WindowsApps\Microsoft.DesktopAppInstaller_1.19.10173.0_x64__8wekyb3d8bbw\AppInstallerPythonRedirector.exe
Executing this opens the Microsoft Store page for… not the latest Python available interestingly. Installing the Python app (even the latest) will change the link to execute the installed Python version instead. I am not sure if this is only happening for me, but it appears that this is an intended functionality of the App installer, which is a part of Windows. Either way, it is neat! I wouldn’t be surprised if this were the intended way Office worked too.
Microsoft Office Store Apps
Since the release of Windows 8, Microsoft tried to push their Office suite to the Microsoft Store, mainly for their mobile users at first. With Windows 10, they offered OneNote as a replacement for the prior Sticky Notes application, and as a gap filler for those Windows versions that could not support Cortana. Of course, since then the Sticky Notes apps returned due to popular demand. While the Desktop versions didn’t really seem to fully transition there, there still was a time where the Office apps with limited interface for mobile devices were also available for the desktop, that I have also downloaded on my PC. You no longer can download these apps to the desktop version of Windows, but I still have them. Microsoft since switched to release the Office suite on its own channel, and changed so the Microsoft Store page instead leads to the Microsoft Office Marketplace, where you could subscribe to use Office. However, the presence of this conflicting path being empty, and I still have the mobile version of the office apps, it is quite possible, that this folder is meant to be for the desktop application distributed through the Microsoft Store.
Conclusion
In the back-and-forth they did in their decision with the Microsoft Office release, and the consideration of the path used in the folders it is quite possible that in preparation for an Office version installed through the Microsoft Store, Visual Studio started supporting a path that was abandoned since, if was ever used. And since it is in the user’s local application data path, which is for storing configuration files, it is not something that must be removed, as a configuration file or blank folder on its own will not hinder your PC. But, since the path exists, and the application isn’t there, Visual Studio confuses the presence of the path with a valid Office installation and attempts to execute an application, that isn’t there. I have Microsoft Office 365 installed, and an empty folder is in no means meaningful in a program that works. Deleting it only be an issue, if the next update would restore the folder, but then I would have found it on my other brand-new laptop, which was not the case, so I go and delete the Microsoft.Office.Desktop_8wekyb3d8bbwe folder. Now running the project opens Excel with the add-on.
Under any other circumstances, the most ideal way to fix this issue would have been to first uninstall Office, then delete the folder, then reinstall Office, and then check if the folder appeared. If it did, then one must send an issue ticket mostly for Visual Studio, but also probably to the Office team.
