Returned object type
Typically,
new-object -com … returns a System.__ComObject object. In special cases however, it returns an «interop» object that wraps the COM Object.
This behaviour is demonstrated in the following simple example.
First, we create two COM objects …
PS C:\> $fso = new-object -com scripting.filesystemobject PS C:\> $xls = new-object -com excel.application
… and then determine their types:
PS C:\> $fso.GetType().FullName System.__ComObject PS C:\> $xls.GetType().FullName Microsoft.Office.Interop.Excel.ApplicationClass
I wondered why
new-object -com does not always return a __ComObject object. The explanation seems to be related to the way in which COM Objects are registered with the registry.
When I used
new-object -com progId, the CLSID that is associated with prog.id was determined. The value of this CLSID is found in the registry as default value of the registry key HKEY_CLASSES_ROOT\prog.id\CLSID: $null = new-psDrive -name HKCR -psProvider registry -root HKEY_CLASSES_ROOT
$clsid_xls = get-itemPropertyValue -name '(default)' HKCR:\excel.application\CLSID
$clsid_fso = get-itemPropertyValue -name '(default)' HKCR:\scripting.filesystemobject\CLSID
write-host "CLSIDs: xls: $clsid_xls, fso: $clsid_fso"
CLSIDs: xls: {00024500-0000-0000-C000-000000000046}, fso: {0D43FE01-F093-11CF-8940-00A0C9054228}
Each of these CLSIDs has a registry key named
InprocServer32 that is found under the key HKEY_CLASSES_ROOT\CLSID\{clsid}
If we look up these keys in
regedit.exe, we find some differences. In-proc server for file system object
In the case of the file system object, «only» a DLL is registred: 
