mirror of
https://github.com/Set-OutlookSignatures/Set-OutlookSignatures.git
synced 2026-04-26 18:55:53 +03:00
[GH-ISSUE #54] Cannot bind parameter 'Path' to the target #19
Labels
No milestone
No project
No assignees
1 participant
Notifications
Due date
No due date set.
Dependencies
No dependencies set.
Reference
starred/Set-OutlookSignatures-Set-OutlookSignatures#19
Loading…
Add table
Add a link
Reference in a new issue
No description provided.
Delete branch "%!s()"
Deleting a branch is permanent. Although the deleted branch may continue to exist for a short time before it actually gets removed, it CANNOT be undone in most cases. Continue?
Originally created by @dakolta on GitHub (Sep 7, 2022).
Original GitHub issue: https://github.com/Set-OutlookSignatures/Set-OutlookSignatures/issues/54
Originally assigned to: @dakolta on GitHub.
This is on a new computer that has office 2016 installed
Here is the verbose output:
SetSig.txt
@GruberMarkus commented on GitHub (Sep 8, 2022):
Set-OutlookSignatures does the following:
The full code is:
The part finding the DLL file to load is:
The DLL file found is 'C:\WINDOWS\assembly\GAC_MSIL\Microsoft.Office.Interop.Word\15.0.0.0__71e9bce111e9429c\Microsoft.Office.Interop.Word.dll', which is the same as on many other systems (including some of my test systems).
What happens on your client, is that the
Add-Typepart of the code fails with an error stating that the file found a fraction of a second before does not exist.Test if
brings up the same error as
and
@dakolta commented on GitHub (Sep 8, 2022):
Ok, I ran those 3 commands, here are the results:
Also ran them as system:
@GruberMarkus commented on GitHub (Sep 9, 2022):
You executed the last code sequence as one line instead of two, that's why you receive the "Unexpected token '('" error message.
Your other tests show that everything works fine when using the SYSTEM account, but getting errors when using a regular user account.
The error message from
[System.Reflection.Assembly]::LoadFrom()may point you in the right direction: Instead ofCannot find path, this command throws 'Access is denied' and the hint that maybe not the DLL file itself has a problem, but one it's dependencies.As running the commands with the SYSTEM account shows no error, the root cause is very unlikely in Set-OutlookSignatures, PowerShell or the underlying .Net Framework, but rather in corrupt or missing files, NTFS permissions, corrupt or missing registry entries.
My next steps would be running the Office repair, maybe even uninstalling and reinstalling Office, checking registry keys (compare registry entries for '{00020970-0000-0000-C000-000000000046}' between a working and a non-working client computer), checking NTFS permissions and finally watching the whole sequence with a tool like process explorer.
@dakolta commented on GitHub (Sep 9, 2022):
Repaired the install of Office and ran the script from command line.

Web page comes up:
and we have the following error:
Here is the verbose output:
SetSig.txt
@GruberMarkus commented on GitHub (Sep 9, 2022):
Delete 'C:\Users\mvogel\AppData\Local\MSAL.PS\MSAL.PS.msalcache.bin3' and run the script again.
It is very likely a problem with browsing, as the browser message 'http://localhost/ refused to connect' suggests.
@dakolta commented on GitHub (Sep 12, 2022):
I created a new user on this computer.
Still getting error and web browser localhost issue.
I get the logon page, and password, this comes after the login.

Here is the verbose output:
SetSig (1).txt
@GruberMarkus commented on GitHub (Sep 12, 2022):
All tests until now have shown that loading the Word Interop DLL in Powershell outside Set-OutlookSignatures in three different programmatic ways
I cannot see where Set-OutlookSignatures could change anything for the better regarding this error. From my point of view, the root cause is clearly something on your clients, outside of Set-OutlookSignatures.
Repairing office did not help, but there are other proposed approaches you have not followed yet: