mirror of
https://github.com/brutaldev/StrongNameSigner.git
synced 2026-04-25 11:26:04 +03:00
[GH-ISSUE #94] Does not work with VS 2022 started with Admin rights targeting .net 4.8 framework #78
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 @rboy1 on GitHub (Feb 11, 2023).
Original GitHub issue: https://github.com/brutaldev/StrongNameSigner/issues/94
Originally assigned to: @brutaldev on GitHub.
When trying to use the nuget add on with VS 2022 with a target framework of 4.8, it doesn't seem to work. For example when including this unsigned nuget package https://www.nuget.org/packages/OSVersionExt/ in the project it, it doesn't strong name it leading to an error when the strong named project tries to access it.
@brutaldev commented on GitHub (Feb 11, 2023):
@rboy1 Works just fine here.
Sample project to verify this yourself if you want: Issue94.zip
You need to post the output for the signer if there are any errors trying to sign your file.
@rboy1 commented on GitHub (Feb 13, 2023):
Thanks for looking into this. It's still running into an error and I believe it's related to elevated permissions when running VS 2022 with Admin rights.
I tried running your attached solution and I got an error. (actually two, the first was that the AssemblyInfo.cs was missing which I took care of deleting the missing file from the solution), after compilation I got this:
The one point to note is that I'm starting VS 2022 with Admin rights (right click VS 2022 and
Run as Administrator).Debug output:
Build output
If I start VS without admin rights it seems to work fine, however I need Admin rights for my project to work/debug.
Oddly enough it works with VS 2017 started with Admin rights (targeting .NET 4.6.1)
@rboy1 commented on GitHub (Feb 13, 2023):
Also when trying to replicate the issue in Admin mode, after having signed it in non admin mode, I would recommend deleting the nuget package and restoring it again and then trying to build it in admin mode.
@brutaldev commented on GitHub (Feb 13, 2023):
@rboy1 Deleted bin/obj/packages and opened the sample solution with elevated VS 2022 and there are no errors so I'm not going to investigate this any further. If I was to guess, it's because you are building in your OneDrive directory and files are probably being synched incorrectly.
@rboy1 commented on GitHub (Feb 13, 2023):
Actually, I managed to replicate the same error even in non Admin mode. I deleted and restore the nuget package and tried to rebuild it in non admin mode (see attached screenshot, the Admin symbol on the right corner is missing) and it gave me the error.
Can't explain it, the first time after an Admin mode build failure it built it in non Admin mode. The second time even with Non admin mode it failed.
@rboy1 commented on GitHub (Feb 13, 2023):
Not using OneDrive (it's disabled) but to test it out anyways I moved the solution to another folder and tried to rebuild it and it failed again with the same error. This isn't unique to me. I've seen this error reported by other users using a different package signer and it appears to be rooted in the Mono.Cecil error. Here's the reference
https://github.com/dsplaisted/strongnamer/issues/52
I'm able to replicate this issue easily here in Admin mode of VS 2022.
EDIT: Logs
@rboy1 commented on GitHub (Feb 13, 2023):
For reference you will encounter this error on a fresh install of Windows 11 / VS 2022 with ONLY .net 4.8 installed. If you've installed .net 4.6.1 you won't encounter this error. It appears to have something related to
MSBuildRuntimeTypedefaulting to net461 if you're building with a target that's not 4.6.1@rboy1 commented on GitHub (Feb 13, 2023):
FYR: https://github.com/dsplaisted/strongnamer/issues/47
I don't know if this is something that needs to detect at runtime by Stron-Name Signer to see which libraries are being loaded at runtime which may be causing the issue.
@rboy1 commented on GitHub (Feb 14, 2023):
@brutaldev do you think it might be an issue with binding redirect? At runtime Strong-Name Signer isn't able to access the Mono-Cecil dll because it's being redirected to a different version of the assembly that doesn't exist. I'm asking because after updating to .NET 4.8 I'm seeing binding direct issues which never existed with .net 4.6.1