I was writing a simple PowerShell script to automate parts of a Microsoft Word document, and bizarrely the output error was telling me that you cannot call a method on a null-valued expression. But the confusing thing was that the object calling the method was not null!
My sample script was:
$alkaneDocumentPath = "C:\Temp\word.docx"
$wordApplication = New-Object -ComObject word.application
$document = $wordApplication.documents.open($alkaneDocumentPath);You Cannot Call a Method on a Null-Valued Expression
Every time I ran the script I got the following error message:
You cannot call a method on a null-valued expression.
The error message was implying that $wordApplication was null, when in fact it wasn’t! So what was going on? Well to see a more descriptive error message, I made my $wordApplication visible like so:
$alkaneDocumentPath = "C:\Temp\word.docx"
$wordApplication = New-Object -ComObject word.application
$wordApplication.Visible = $true
$document = $wordApplication.documents.open($alkaneDocumentPath);And this brought me back a much more useful error message:
Exception setting “Visible”: “Unable to cast COM object of type ‘Microsoft.Office.Interop.Word.ApplicationClass’ to interface type
‘Microsoft.Office.Interop.Word._Application’. This operation failed because the QueryInterface call on the COM component for the interface with IID
‘{00020970-0000-0000-C000-000000000046}’ failed due to the following error: Library not registered. (Exception from HRESULT: 0x8002801D
(TYPE_E_LIBNOTREGISTERED)).”
To cut a story short, I’d obtained my laptop from another user who had all sorts of junk installed and more recent copy of Microsoft Office (version 2016). When the laptop was passed to me, I was reverted to an older version of Office (Office 2010). And the uninstall of Office 2016 had left unwanted remnants.
My version of Office 2010 is a 32-bit version on a 64-bit operating system and as such installs registry to the WOW6432Node node. So I navigated to:
HKEY_CLASSES_ROOT\WOW6432Node\Interface\{00020970-0000-0000-C000-000000000046}\TypeLib
and the ‘Version’ value was set to 8.5. This version corresponds to Office 2010 so I was happy with this. So I looked at the ‘Default’ value, obtained the TypeLib GUID ({00020905-0000-0000-C000-000000000046}) and navigated to:
HKEY_CLASSES_ROOT\WOW6432Node\TypeLib\{00020905-0000-0000-C000-000000000046}
In here should only be a version subkey that corresponds to the installed version of Office – in my case there should just be a subkey called ‘8.5’. However there was also a subkey call ‘8.7’ which corresponded to Office 2016! I simply deleted the 8.7 subkey and re-ran my PowerShell script. Voila – it breathed into life!!
Incidentally I had the exact same issue instantiating Excel.Application. The relevant interface GUID was {000208D5-0000-0000-C000-000000000046}, the TypeLib version for Excel 2010 was 1.7 but when I navigated to the TypeLib in the registry it included a subkey for ‘1.9’! I deleted this subkey and Excel also started working.
