brutaldev / StrongNameSigner

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

Error: Win32 IO returned ERROR_GEN_FAILURE #26

Closed Matthew-Davey closed 7 years ago

Matthew-Davey commented 7 years ago

Hi there! I'm seeing the following error when I try to execute the StrongNameSigner.Console.exe command line tool in a Linux environment.

packages/Brutal.Dev.StrongNameSigner.1.5.1/tools/StrongNameSigner.Console.exe -in {my project}/bin/Debug -k {my signing key}.pfx -p {my password} -l Changes
Error: Win32 IO returned ERROR_GEN_FAILURE. Path: /vagrant/{my project folder}/bin/Debug/{assembly file}
Error: Win32 IO returned ERROR_GEN_FAILURE. Path: /vagrant/{my project folder}/bin/Debug/{assembly file}
.NET Assembly Strong-Name Signer Summary
0 file(s) were strong-name signed.
0 references(s) were fixed.
Unknown errno: Protocol error
Unknown errno: Protocol error

Any ideas what could be causing this?

StrongNameSigner.Console v1.5.1 Ubuntu 14.04.5 LTS Mono 4.6.1

brutaldev commented 7 years ago

@Matthew-Davey You should first update to the latest version (2.1.0), the version you are using is pretty old from August 2015. Try running the command again with the latest version and see if it's been fixed.

Matthew-Davey commented 7 years ago

Thanks for your quick response :)

I have upgraded the package to v2.1.0, unfortunately still seeing the same error:

packages/Brutal.Dev.StrongNameSigner.2.1.0/build/StrongNameSigner.Console.exe -in {my project folder}/bin/Debug -k {my signing key}.pfx -p {password} -l Changes
Error: Win32 IO returned ERROR_GEN_FAILURE. Path: /vagrant/{my project folder}/bin/Debug/{my assembly}.dll
Error: Win32 IO returned ERROR_GEN_FAILURE. Path: /vagrant/{my project folder}/bin/Debug/{my assembly}.dll

.NET Assembly Strong-Name Signer Summary
0 file(s) were strong-name signed.
0 references(s) were fixed.
Unknown errno: Protocol error
Unknown errno: Protocol error

I tried also with verbose logging output but it didn't yield any additional information on the error.

brutaldev commented 7 years ago

A quick Google and it looks like that error happens when using \ path separators which will fail in Linux which expects /.

Will take a look at the code a bit later and find where those are being used and replace them with Path.DirectorySeparatorChar so it's specific to the system being run on.

brutaldev commented 7 years ago

@Matthew-Davey How long are the actual directory paths being reported in the error messages?

brutaldev commented 7 years ago

@Matthew-Davey I don't think this is something that can be fixed. I know of another user who uses the application successfully in Linux so this could just be specific to your machine and I've double checked there are no hard-coded backslashes in any paths. If you lookup what the error code ERROR_GEN_FAILURE refers to in the error code table you'll find "A device attached to the system is not functioning."

Matthew-Davey commented 7 years ago

OK thanks. The longest path to one of the assemblies in my output folder ins 170 characters.

I'll try and see if I can get the tool to sign the assemblies under perfect conditions - eg. in the home folder, short names etc

Matthew-Davey commented 7 years ago

Hi again,

So as you might have seen from my logs I'm running this inside a vagrant provisioned vm. Vagrant creates a folder sync between the vm and the host machine where the project files live.

It looks like the failure only occurs when running inside the synced folder, and it occurs when writing the signed assembly back to disk.

If I move the project out of the synced folder (eg. cp /vagrant/{my project folder} ~/{my project folder}) and run the command again, it works 100%.

Not sure if there's anything you'd be able to do to resolve this within your code. Probably safe to close this issue.

brutaldev commented 7 years ago

Hey, yeah that's not something I want to attempt to fix, it will probably break with any .NET application trying to write to the directory because it's not doing anything out of the ordinary.

Based on your description the actual error code makes sense, if it's a synced directory then flushing to a "simulated" disk is probably freaking out. I would chalk this up to something wrong in Mono because the error message has been reported a number of times with various other applications.