brutaldev / StrongNameSigner

Strong-name sign third party .NET assemblies without the source code.
https://brutaldev.com/post/net-assembly-strong-name-signer
Other
327 stars 68 forks source link

Access to the path '' is denied. #43

Closed scottydel closed 6 years ago

scottydel commented 6 years ago

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 6 years ago

Have you tried running with elevated privileges (right-click -> Run as Administrator)?

scottydel commented 6 years ago

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 6 years ago

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 6 years ago

Ok thanks, I will try lockhunter and see if something is holding it up. I"m using 2.1.3.0.

scottydel commented 6 years ago

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 6 years ago

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 6 years ago

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 6 years ago

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 6 years ago

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 6 years ago

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 6 years ago

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 6 years ago

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 6 years ago

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 6 years ago

Fixed in release 2.1.4

scottydel commented 6 years ago

Thank you and nice catch. I will grab the new version and continue. Much appreciated!!!