Office Interop Access is denied fix for .NET automation of Microsoft Office
Problem, Could not load file or assembly … or one of its dependencies. Access is denied
This is the solution to a perplexing issue around Office automation, that many people do not seem to be finding a solution for on forums.
The story, on a newly deployed set of PCs, a big issue arose where the Microsoft Office Interop for our .NET application would fail with errors of “Access is denied” when launching our integrating application. Solutions that were attempted proved only to be a temporary fix, with the problem reverting back again, often overnight.
Could not load file or assembly Microsoft.Office.Interop.Excel.dll or one of its dependencies. Access is denied.
Could not load file or assembly Microsoft.Office.Interop.Outlook.dll or one of its dependencies. Access is denied.
It turns out this is to do with permissions to the Interop assemblies that are put in the Global Assembly Cache (GAC) and the Centennial version of the Office App.
Solutions attempted
In an attempt to resolve the issue, the usual culprits were investigated including many more ideas that I’ve now forgotten about:
- Changing the permissions within the COM, component services control panel for the access, launch and activation permissions etc
- Taking control of the assembly cache permissions and granting access for directories and files including…
"C:\Windows\assembly\GAC_MSIL\Microsoft.Office.Interop.Outlook\15.0.0.0__71e9bce111e9429c\Microsoft.Office.Interop.Outlook.dll"
"C:\Windows\assembly\GAC_MSIL\Microsoft.Office.Interop.Excel\15.0.0.0__71e9bce111e9429c\Microsoft.Office.Interop.Excel.dll"
"C:\Windows\assembly\GAC_MSIL\Microsoft.Office.Interop.Word\15.0.0.0__71e9bce111e9429c\Microsoft.Office.Interop.Word.dll" - Uninstalling restarting, reinstalling Office
- Uninstalling restarting, installing the Office interop via the Office installer options
- Removing and replacing the local Office interop assemblies for the integrating application
- Embedding the Interops in the application (difficult with Nuget packages tho?)
- Using cacls.exe to update DCAL
Some of the above would work for the rest of that day, fixing the issue, yet the problem would return the next morning (machines left on overnight).
Root cause
Finally, a hint of the issue was found from digging deeper and deeper in the forums, revealing the root cause.
“Office in the Windows Store” was released which is a different version of Office that is available through the windows store in Windows 10. This version of office is often referred to as Office Centennial version, as it utilises Project Centennial to allow office to be ported to an Office store app. Project Centennial is a bridging solution intended to make it easier for software developers to migrate existing applications to the store and app architecture in windows. This bridge was used to create the version of office in the store, which is distinct from the standard Office you would install from other media sources.
This store version of Office has been included in the Windows system image used by some OEM manufacturers of PCs, so new users have it ready to go on the machine when they get it to the Office or home. Being a store app, it gets refreshed by the auto updates of the Windows store… you can see where this is going?…
It would seem that this version of Centennial Office was installed on the disk image of these PCs and when full Office professional was installed on the machine, all is fine, until the (not in use) Centennial version of Office decides to repair itself overnight during the store update, corrupting the permissions on the Interop assemblies in the GAC, leaving them with only SYSTEM permissions, thus rendering them inaccessible to the end users.
Doing many of the aforementioned attempts to fix the issue, would overlay the correct permissions, but only until the Centennial version of Office went and undid the work overnight.
What is more annoying is that early on in the diagnostics for this issue I had a suspicion around this being the issue, but found no installer under, Start>>Apps and Features for Microsoft Office Desktop Apps or Office, other than the pro copy. Also nothing in the programs and apps. Hence I’d assumed it can’t be the issue, wrongly as it turns out.
This seems to be an issue that has been hitting people from early 2019 through to 2020 when this blog post was written, although the OEMs were asked not the include the version of Office in the images anymore, so this should fade away over time.
It is a bit concerning that few people in forums seem to have found solutions, other than rebuilding the machine, but pushing on…
Removing Centennial Office
It seemed the obvious solution was to remove the store version of Office. It was not required and thus removing it should stop it overwriting the good install of Office. As noted before, there seemed to be no “uninstall” option anywhere in windows to get rid of the application. There were a few ways to remove this Office listed on internet forums, but the only one that worked for me was to launch power shell as an admin user. Then to run the following three commands, each in turn.
"(Get-AppxPackage -Name Microsoft.Office.Desktop).Dependencies | Remove-AppxPackage"
"Get-AppxPackage -Name Microsoft.Office.Desktop | Remove-AppxPackage"
"(Get-AppxPackage -Name Microsoft.Office.Desktop).Dependencies"
The final command should just confirm removal, by not returning anything.
Immediately it could be seen the assemblies had been removed from the “C:\Windows\assembly\GAC_MSIL\*” directories and after running the afflicted application, the issue would seem to be resolved. The professional office install was also repaired, via the Office Pro installer, for good measure.
A very annoying, obscure problem finally resolved!
References:
How do I uninstall Office 365 Windows Store version?
how to uninstall office 365 preloaded in windows 10
Why ‘Office in the Windows Store’ isn’t really Microsoft Office