Closed Matthew-Davey closed 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.
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.
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.
@Matthew-Davey How long are the actual directory paths being reported in the error messages?
@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."
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
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.
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.
Hi there! I'm seeing the following error when I try to execute the
StrongNameSigner.Console.exe
command line tool in a Linux environment.Any ideas what could be causing this?
StrongNameSigner.Console v1.5.1 Ubuntu 14.04.5 LTS Mono 4.6.1