I recently started developing an Excel web add-in. When I first created the project in Visual Studio and tried to run it, Visual Studio insisted that the application associated with this type of project was not installed on this computer. Now I know that’s not true, since I installed it myself. I thought maybe it’s because my Office version isn’t correct, or maybe it’s not running in English, which is messing up Visual Studio. Searching, I found this question on Microsoft Q&A asking the same question, but the user went a step further and analysed Visual Studio’s file system actions with Process Monitor from Sysinternals – a step I usually take in desperation too – and showed a strange access to the file system.
and showed access to a strange path:
C:UsersUserAppDataLocalMicrosoftWindowsAppsMicrosoft.Office.Desktop_8wekyb3d8bbweexcel.exe
I tried it too, and it was the same for me based on what the user shared, but I also noticed that Visual Studio looks for the path first. The folder existed for me too, but was empty. What is the reason for 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 know how I justified my actions, you can read this article to find out what I know about this topic.
Brief history of Known Path in Windows
An important aspect of an operating system, especially nowadays, is the ability to accommodate multiple users in a single installation, which has been an important aspect since the dawn of computers, especially in organisations. We don’t want users to handle files that are not their own, especially important system files.
We want them to be able to run applications, we just don’t want them to issue a command like format c: /y or cat /dev/null > /dev/sda, both of which would wipe your drive and in the latter case even render your primary hard drive unusable. To restrict access, we can set permissions on files and folders, and to make our lives easier, the operating system groups certain files based on their future use, though it can also set up exceptions if the intended system is not suitable – which it usually is. There’s much more, but here I’m focusing solely on the file system structure. Before Windows Universal Programmes, there was no such system in Windows 1 to 3.1, and users didn’t appear until Windows 3.11. In fact, it wasn’t even a separate operating system until Windows NT 3.5 or the more popular Windows 95 and later Windows NT 4 came along. Windows 3.11 introduced networking functionality and was only able to manage users for networking purposes, but had no impact on user isolation.
These versions also didn’t have much of a folder structure and stored everything under C:Windows, except for third-party applications, which were installed in their own folder in the root of the C: drive. Now, C:Windows was more compartmentalised, but it’s been so long since I used Windows 3.11 that I can’t trust my memory.
Since Windows 95, a system-wide folder tree has been introduced, to the chagrin of all developers, with various known folder locations, but for this article I will concentrate on three:
This makes me think. Could we install the application by default under: C:UsersuserAppDataRoamingPrograms ? Local roaming application data ‘travels with you’ when you change PCs within the same domain that your username is assigned to. However, home users cannot really use this and it is not recognised by Windows as a known path.
After Universal Windows programmes
With Windows 8 and later Windows 10, Microsoft wanted to be ‘everything at once’ and introduced Universal Windows Programs (UWP) to make life easier for programmers by allowing them to write a single program and run that program on a list of supported architectures The programs are now reinterpreted as application packages, similar to Android or iOS, and are now further isolated from the system so that these applications are less likely to damage your system or personal files To enable this, Microsoft has introduced new sets of folders for these applications, most of which you have limited access to, but which you may not even want to access under normal circumstances as they are only required by the applications to function.
I found it quite nice that there are almost parallels to classic Windows programmes in the structuring of UWPs.
Interjection: Python from the Microsoft Store
Interestingly, I found a python.exe file under my C:UsersuserAppDataLocalMicrosoftWindowsApps folder, which is a symbolic link to the following path: c:Program FilesWindowsAppsMicrosoft.DesktopAppInstaller_1.19.10173.0_x64__8wekyb3d8bbwAppInstallerPythonRedirector.exe
When you run this, the Microsoft Store page opens for… interestingly, it does not open the latest Python available. When installing the Python app (even the latest one), the link is changed to run the installed Python version instead. I’m not sure if this is just me, but it seems that this is an intended feature of the app installer that is part of Windows. Either way, it’s awesome! I wouldn’t be surprised if this was the intended functionality of Office as well.
Microsoft Office Store applications
Since the release of Windows 8, Microsoft has been trying to bring its Office suite to the Microsoft Store, initially mainly for its mobile users. With Windows 10, OneNote was offered as a replacement for the previous Sticky Notes app and as a stopgap for those versions of Windows that could not support Cortana. Of course, the Sticky Notes apps have since returned due to popular demand. While the desktop versions don’t really seem to have fully transitioned, there was still a time when the Office apps with limited interface for mobile devices were also available for desktop, which I also downloaded to my PC. You can no longer download these apps to the desktop version of Windows, but I still have them. Microsoft has since switched to releasing the Office suite through its own channel, and has changed the Microsoft Store page to lead to the Microsoft Office Marketplace instead, where you can sign up to use Office. However, since this contradictory path is empty and I still have the mobile version of the Office apps, it’s quite possible that this folder is for the desktop app that is distributed through the Microsoft Store.
Conclusion
With the back and forth they did in their decision with the Microsoft Office version, and looking at the path used in the folders, it’s quite possible that Visual Studio started supporting a path in preparation for an Office version installed via the Microsoft Store that has since been abandoned, if it was ever used. And since it is in the user’s local application data path, which is used to store configuration files, there is no need to remove it, as a configuration file or empty folder will not by itself affect your PC. However, because the path exists but the application does not, Visual Studio mistakes the presence of the path for a valid Office installation and attempts to run an application that does not exist. I have Microsoft Office 365 installed, and an empty folder makes no sense at all in a programme that works. Deleting it would only be a problem if the next update restored the folder, but then I would have found it on my other brand new laptop, which wasn’t the case, so I go and delete the Microsoft.Office.Desktop_8wekyb3d8bbwe folder. Now when I run the project, Excel opens with the add-on.
Under all other circumstances, the most ideal way to resolve this issue would have been to first uninstall Office, then delete the folder, then reinstall Office and then check to see if the folder reappears. If this is the case, you need to send a problem ticket primarily for Visual Studio, but probably also to the Office team.
I recently started developing an Excel web add-in. When I first created the project in Visual Studio and tried to run it, Visual Studio insisted that the application associated with this type of project was not installed on this computer. Now I know that’s not true, since I installed it myself. I thought maybe it’s because my Office version isn’t correct, or maybe it’s not running in English, which is messing up Visual Studio. Searching, I found this question on Microsoft Q&A asking the same question, but the user went a step further and analysed Visual Studio’s file system actions with Process Monitor from Sysinternals – a step I usually take in desperation too – and showed a strange access to the file system.
and showed access to a strange path:
C:UsersUserAppDataLocalMicrosoftWindowsAppsMicrosoft.Office.Desktop_8wekyb3d8bbweexcel.exe
I tried it too, and it was the same for me based on what the user shared, but I also noticed that Visual Studio looks for the path first. The folder existed for me too, but was empty. What is the reason for 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 know how I justified my actions, you can
read this article to find out what I know about this topic.
Brief history of Known Path in Windows
An important aspect of an operating system, especially nowadays, is the ability to accommodate multiple users in a single installation, which has been an important aspect since the dawn of computers, especially in organisations. We don’t want users to handle files that are not their own, especially important system files.
We want them to be able to run applications, we just don’t want them to issue a command like format c: /y or cat /dev/null > /dev/sda, both of which would wipe your drive and in the latter case even render your primary hard drive unusable. To restrict access, we can set permissions on files and folders, and to make our lives easier, the operating system groups certain files based on their future use, though it can also set up exceptions if the intended system is not suitable – which it usually is. There’s much more, but here I’m focusing solely on the file system structure. Before Windows Universal Programmes, there was no such system in Windows 1 to 3.1, and users didn’t appear until Windows 3.11. In fact, it wasn’t even a separate operating system until Windows NT 3.5 or the more popular Windows 95 and later Windows NT 4 came along. Windows 3.11 introduced networking functionality and was only able to manage users for networking purposes, but had no impact on user isolation.
These versions also didn’t have much of a folder structure and stored everything under C:Windows, except for third-party applications, which were installed in their own folder in the root of the C: drive. Now, C:Windows was more compartmentalised, but it’s been so long since I used Windows 3.11 that I can’t trust my memory.
Since Windows 95, much to the chagrin of all developers, a system-wide folder tree was introduced, with various known folder locations, but for this article I’ll focus on three:
This makes me think. Could we install the application by default under: C:UsersuserAppDataRoamingPrograms ? Local roaming application data ‘travels with you’ when you change PCs within the same domain that your username is assigned to. However, home users cannot really use this and it is not recognised by Windows as a known path.
After Universal Windows programmes
With Windows 8 and later Windows 10, Microsoft wanted to be ‘all things at once’ and introduced Universal Windows Programs (UWP) to make life easier for programmers by allowing them to write a single program and run that program on a list of supported architectures. The programs are now reinterpreted as application packages, similar to Android or iOS, and are now further isolated from the system so that these applications are less likely to damage your system or personal files. To enable this, Microsoft has introduced new sets of folders for these applications, most of which you have limited access to, but which you may not even want to access under normal circumstances as they are only required by the applications to function.
I found it quite nice that there are almost parallels to classic Windows programmes in the structuring of UWPs.
Interjection: Python from the Microsoft Store
Interestingly, I found a python.exe file under my C:UsersuserAppDataLocalMicrosoftWindowsApps folder, which is a symbolic link to the following path: c:Program FilesWindowsAppsMicrosoft.DesktopAppInstaller_1.19.10173.0_x64__8wekyb3d8bbwAppInstallerPythonRedirector.exe
When you run this, the Microsoft Store page opens for… interestingly, it does not open the latest Python available. When installing the Python app (even the latest one), the link is changed to run the installed Python version instead. I’m not sure if this is just me, but it seems that this is an intended feature of the app installer that is part of Windows. Either way, it’s awesome! I wouldn’t be surprised if this was the intended functionality of Office as well.
Microsoft Office Store applications
Since the release of Windows 8, Microsoft has been trying to bring its Office suite to the Microsoft Store, initially mainly for its mobile users. With Windows 10, OneNote was offered as a replacement for the previous Sticky Notes app and as a stopgap for those versions of Windows that could not support Cortana. Of course, the Sticky Notes apps have since returned due to popular demand. While the desktop versions don’t really seem to have fully transitioned, there was still a time when the Office apps with limited interface for mobile devices were also available for desktop, which I also downloaded to my PC. You can no longer download these apps to the desktop version of Windows, but I still have them. Microsoft has since switched to releasing the Office suite through its own channel, and has changed the Microsoft Store page to lead to the Microsoft Office Marketplace instead, where you can sign up to use Office. However, since this contradictory path is empty and I still have the mobile version of the Office apps, it’s quite possible that this folder is for the desktop app that is distributed through the Microsoft Store.
Conclusion
With the back and forth they did in their decision with the Microsoft Office version, and looking at the path used in the folders, it’s quite possible that Visual Studio started supporting a path in preparation for an Office version installed via the Microsoft Store that has since been abandoned, if it was ever used. And since it is in the user’s local application data path, which is used to store configuration files, there is no need to remove it, as a configuration file or empty folder will not by itself affect your PC. However, because the path exists but the application does not, Visual Studio mistakes the presence of the path for a valid Office installation and attempts to run an application that does not exist. I have Microsoft Office 365 installed, and an empty folder makes no sense at all in a programme that works. Deleting it would only be a problem if the next update restored the folder, but then I would have found it on my other brand new laptop, which wasn’t the case, so I go and delete the Microsoft.Office.Desktop_8wekyb3d8bbwe folder. Now when I run the project, Excel opens with the add-on.
Under all other circumstances, the most ideal way to fix this problem would have been to first uninstall Office, then delete the folder, then reinstall Office and then check if the folder reappears. If this is the case, you need to send a problem ticket primarily to Visual Studio, but probably also to the Office team.
I recently started developing an Excel web add-in. When I first created the project in Visual Studio and tried to run it, Visual Studio insisted that the application associated with this type of project was not installed on this computer. Now I know that’s not true, since I installed it myself. I thought maybe it’s because my Office version isn’t correct, or maybe it’s not running in English, which is messing up Visual Studio. Searching, I found this question on Microsoft Q&A asking the same question, but the user went a step further and analysed Visual Studio’s file system actions with Process Monitor from Sysinternals – a step I usually take in desperation too – and showed a strange access to the file system.
and showed access to a strange path:
C:UsersUserAppDataLocalMicrosoftWindowsAppsMicrosoft.Office.Desktop_8wekyb3d8bbweexcel.exe
I tried it too, and it was the same for me based on what the user shared, but I also noticed that Visual Studio looks for the path first. The folder existed for me too, but was empty. What is the reason for 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 know how I justified my actions, you can read this article to find out what I know about this topic.
Brief history of Known Path in Windows
An important aspect of an operating system, especially nowadays, is the ability to accommodate multiple users in a single installation, which has been an important aspect since the dawn of computers, especially in organisations. We don’t want users to handle files that are not their own, especially important system files.
We want them to be able to run applications, we just don’t want them to issue a command like format c: /y or cat /dev/null > /dev/sda, both of which would wipe your drive and in the latter case even render your primary hard drive unusable. To restrict access, we can set permissions on files and folders, and to make our lives easier, the operating system groups certain files based on their future use, though it can also set up exceptions if the intended system is not suitable – which it usually is. There’s much more, but here I’m focusing solely on the file system structure. Before Windows Universal Programmes, there was no such system in Windows 1 to 3.1, and users didn’t appear until Windows 3.11. In fact, it wasn’t even a separate operating system until Windows NT 3.5 or the more popular Windows 95 and later Windows NT 4 came along. Windows 3.11 introduced networking functionality and was only able to manage users for networking purposes, but had no impact on user isolation.
These versions also didn’t have much of a folder structure and stored everything under C:Windows, except for third-party applications, which were installed in their own folder in the root of the C: drive. Now, C:Windows was more compartmentalised, but it’s been so long since I used Windows 3.11 that I can’t trust my memory.
Since Windows 95, a system-wide folder tree has been introduced, to the chagrin of all developers, with various known folder locations, but for this article I will concentrate on three:
This makes me think. Could we install the application by default under: C:UsersuserAppDataRoamingPrograms ? Local roaming application data ‘travels with you’ when you change PCs within the same domain that your username is assigned to. However, home users cannot really use this and it is not recognised by Windows as a known path.
After Universal Windows programmes
With Windows 8 and later Windows 10, Microsoft wanted to be ‘all things at once’ and introduced Universal Windows Programs (UWP) to make life easier for programmers by allowing them to write a single program and run that program on a list of supported architectures. The programs are now reinterpreted as application packages, similar to Android or iOS, and are now further isolated from the system so that these applications are less likely to damage your system or personal files. To enable this, Microsoft has introduced new sets of folders for these applications, most of which you have limited access to, but which you may not even want to access under normal circumstances as they are only required by the applications to function.
I found it quite nice that there are almost parallels to classic Windows programmes in the structuring of UWPs.
Interjection: Python from the Microsoft Store
Interestingly, I found a python.exe file under my C:UsersuserAppDataLocalMicrosoftWindowsApps folder, which is a symbolic link to the following path: c:Program FilesWindowsAppsMicrosoft.DesktopAppInstaller_1.19.10173.0_x64__8wekyb3d8bbwAppInstallerPythonRedirector.exe
When you run this, the Microsoft Store page opens for… interestingly, it does not open the latest Python available. When installing the Python app (even the latest one), the link is changed to run the installed Python version instead. I’m not sure if this is just me, but it seems that this is an intended feature of the app installer that is part of Windows. Either way, it’s awesome! I wouldn’t be surprised if this was the intended functionality of Office as well.
Microsoft Office Store applications
Since the release of Windows 8, Microsoft has been trying to bring its Office suite to the Microsoft Store, initially mainly for its mobile users. With Windows 10, OneNote was offered as a replacement for the previous Sticky Notes app and as a stopgap for those versions of Windows that could not support Cortana. Of course, the Sticky Notes apps have since returned due to popular demand. While the desktop versions don’t really seem to have fully transitioned over, there was still a time when the Office apps with limited interface for mobile devices were also available for desktop, which I also downloaded to my PC. You can no longer download these apps to the desktop version of Windows, but I still have them. Microsoft has since switched to releasing the Office suite through its own channel, and has changed the Microsoft Store page to lead to the Microsoft Office Marketplace instead, where you can sign up to use Office. However, since this contradictory path is empty and I still have the mobile version of the Office apps, it’s quite possible that this folder is for the desktop app that is distributed through the Microsoft Store.
Conclusion
With the back and forth they did in their decision with the Microsoft Office version, and looking at the path used in the folders, it’s quite possible that Visual Studio started supporting a path in preparation for an Office version installed via the Microsoft Store that has since been abandoned, if it was ever used. And since it is in the user’s local application data path, which is used to store configuration files, there is no need to remove it, as a configuration file or empty folder will not by itself affect your PC. However, because the path exists but the application does not, Visual Studio mistakes the presence of the path for a valid Office installation and attempts to run an application that does not exist. I have Microsoft Office 365 installed, and an empty folder is not at all useful in a programme that works. Deleting it would only be a problem if the next update restored the folder, but then I would have found it on my other brand new laptop, which wasn’t the case, so I go and delete the Microsoft.Office.Desktop_8wekyb3d8bbwe folder. Now when I run the project, Excel opens with the add-on.
Under all other circumstances, the most ideal way to resolve this issue would have been to first uninstall Office, then delete the folder, then reinstall Office and then check to see if the folder reappears. If this is the case, you need to send a problem ticket primarily for Visual Studio, but probably also to the Office team.
