Strongname signature size in F# project using new sdk base project running msbuild only

[jmecosta]

Hi,

we got a new developer machine that we installed VS 2015 and VS 2017 with F# support. We got some errors during compilation that i cant replicate in any other dev machine. Visual studio works perfectly fine

"e:\prod\structures\work\Test\TestTools\TestAdapters\TestAdapters.sln" (default target) (1) ->
"e:\prod\structures\work\Test\TestTools\TestAdapters\NunitRunnerTask\NunitRunnerTask.fsproj" (default target) (12) ->
(CoreCompile target) ->
FSC : error FS2014: A problem occurred writing the binary 'E:\prod\structures\work\ObjDrop\Work\Debug\x64\NunitRunnerTask\NunitRunnerTask.dll': A call to StrongNameSignatureSize failed (Access is denied. (Exceptio
n from HRESULT: 0x80070005 (E_ACCESSDENIED))) [e:\prod\structures\work\Test\TestTools\TestAdapters\NunitRunnerTask\NunitRunnerTask.fsproj]

This goes away if i dont sign the assembly

dev2.txt is the environment that is broken
dev2.txt
dev.txt

i have 2 detalied build logs, one ok and another not ok. The envs are very similar.
dev2-log.zip
dev-log.zip

Error is comming from F# during signing. can you try to help with this.

thanks

[cartermp]

@KevinRansom Any ideas?

[augustoproiete]

I'm having the same issue. It's currently not possible to strong-name sign an FSharp Class Library (.NET Framework).

Attached is a repro example. There's nothing special in this project... It's a pure File -> New -> Project -> F# Library (.NET Framework) v4.8 in Visual Studio 2019.

Error FS2014 A problem occurred writing the binary 'C:\augustoproiete\TestFSharpStrongName\TestFSharpStrongName\obj\Debug\TestFSharpStrongName.dll': A call to StrongNameSignatureSize failed (Access is denied. (Exception from HRESULT: 0x80070005 (E_ACCESSDENIED))) TestFSharpStrongName FSC

• TestFSharpStrongName.zip

[cartermp]

@KevinRansom have you had a chance to look at this?

[atomicmattie]

I've been seeing the same message on an internal project in VS2019:

FS2014 A problem occurred writing the binary 'C:\…\obj\Debug\netstandard2.0\….dll': A call to StrongNameSignatureSize failed (Access is denied. (Exception from HRESULT: 0x80070005 (E_ACCESSDENIED)))

My colleagues aren't having this problem, though. One thing my setup has that's different from theirs is that I do all of my work as a regular user, not an administrator—my machine has two accounts, an admin and mine, and I run all software and do all development under my account, using the admin's password to elevate when UAC asks me to.

[zanaptak]

I just encountered (and managed to resolve) this issue on a system. Running as a user in Administrators group, but non-elevated, it fails. In an elevated admin command prompt, it succeeds. Another symptom is the command sn -k test.key failing with a similar error.

In Sysinternals procmon tool, there were Access Denied errors on C:\ProgramData\Microsoft\Crypto\RSA\MachineKeys.

Administrators group had Full Control on the folder, inherited from parent, and the Windows properties dialog showed my account had an effective access level of Full Control. So by appearances the Access Denied made no sense.

But the overall makeup of permissions on that directory differed from a working system. There were 4 accounts with inherited permissions, whereas the working system only had 2 accounts, with non-inherited folder-only permissions. The working system was a recent clean install of Windows 10 version 2004.

Changing the permissions to match the working system, even though it didn't change reported effective access level in the UI, successfully resolved the issue.

The working permissions are here: https://support.microsoft.com/en-us/help/278381/default-permissions-for-the-machinekeys-folders. It is an old Windows 2003 article, but the permissions are the same as my recent Windows 10 version 2004 install.

• Administrators
  • (Full Control) This folder only
• Everyone
  • (Special) This folder only
    • List Folder/Read Data
    • Read Attributes
    • Read Extended Attributes
    • Create Files/Write Data
    • Create Folders/Append Data
    • Write Attributes
    • Write Extended Attributes
    • Read Permissions

Your mileage may vary, use at your own risk, etc. No idea yet if this has affected anything else on the system.

[dsyme]

@cartermp @KevinRansom I'm struggling to give this a severity, can you assess please?

[KevinRansom]

If we have scenarios where signing doesn't wpork that's severe. The code around that hasn't been touched in an absolute age. I will work on it.

Access is denied would indicate that the file is opened and locked for writing, elsewhere. So it shouldn't be too hard to track down.

[dsyme]

Could you also compare with #8817, is this the same issue?

[KevinRansom]

So as @zanaptac identified this is a permissions issue with C:\ProgramData\Microsoft\Crypto\RSA\MachineKeys

Once I removed the special permisssions from this directory I became able to reproduce this issue. Now I have to figure out how to repair my machine, since I foolishly did it on my main dev box.
"What a superstar" I hear you say voice dripping with sarcasm ... whilst my boss shakes his head and mutters "reckless fool".

Sigh!!! off to figure out how to restore my permissions.