mirror of
https://github.com/brutaldev/StrongNameSigner.git
synced 2026-04-25 11:26:04 +03:00
[GH-ISSUE #32] trying to sign dll "Operation is not valid due to the current state of the object" #30
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 @den-run-ai on GitHub (Feb 16, 2017).
Original GitHub issue: https://github.com/brutaldev/StrongNameSigner/issues/32
I'm trying to sign Python.Runtime.DLL, but got this error:
This used to work before and stopped working in version 1.8.0.
@brutaldev commented on GitHub (Feb 16, 2017):
The latest version is 2.1.0 which has some significant changes to the signing. If it still breaks with the latest version let me know, I'm not supporting version 1.x.
@den-run-ai commented on GitHub (Feb 16, 2017):
@brutaldev yes, I checked with latest as well
@den-run-ai commented on GitHub (Feb 16, 2017):
@brutaldev actually not, let me check
@den-run-ai commented on GitHub (Feb 16, 2017):
2.1.0.0 still not working:
@brutaldev commented on GitHub (Feb 16, 2017):
Please post a link to where I can get
Python.Runtime.DLLto test on my side.@den-run-ai commented on GitHub (Feb 16, 2017):
I just recompiled from master with Debug/AnyCPU and your tool is working!
@den-run-ai commented on GitHub (Feb 16, 2017):
you can download Python.Runtime.DLL from here, just extract .whl as zip files:
https://pypi.python.org/pypi/pythonnet/2.2.2#downloads
@brutaldev commented on GitHub (Feb 16, 2017):
Hmm, could just be a messes up release then. I'll drop 2.1.1 just as a rebuild and see if that helps. I'll let you know when it's up and you can give it another test with the official version.
@brutaldev commented on GitHub (Feb 16, 2017):
Give this version a try please: https://brutaldev.com/download/StrongNameSigner_Setup.exe?v=2.1.1
@den-run-ai commented on GitHub (Feb 16, 2017):
still the same error, so try downloading my DLL.
@brutaldev commented on GitHub (Feb 16, 2017):
So strange, I can the
Python.Runtime.DLLusing 2.1.0 and 2.1.1 without any error. Try build in release and see if it happens on your side.@den-run-ai commented on GitHub (Feb 16, 2017):
I can't build release version, it complains about sandcastle.
On Thu, Feb 16, 2017, 1:27 PM Werner van Deventer notifications@github.com
wrote:
@brutaldev commented on GitHub (Feb 16, 2017):
That will be a post build step anyway, you will still have a release build to run before that happens.
@den-run-ai commented on GitHub (Feb 16, 2017):
Release build from Master branch works as well.
@brutaldev commented on GitHub (Feb 16, 2017):
¯\(ツ)/¯
Only seems to break on your machine. I've tried signing
Python.Runtime.DLLon several machines now and cannot reproduce the error even on the current version of 2.1.0.@den-run-ai commented on GitHub (Feb 16, 2017):
@brutaldev I just tried on another machine and this works with the latest installer. so me too:
¯(ツ)/¯
@brutaldev commented on GitHub (Feb 17, 2017):
I think we can chalk this up to a weird bug that only exists on your machine with compiled release versions... If anyone else gets the "Operation is not valid due to the current state of the object" error then just re-open this issue.
@den-run-ai commented on GitHub (Mar 8, 2017):
@brutaldev I just reproduced this problem on Windows 10 (before it was Windows 7). I'm using 64-bit Python 3.5 wheel:
https://pypi.python.org/packages/c2/1b/616ba08a2856537f511e052020dc2317213af031d88c8db361f26cc89f6a/pythonnet-2.2.2-cp35-cp35m-win_amd64.whl
@brutaldev commented on GitHub (Mar 8, 2017):
@denfromufa Are you talking about
Python.Runtime.dll? Just tried your download link on my machine and works without a hitch. Only seems to happen for you... If you can get it to happen consistently in the UI, click the "Show Output" link and see if there is a stack trace there which might be useful.@GieltjE commented on GitHub (Jul 10, 2017):
This is easily fixable by releasing the AssemblyDefinition (just call .Dispose or put it in a using) and just caching the AssemblyInfo results (Don't foget to fix the SignAssembly too!).
After these two simple patches everyting works like a charm!
Took me about 3 minutes to figure out, let's just get this crap over with.
@brutaldev commented on GitHub (Jul 10, 2017):
@GieltjE I updated to the latest pre-release of Mono.Cecil which has
IDisposableonAssemblyDefinition. Also ensured they are disposed of at appropriate times but the file locking problem with the pre-release version still remains as I mentioned in issue #40. You can verify with the unit tests that file locks still occur so I won't be going live with this version. You can view the changes in the mono.cecil-0.10 branch.Caching
AssemblyInfowould be pointless since only the getter generates an instance of that class and it gets stale really fast, it would fail with the same problem long before it gets there because it still needs to read the PDB files in long before that.Would love to see how you easily fixed this in about 3 minutes, perhaps you can provide a PR for your changes and you can get this crap over with yourself.
@GieltjE commented on GitHub (Jul 10, 2017):
Works for me, just took the parts I needed, updated the assembly info to hold the hash (switched to .net sha1) to rectify the list<string,list< and properly disposed the objects both in the getassembly and signassembly.
Everthing runs fine, no more locking issues.
Could try to patch up your source if you like.
@GieltjE commented on GitHub (Aug 23, 2017):
https://github.com/nunit/nunit3-vs-adapter/issues/325
That is the bug that prohibits the correct functioning of the test cases, otherwise with the proper disposal of the mentioned objects the new versions are perfectly fine :)
@brutaldev commented on GitHub (Aug 23, 2017):
The following commit contains the changes you are referring to:
github.com/brutaldev/StrongNameSigner@9cb11ec8e7This commit properly disposes these objects and uses the beta6 version of Mono.Cecil. This may fix the PDB issue, but the new version of Mono.Cecil holds locks to files so any non-trivial signing process will fail. This is clearly highlighted by the failing tests when introducing these changes: https://ci.appveyor.com/project/brutaldev/strongnamesigner/build/tests
Although the changes you mention will fix the problem in your very simple signing process, this is not a viable solution because of the additional problems it introduces and how many other users will experience file locking issues.