SignatureDescription could not be created for the signature algorithm

Question

I'm deploying an update to a Word document-level add-in. In this update, I'm targeting .Net 4.5 instead of 4.0. I use ClickOnce for my deployments. This works fine on my dev machine and a few others.

At the customer site, it installs fine (although it prompts me when it probably shouldn't; the certificate trust chain should be valid), but when I try to run it, I get this error. All my googling suggests that this was a problem prior to Visual Studio 2013 Update 3 RC, and .Net versions prior to 4.5. I am using VS 2015 and I have verified that the target machine has .Net 4.5.

I have checked that my dev machine has the same version of VSTO (10.0.50903), so I don't think a newer version is required.

What else could be wrong here?

Answer 1

Hello,

As the issue is related to ClickOnce deployment, I would move this thread into ClickOnce and Setup & Deployment Projects  forum. Sorry for any inconvenience.

Regards,

Celeste

---

MSDN Community Support
Please remember to click "Mark as Answer" the responses that resolved your issue, and to click "Unmark as Answer" if not. This can be beneficial to other community members reading this thread. If you have any compliments or complaints to MSDN Support, feel free to contact [e-mail].

Answer 2

Hi Christopher,

Just as you have already inquired about the results described, the usual solution to this problem is to install .NET Framework 4.5 on client machines.

At first, I think you should know the reason that cause this issue, it is caused because .NET Framework 4.5 runtime is using SHA-256 as the default algorithm, however SHA-1 is used by default prior to .NET Framework 4.0.

And now we stopped using legacy certificates as default (SHA-1) in NetFX4.5 to sign manifest and instead, use newer version (SHA-256), which is not recognized by NetFx4.0 runtime, therefore, while parsing the manifest, 4.0 runtime complains of an invalid manifest.

However as you said you have already install .NET Framework 4.5, but the issue still exist, so I guess there are two solutions:

First you need to check whether the version you installed is valid, maybe there are some error in some step when you install it, I just said it might be, and I suggest you refer to the following link: https://msdn.microsoft.com/en-us/library/5a4x27ek(v=vs.110).aspx

The second solution is make sure the correct version of your target machine, if you can not install the valid 4.5 version, maybe you can only reinstall 4.0 version and recreate the certificate using SHA-1 algorithm, however this is not the best way if you can install the valid 4.5 version.

Hope this helps!

Best Regards,

Stanly

---

MSDN Community Support
Please remember to click "Mark as Answer" the responses that resolved your issue, and to click "Unmark as Answer" if not. This can be beneficial to other community members reading this thread. If you have any compliments or complaints to MSDN Support, feel free to contact [e-mail].

Answer 3

Thank you Stanley, I later considered that possibility. I tried it on another machine with .Net 4.6.1 and saw similar behavior.

There were two differences. The first is that I wasn't prompted to install it, which was a nice surprise. The second was that it runs correctly once after login, but every time after that it fails with the same error (though it may be I had not tried this particular use case on the other, so it might not be any different).

I checked the Trust Center log and the event viewer for error artifacts. The trust center log showed the same information during a failure as a success, except it cut off before checking fplace.dll, fdate.dll, etc. I believe those are related to Word's fields.

The event viewer showed the same error shown at runtime but with DLL information. I think it may be trying to target .Net 4.0 when it fails, which would make some amount of sense, given the error message. I see multiple listings like these two:

-----------------------------------------
Assembly Version: 4.0.0.0
Win32 Version: 4.6.1087.0 built by: NETFXREL4STAGE
CodeBase: file:///C:/Windows/Microsoft.Net/Framework/v4.0.30319/mscorlib.dll
-----------------------------------------

Assembly Version: 10.0.0.0
Win32 Version: 10.0.50903.0
CodeBase: file:///C:/Windows/Microsoft.Net/assembly/GAC_MSIL/Microsoft.VisualStudio.Tool.Office.Runtime/v4.0_10.0.0.0_b03f5f7f11d50a3a/Microsoft.VisualStudio.Tool.Office.Runtime.dll
-----------------------------------------

The reason for the framework version change is to support TLS 1.2, which means going back to 4.0 is a very last resort option.

Answer 4

Hi Christopher,

I think so, if there are not another better solution, maybe go back to 4.0 version is a alternative solution.

Hope you can work well.

Regards,

---

MSDN Community Support
Please remember to click "Mark as Answer" the responses that resolved your issue, and to click "Unmark as Answer" if not. This can be beneficial to other community members reading this thread. If you have any compliments or complaints to MSDN Support, feel free to contact [e-mail].

Answer 5

I believe I have found a solution. The application manifest contained this tag:

<dependency>
    <dependentAssembly dependencyType="preRequisite" allowDelayedBinding="true">
      <assemblyIdentity name="Microsoft.Windows.CommonLanguageRuntime" version="4.0.30319.0" />
    </dependentAssembly>
  </dependency>

I changed it to this:

<dependency>
    <dependentAssembly dependencyType="preRequisite" allowDelayedBinding="true">
      <assemblyIdentity name="Microsoft.Windows.CommonLanguageRuntime" version="4.0.30319.18020" />
    </dependentAssembly>
  </dependency>

As that appears to be the version for .Net 4.5. So far it is working. Unfortunately it requires resigning the manifests (see Signing and re-signing manifests in ClickOnce). I made a powershell script to do this, which I'm including here. It runs out of the Application Files\<application>_<version>\ folder

    $withDeploy = ls -Recurse | where Mode -eq "------" | where Name -Like "*.deploy"

    if ($withDeploy.Length -gt 0)
    {
        # rename .deploy files
        $withDeploy | %{ Rename-Item -Path $_.FullName -NewName $_.FullName.Replace(".deploy", "") }

        $certPath = "Z:\path\to\your\cert\file"
        $certFile = "$certPath\cert.p12"
        $certPass = "<your_password>"

        # re-sign the application manifest; should be <application>*.dll.manifest
        $manifestFile = ls | where Name -like "*.dll.manifest" | %{ return $_.Name }
        mage -Update $manifestFile -CertFile $certFile -Password $certPass

        # re-sign the deployment manifest; *.vsto
        $vstoFile = ls | where Name -like "*.vsto" | %{ return $_.FullName }
        #mage -Update $vstoFile -AppManifest $manifestFile -CertFile $certFile -Password $certPass

        $otherVstoFile = ls "..\..\" | where Name -like "*.vsto" | %{ return $_.FullName }
        mage -Update $otherVstoFile -AppManifest $manifestFile -CertFile $certFile -Password $certPass
        Copy-Item $otherVstoFile $vstoFile

        # put .deploy back
        $withDeploy | %{ Rename-Item -Path $_.FullName.Replace(".deploy", "") -NewName $_.FullName }
    }

Ideally it would be preferable to make a change to the Visual Studio project so that I don't have to do this every time I publish, but I don't see a way to do that, and any solution is better than no solution.

Answer 6

Hi Christopher,

Glad you can find a solution, I suggest you can mark the solution as answer so that people who have the same confusion can quickly find the answer, thanks for your sharing at the same time.

Best Regards,

Stanly

---

MSDN Community Support
Please remember to click "Mark as Answer" the responses that resolved your issue, and to click "Unmark as Answer" if not. This can be beneficial to other community members reading this thread. If you have any compliments or complaints to MSDN Support, feel free to contact [e-mail].