6

I have a VS2010 .NET 4.0 VSTO Outlook Addin project that I wish to migrate to VS2012 (but keep it in .NET 4.0). It compiles fine, and runs from inside the IDE just fine, but when I attempt to run the published ClickOnce installer, I get the following exception:

System.Deployment.Application.InvalidDeploymentException: Exception reading manifest from file://MyPath/MyAddIn.vsto: the manifest may not be valid or the file could not be opened. ---> System.Deployment.Application.InvalidDeploymentException: Manifest XML signature is not valid. ---> System.Security.Cryptography.CryptographicException: SignatureDescription could not be created for the signature algorithm supplied.

Based on my tests and online research (here and there), it appears that just having VS2012 installed on my machine (whether I publish from VS2010 or VS2012) forces the ClickOnce installer to require a SHA1 certificate when using .NET 4.0. My existing SHA256 certificate works perfectly fine with .NET 4.0 when compiled using VS2010 (without VS2012 installed).

  • I can't upgrade clients to .NET 4.5 because this is a VSTO40 project (runs on XP/Office 2007).
  • I can't uninstall VS2012/.NET 4.5 on local machine because I have other projects that need it.
  • I can't easily downgrade my certificate from SHA256 to SHA1.

Are there any other suggestions to allow me to move forward?

Community
  • 1
  • 1
Lee Grissom
  • 9,705
  • 6
  • 37
  • 47

4 Answers4

10

I had this exact same error message and was using VS 2013, .NET 4.5, and signing everything correctly with SHA256.

Finally, I found that an older version of VSTO 2010 Runtime was installed (10.0.40303). Once we updated it to 10.0.40820 everything worked fine. Really hope this helps someone, drove me absolutely bonkers for days trying to figure out what was going on.

Lee Grissom
  • 9,705
  • 6
  • 37
  • 47
Brian
  • 101
  • 1
  • 3
  • Good find! I have the older version installed (and deployed to all my clients). Next chance I get, I'll try reverting to the SHA256 certificate and use the newer VSTO Runtime and see if that works. Thanks! – Lee Grissom Dec 21 '13 at 01:29
  • 2
    Note: A newer version of VSTO Runtime has been released today, it solves an "Unknown Publisher" issue that you might otherwise see with your SHA256 cert. http://blogs.msdn.com/b/vsto/archive/2014/04/10/vsto-runtime-update-to-address-slow-shutdown-and-unknown-publisher-for-sha256-certificates.aspx – Michael Zlatkovsky - Microsoft Apr 11 '14 at 01:06
  • Thanks Michael, this bailed me out after fighting with this for over a day. – Ryan Morlok Dec 03 '14 at 15:11
  • @Brian, I really owe you one. This should be the accepted answer. THANKS – Ignacio Soler Garcia Oct 04 '17 at 14:07
2

I solved my problem by creating a new certificate that is used to sign the ClickOnce manifest and generated it using the SHA1 algorithm. You can see the conversation here: http://social.msdn.microsoft.com/Forums/en-US/winformssetup/thread/eba424ae-f7b7-4530-bb68-db3b9972a31e

Edit 2014-Aug-05:
Visual Studio 2013 Update 3 finally fixes this problem.
http://support.microsoft.com/kb/2933779
From Fixed Issues -> General:

You can use SHA 256 code-signing certificates even for applications that target the .NET Framework 4.0 or an earlier version. Before this update, the .NET Framework 4.5 had to be present on the client computer when a SHA 256 code-signing certificate was used for desktop applications published with ClickOnce or Visual Studio Tools for Office add-ins. If you have used SHA 256 code-signing certificates in the past, and have seen errors such as "The application is improperly formatted," "The manifest may not be valid," "Manifest XML signature is not valid," or "SignatureDescription could not be created for the signature algorithm supplied," this update resolves the problem for re-published and newly-published applications.

Lee Grissom
  • 9,705
  • 6
  • 37
  • 47
1

Same with Visual Studio 2012 RTM. When i deploy the application in a clean Windows 7 ultimate machine i have "SignatureDescription could not be created for the signature algorithm supplied" Exception. Problem solved after the installation of .Net Framework 4.5 on the deployment machine.

ploffredi
  • 11
  • 2
  • Interesting, you're saying that you had to "install" .NET 4.5 whereas I had to "uninstall" .NET 4.5. – Lee Grissom Aug 21 '12 at 18:07
  • 1
    Yes, i had to install .net 4.5 in deployment(customer) machine. I think .net 4.5 has different way to verify clickonce manifest signature. If i publish the application without signature all works ok even without .net 4.5 installation in deployment(customer) machine. – ploffredi Aug 22 '12 at 03:47
  • Oh, I see. I thought you were talking about your build machine. My problem was occurring during the ClickOnce invocation stage. I'm not compiling with .NET 4.5 because my users are still using Windows XP. But they're due for a machine upgrade by year-end. :) – Lee Grissom Aug 22 '12 at 16:29
  • I'm compiling my apps with .NET 4.0. I "temporary" solved for my XP users removing manifest signature before publish – ploffredi Aug 23 '12 at 07:52
  • 1
    Found this useful blog http://blogs.msdn.com/b/smondal/archive/2012/08/24/signaturedescription-could-not-be-created-for-the-signature-algorithm-supplied.aspx – ploffredi Aug 25 '12 at 20:43
  • That is a a great blog post. It sounds like it explains my problem even though I swear I did not target .NET 4.5. You know what I think? I think that somehow under the hood, even though I'm targeting .NET 4.0, the in-place upgrade of some files and assemblies is what's causing the problem. I suspect I might be able to work around that issue if I put in some extra research effort. Unfortunately, I don't have time at the moment. I'll vote your answer up. When I get time to revisit this topic, if your input proves helpful, I'll mark your response as answer. – Lee Grissom Aug 29 '12 at 01:15
  • Starting with VS 2013 Update 3 RC (released July 2, 2014), this issue has been resolved. Namely, even if you are using a SHA256 certificate but targeting a lower version of .NET (e.g., 3.5 or 4.0), the manifest will be generated in such a way that it can still run on down-level .NET versions. You can get VS 2013 Update 3 RC from http://www.visualstudio.com/news/2014-jul-2-vs. – Michael Zlatkovsky - Microsoft Jul 10 '14 at 20:16
0

Edit: I later found out that the re-sign was the only thing that made this work. Ignore the stuff below about changing the .Net version.

I ran into this with a VSTO project, while publishing with Visual Studio 2015, targeting .Net 4.5, and running on a client machine with .Net 4.5. Theoretically I should not be seeing the error, but I found that the application manifest (*.dll.manifest) was still specifying .Net 4.0. It would work correctly the first tie it was run after logging in, but would then fail every time after that.

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

The version for .Net 4.5 is 4.0.30319.18020 as far as I can tell, so I put that in instead.

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

Then I had to re-sign the application and deployment manifests (*.vsto). See Signing and re-signing manifests in ClickOnce. Here is a PowerShell script I used to do that. It runs out of the Application Files\<application>_<version>\ folder.

# get files only, no directories
$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. I might add this as a post-publish MSBuild action or something, but for now this works.

Chris
  • 3,400
  • 1
  • 27
  • 41