Closed scottydel closed 6 years ago
Have you tried running with elevated privileges (right-click -> Run as Administrator)?
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.
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?
Ok thanks, I will try lockhunter and see if something is holding it up. I"m using 2.1.3.0.
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).
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.
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.
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 👍
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
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
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.
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.
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.
Thank you and nice catch. I will grab the new version and continue. Much appreciated!!!
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.