[GH-ISSUE #47] Error when signing assembly; Operation is not valid due to the current state of the object

kerem commented

2026-02-25 21:30:32 +03:00

Owner

Originally created by @alphaleonis on GitHub (Aug 10, 2018).
Original GitHub issue: https://github.com/brutaldev/StrongNameSigner/issues/47

Originally assigned to: @brutaldev on GitHub.

Running StrongNameSigner.Console.exe -a net452\IdentityModel.dll gives the following error:
Error: Operation is not valid due to the current state of the object..

The IdentityModel.dll is from the IdentityModel nuget package version 3.9.0, and StrongNameSigner is downloaded from NuGet version 2.1.4.

Originally created by @alphaleonis on GitHub (Aug 10, 2018). Original GitHub issue: https://github.com/brutaldev/StrongNameSigner/issues/47 Originally assigned to: @brutaldev on GitHub. Running `StrongNameSigner.Console.exe -a net452\IdentityModel.dll` gives the following error: `Error: Operation is not valid due to the current state of the object.`. The IdentityModel.dll is from the IdentityModel nuget package version 3.9.0, and StrongNameSigner is downloaded from NuGet version 2.1.4.

kerem

2026-02-25 21:30:32 +03:00

closed this issue
added the
enhancement

bug
labels

kerem commented

2026-02-25 21:30:32 +03:00

Author

Owner

@Comprion-OJapes commented on GitHub (Aug 15, 2018):

Hi!

I ran into the same problem last year and together with @brutaldev we found that the existence of a pdb file causes this problem. Right now I'm again facing that problem, using the NuGet-Package of ZXing.Net (https://www.nuget.org/packages/ZXing.Net/) with version 0.15.0

As a workaround: delete all .pdb-files in the packages-subfolder.

I hope that this will give a clue on what causes the problem so that it can be hopefully fixed in the future.

@Comprion-OJapes commented on GitHub (Aug 15, 2018): Hi! I ran into the same problem last year and together with @brutaldev we found that the existence of a pdb file causes this problem. Right now I'm again facing that problem, using the NuGet-Package of ZXing.Net (https://www.nuget.org/packages/ZXing.Net/) with version 0.15.0 As a workaround: delete all .pdb-files in the packages-subfolder. I hope that this will give a clue on what causes the problem so that it can be hopefully fixed in the future.

kerem commented

2026-02-25 21:30:32 +03:00

Author

Owner

@alphaleonis commented on GitHub (Aug 28, 2018):

That's a good tip... unfortunately I can't seem to be able to sign the IdentityModel NuGet package even if I remove the .pdb-file. :(

@alphaleonis commented on GitHub (Aug 28, 2018): That's a good tip... unfortunately I can't seem to be able to sign the **IdentityModel** NuGet package even if I remove the .pdb-file. :(

kerem commented

2026-02-25 21:30:32 +03:00

Author

Owner

@alphaleonis commented on GitHub (Aug 28, 2018):

I still get the following exception trace:

error : Operation is not valid due to the current state of the object.
 error :    at Mono.Cecil.ModuleDefinition.ProcessDebugHeader()
 error :    at Mono.Cecil.ModuleDefinition.ReadSymbols(ISymbolReader reader)
 error :    at Mono.Cecil.ModuleReader.ReadSymbols(ModuleDefinition module, ReaderParameters parameters)
 error :    at Mono.Cecil.ModuleReader.CreateModuleFrom(Image image, ReaderParameters parameters)
 error :    at Mono.Cecil.ModuleDefinition.ReadModule(Stream stream, ReaderParameters parameters)
 error :    at Mono.Cecil.ModuleDefinition.ReadModule(String fileName, ReaderParameters parameters)
 error :    at Brutal.Dev.StrongNameSigner.SigningHelper.GetAssemblyInfo(String assemblyPath, String[] probingPaths)
 error :    at Brutal.Dev.StrongNameSigner.AutomaticBuildTask.Execute()

@alphaleonis commented on GitHub (Aug 28, 2018): I still get the following exception trace: ```` error : Operation is not valid due to the current state of the object. error : at Mono.Cecil.ModuleDefinition.ProcessDebugHeader() error : at Mono.Cecil.ModuleDefinition.ReadSymbols(ISymbolReader reader) error : at Mono.Cecil.ModuleReader.ReadSymbols(ModuleDefinition module, ReaderParameters parameters) error : at Mono.Cecil.ModuleReader.CreateModuleFrom(Image image, ReaderParameters parameters) error : at Mono.Cecil.ModuleDefinition.ReadModule(Stream stream, ReaderParameters parameters) error : at Mono.Cecil.ModuleDefinition.ReadModule(String fileName, ReaderParameters parameters) error : at Brutal.Dev.StrongNameSigner.SigningHelper.GetAssemblyInfo(String assemblyPath, String[] probingPaths) error : at Brutal.Dev.StrongNameSigner.AutomaticBuildTask.Execute() ````

kerem commented

2026-02-25 21:30:32 +03:00

Author

Owner

@alphaleonis commented on GitHub (Aug 28, 2018):

Sorry, my bad. It actually does seem to work from the console app at least when removing the .pdb file as suggested.

@alphaleonis commented on GitHub (Aug 28, 2018): Sorry, my bad. It actually does seem to work from the console app at least when removing the .pdb file as suggested.

kerem commented

2026-02-25 21:30:32 +03:00

Author

Owner

@alphaleonis commented on GitHub (Aug 28, 2018):

Actually it seems this problem was "fixed" in the master branch already, but never released. See commit 237726afe2

@alphaleonis commented on GitHub (Aug 28, 2018): Actually it seems this problem was "fixed" in the master branch already, but never released. See commit 237726afe2ee6427f2999674021d480bfea48e5f

kerem commented

2026-02-25 21:30:32 +03:00

Author

Owner

@brutaldev commented on GitHub (Aug 28, 2018):

@alphaleonis The last release was 7 months ago (v2.1.4) which contains that fix (tagged for 2.1.4 as well) which was made almost a year ago now. The automatic build task is in the same assembly as the signing helper where the change was made so it's definitely included.

@brutaldev commented on GitHub (Aug 28, 2018): @alphaleonis The last release was 7 months ago (v2.1.4) which contains that fix (tagged for 2.1.4 as well) which was made almost a year ago now. The automatic build task is in the same assembly as the signing helper where the change was made so it's definitely included.

kerem commented

2026-02-25 21:30:32 +03:00

Author

Owner

@alphaleonis commented on GitHub (Aug 28, 2018):

Yeah, sorry about that. I mixed everything up here with different versions of things, building them and trying to fix the problem. It was all very confusing, and still is a bit.

It seems that I got the error if the Mono.Cecil.Mdb.dll and Mono.Cecil.Pdb.dll files were present in the same directory as the .exe, otherwise I didn't.

After updating to the latest version of Cecil though, it seems to work as it should, except that now it seems that it is not possible to write the output to the same destination as the input file, since that produces an Access Denied error because "the file is used by another process".

I will investigate a little further and let you know what I find out. Sorry for all my confusing ramblings, it's been one of those days.

@alphaleonis commented on GitHub (Aug 28, 2018): Yeah, sorry about that. I mixed everything up here with different versions of things, building them and trying to fix the problem. It was all very confusing, and still is a bit. It seems that I got the error if the `Mono.Cecil.Mdb.dll` and `Mono.Cecil.Pdb.dll` files were present in the same directory as the .exe, otherwise I didn't. After updating to the latest version of Cecil though, it seems to work as it should, *except* that now it seems that it is not possible to write the output to the same destination as the input file, since that produces an Access Denied error because "the file is used by another process". I will investigate a little further and let you know what I find out. Sorry for all my confusing ramblings, it's been one of those days.

kerem commented

2026-02-25 21:30:32 +03:00

Author

Owner

@brutaldev commented on GitHub (Aug 28, 2018):

There is a branch using the newer version but the unit tests don't pass because of file locking problems now present internally in those libs. Once an assembly is read, file locks seem to be kept even though you dispose the reader objects so upgrading was abandoned.

This issue was identified in multiple times in the past:
https://github.com/brutaldev/StrongNameSigner/issues/35
https://github.com/brutaldev/StrongNameSigner/issues/32#issuecomment-324259693

@brutaldev commented on GitHub (Aug 28, 2018): There is a [branch using the newer version](https://github.com/brutaldev/StrongNameSigner/tree/mono.cecil-0.10) but the unit tests don't pass because of file locking problems now present internally in those libs. Once an assembly is read, file locks seem to be kept even though you dispose the reader objects so upgrading was abandoned. This issue was identified in multiple times in the past: https://github.com/brutaldev/StrongNameSigner/issues/35 https://github.com/brutaldev/StrongNameSigner/issues/32#issuecomment-324259693

kerem commented

2026-02-25 21:30:32 +03:00

Author

Owner

@alphaleonis commented on GitHub (Aug 28, 2018):

I did some quick tests, and I can't see any file locking if I dispose the AssemblyDefinition returned by AssemblyDefinition.ReadAssembly. They must be disposed before writing to the file that was read. This means you probably have to write a temporary file first, then dispose the AssemblyDefinition and then move the temporary file to the actual file if in-place-signing is desired.

I tried implementing a quick-fix for this in the SignAssembly method, and all unit tests passed except for one using FixAssemblyReferences since I didn't implement it in this method. (I cache AssemblyInfo instances instead of AssemblyDefinition in these cases).

This is with the latest version of Mono.Cecil from NuGet, and everything seems to work.

If you'd like I could probably spend a bit more time and create a proper implementation and submit a PR.

Edit: In fact I realize I pretty much have to implement a proper fix for it tomorrow since we kind of need it, so just let me know if you want the PR.

@alphaleonis commented on GitHub (Aug 28, 2018): I did some quick tests, and I can't see any file locking if I dispose the `AssemblyDefinition` returned by `AssemblyDefinition.ReadAssembly`. They must be disposed before writing to the file that was read. This means you probably have to write a temporary file first, then dispose the `AssemblyDefinition` and then move the temporary file to the actual file if in-place-signing is desired. I tried implementing a quick-fix for this in the `SignAssembly` method, and all unit tests passed except for one using `FixAssemblyReferences` since I didn't implement it in this method. (I cache `AssemblyInfo` instances instead of `AssemblyDefinition` in these cases). This is with the latest version of Mono.Cecil from NuGet, and everything seems to work. If you'd like I could probably spend a bit more time and create a proper implementation and submit a PR. Edit: In fact I realize I pretty much have to implement a proper fix for it tomorrow since we kind of need it, so just let me know if you want the PR.

kerem commented

2026-02-25 21:30:32 +03:00

Author

Owner

@brutaldev commented on GitHub (Aug 28, 2018):

Sure, a PR would be great for this. Do it on the mono.cecil-0.10 branch but just upgrade to whatever the latest is in NuGet. I'll give it a quick run now myself to see if I can get the tests to pass using your suggestions.

@brutaldev commented on GitHub (Aug 28, 2018): Sure, a PR would be great for this. Do it on the mono.cecil-0.10 branch but just upgrade to whatever the latest is in NuGet. I'll give it a quick run now myself to see if I can get the tests to pass using your suggestions.

kerem commented

2026-02-25 21:30:32 +03:00

Author

Owner

@brutaldev commented on GitHub (Aug 28, 2018):

This has all been fixed in release v2.2.0

Thanks for the suggestions @alphaleonis, I was creating temp files and overwriting later, but not in all areas. Caching the definition in one place also prevented it from being disposed so changing that to cache info instead helped the unit tests pass.

@brutaldev commented on GitHub (Aug 28, 2018): This has all been fixed in release [v2.2.0](https://github.com/brutaldev/StrongNameSigner/releases/tag/v2.2.0) Thanks for the suggestions @alphaleonis, I was creating temp files and overwriting later, but not in all areas. Caching the definition in one place also prevented it from being disposed so changing that to cache info instead helped the unit tests pass.

kerem commented

2026-02-25 21:30:32 +03:00

Author

Owner

@alphaleonis commented on GitHub (Aug 28, 2018):

Nice. Thanks. I just noted though that you don't delete the temp-files afterwards which we should probably do to be nice to the user. Also all the calls to File.SetAttributes, aren't they supposed to operate on the actual target file rather than the temporary file so that the actual target file can be overwritten by the copy? (The temp file we just created so it seems unlikely that would be read-only)?

I might be missing something, kind of tired here, just some reflections I thought I'd point them out. :) Thanks for a quick fix anyway! Guess you won't be needing my PR. :)

@alphaleonis commented on GitHub (Aug 28, 2018): Nice. Thanks. I just noted though that you don't delete the temp-files afterwards which we should probably do to be nice to the user. Also all the calls to `File.SetAttributes`, aren't they supposed to operate on the actual target file rather than the temporary file so that the actual target file can be overwritten by the copy? (The temp file we just created so it seems unlikely that would be read-only)? I might be missing something, kind of tired here, just some reflections I thought I'd point them out. :) Thanks for a quick fix anyway! Guess you won't be needing my PR. :)

kerem commented

2026-02-25 21:30:32 +03:00

Author

Owner

@brutaldev commented on GitHub (Aug 28, 2018):

Setting the file attributes is to force the read-only flag off, could get away without doing it on the temp file but it's done to ensure the file it replaces will always have the read-only flag off (both files have this set). There was a long issue about how this also caused issues that appeared as file locks but I'm not prepared to go down that rabbit whole again or introduce any other issues by removing it right now.

I can add the code to delete the temp files later (unless you want to review and PR), I don't really want to do anything else on this project right now so I was just getting it working and moving onto other work.

@brutaldev commented on GitHub (Aug 28, 2018): Setting the file attributes is to force the read-only flag off, could get away without doing it on the temp file but it's done to ensure the file it replaces will always have the read-only flag off (both files have this set). There was a long issue about how this also caused issues that appeared as file locks but I'm not prepared to go down that rabbit whole again or introduce any other issues by removing it right now. I can add the code to delete the temp files later (unless you want to review and PR), I don't really want to do anything else on this project right now so I was just getting it working and moving onto other work.

kerem commented

2026-02-25 21:30:32 +03:00

Author

Owner

@alphaleonis commented on GitHub (Aug 29, 2018):

I understand completely. Thanks for the quick fix attempt, unfortunately this caused a couple of other problems when .pdb files were present it seems (Error: Symbols were found but are not matching the assembly). I will investigate and submit a PR once I'm done, and try to get some new tests that cover this scenario as well.

@alphaleonis commented on GitHub (Aug 29, 2018): I understand completely. Thanks for the quick fix attempt, unfortunately this caused a couple of other problems when .pdb files were present it seems (`Error: Symbols were found but are not matching the assembly`). I will investigate and submit a PR once I'm done, and try to get some new tests that cover this scenario as well.

kerem commented

2026-02-25 21:30:32 +03:00

Author

Owner

@brutaldev commented on GitHub (Aug 29, 2018):

@alphaleonis That would be awesome, I never had the chance to really test everything with the new libs. I added the temp file deletes to master last night as well. Any other fixes you want to make will be much appreciated.

@brutaldev commented on GitHub (Aug 29, 2018): @alphaleonis That would be awesome, I never had the chance to really test everything with the new libs. I added the temp file deletes to `master` last night as well. Any other fixes you want to make will be much appreciated.

Rows
Columns

[GH-ISSUE #47] Error when signing assembly; Operation is not valid due to the current state of the object #41