mirror of
https://github.com/brutaldev/StrongNameSigner.git
synced 2026-04-25 11:26:04 +03:00
[GH-ISSUE #43] Access to the path '' is denied. #38
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 @scottydel on GitHub (Jan 17, 2018).
Original GitHub issue: https://github.com/brutaldev/StrongNameSigner/issues/43
I installed the GUI version and run into this error every time. I have a couple unsigned DLLs in a local folder I created on my machine. I verified my AD account has rights to this folder, as well as the DLLs. When ever I add the files, and click "Sign Assemblies" the output log says: "Error strong-name signing : Access to the path '' is denied." Tried rebooting. Tried moving them to a different folder. Not sure what's going on.
@brutaldev commented on GitHub (Jan 17, 2018):
Have you tried running with elevated privileges (right-click -> Run as Administrator)?
@scottydel commented on GitHub (Jan 17, 2018):
I have tried that yes. It creates the *.unsigned file. The first time I run the error message says no access to the original DLL. The next time I run the error message says no access to the *unsigned file it previously created.
@brutaldev commented on GitHub (Jan 17, 2018):
Any other process locking the file up? When you get access denied errors it's not always permissions but quite often other processes using the files that prevents you from making changes to it while a file lock is in place. Use LockHunter or something similar to try and determine what is using the file access.
What version are you using?
@scottydel commented on GitHub (Jan 17, 2018):
Ok thanks, I will try lockhunter and see if something is holding it up. I"m using 2.1.3.0.
@scottydel commented on GitHub (Jan 17, 2018):
Lockhunter shows no process are locking any of the files (4 in total, two original DLLs and two *.unsigned files created by Strong-Name Signer).
@brutaldev commented on GitHub (Jan 17, 2018):
Not sure what to tell you. The lock might come and go during the process, like an anti-virus accessing the file to perform a scan just at the point it's trying to write to it again. Not much we can do about this since it's incredibly environment specific and no-one else has reported any issues with locking during the signing process.
@scottydel commented on GitHub (Jan 17, 2018):
That is a great point. I'm using my work development machine, and our network can be very locked down (big company = big brother). I will try this again on my home development machine. Thank you for taking the time to respond. I will report back what I find and hopefully figure it out.
@scottydel commented on GitHub (Jan 18, 2018):
I tried at home and surprisingly same results. So something must be up with these particular DLLs I'm trying to sign? I checked permissions (at home) and I have full access to the folder and files. FWIW, I'm leaving the three text boxes above blank. I'll keep playing around. Again thank you for taking the time to help 👍
@scottydel commented on GitHub (Jan 18, 2018):
I played around at home, and selected a DLL from an old project and the tool worked perfectly. So the two DLLs I am working with are the issue. One of these DLLs is home grown in Visual Studio 2017, and the other is a third party DLL, Renci.SshNet.dll (which is referenced by the home grown DLL). Any ideas if there is something I am doing in VS 2017 that could be preventing the tool from working?
I tried signing them by hand originally, but this is the error I get when running code:
Message :[C:\Windows\Microsoft.Net\assembly\GAC_MSIL\Renci.SshNet\v4.0_2013.4.7.0__e10d9eb3a09c3cf6\Renci.SshNet.dll] Strong-name signed assemblies must specify a public key in their InternalsVisibleTo declarations.
What brought me to your tool was that it sets InternalsVisibleTo. The 3rd party DLL, Renci.SshNet.dll, is the one that needs this attribute added I believe, and since it's 3rd party I don't have the source code to rebuild the DLL
@brutaldev commented on GitHub (Jan 18, 2018):
The SSH.NET library is actually open source so you could compile it and apply a strong name key at that point. Which built version are you using, and does it sign on it's own if it's the only file you use? I'd like to get a copy of the same file you are using to debug with, if it's the .NET Core version then the strong-name signer won't be able to sign it: https://github.com/brutaldev/StrongNameSigner/issues/41
@brutaldev commented on GitHub (Jan 18, 2018):
Hmm, if I get the latest version and drop it into the UI, it's already signed so the tool won't do anything to it.
@scottydel commented on GitHub (Jan 18, 2018):
SSH.NET 2013.4.7, I think it's older. Our home grown app that I'm working on is older. With just the Renci.SshNet.dll file in the UI, same result, access denied. I will try and compile SSH.NET with our dll listed as a friendly and see if that fixes it. I'm able to add Renci.SshNet.dll as a friendly to our app, but I think it needs to be the other way around.
@brutaldev commented on GitHub (Jan 18, 2018):
Alright, figured out what the issue is. Your files have the Read-only attribute set so when trying to overwrite them you get the access denied error. This breaks on the unsigned backup files too because they are just copies of the original and carry the flag with them.
Right click -> Properties on your file and uncheck the Read-only check box and all should be fine.
I'm making an update to reset the flag on the files before processing them so you will not have to uncheck it manually in future.
@brutaldev commented on GitHub (Jan 18, 2018):
Fixed in release 2.1.4
@scottydel commented on GitHub (Jan 19, 2018):
Thank you and nice catch. I will grab the new version and continue. Much appreciated!!!