ClickOnce前提条件:错误:已发布的安装程序可能已损坏 [英] ClickOnce Prerequisite : Error: published installer may be corrupt

查看:250
本文介绍了ClickOnce前提条件:错误:已发布的安装程序可能已损坏的处理方法,对大家解决问题具有一定的参考价值,需要的朋友们下面随着小编来一起学习吧!

问题描述

我创建了一个自定义安装程序包,以在客户端计算机上安装一些字体,并将其部署到C:\Program Files (x86)\Microsoft SDKs\Windows\v7.0A\Bootstrapper\Packages\FontsInstaller下的prerequisites文件夹中.将其作为Visual Studio 2010中的前提条件,一切都很好,并且我能够毫无问题地发布该应用程序.

I've created a custom setup package to install some fonts on a client machine and deployed it to the prerequisites folder under C:\Program Files (x86)\Microsoft SDKs\Windows\v7.0A\Bootstrapper\Packages\FontsInstaller. Everything is fine with reference it as a prerequisite in Visual Studio 2010 and I am able to publish the application without issue.

另一方面,客户端在哈希验证期间出错:

The client on the other hand gets an error during the Hash verification:

验证文件哈希

错误:安装程序检测到文件'C:\ Users \ RMORAN〜1 \ AppData \ Local \ Temp \ VSD4684.tmp \ FontsInstaller \ fontsinstaller.msi'自首​​次发布以来已更改或可能已损坏.

Error: Setup has detected that the file 'C:\Users\RMORAN~1\AppData\Local\Temp\VSD4684.tmp\FontsInstaller\fontsinstaller.msi' has either changed since it was initially published or may be corrupt.

我尝试过使用Bootstrapper清单生成器包括哈希值并将其排除在外,并且我总是在客户端上得到相同的结果.一旦哈希验证失败,该文件将立即被删除(出于安全原因).

I've tried including the hash and excluding it with the Bootstrapper Manifest Generator and I always get the same result on the client. The file is immediately deleted (for security reasons) as soon as it fails hash verification.

现在,我发现 Microsoft Connect错误报告说:

"我已安装了自定义引导程序包,这是我的应用程序的先决条件.当我在安装了Visual Studio 2012的系统上进行构建时,安装失败,并显示以下错误:

"I have a custom bootstrapper package installed as a prerequisite for my application. When I build this on a system that has Visual Studio 2012 installed, the installation fails with the following error:

安装程序检测到文件'...'自最初发布以来已更改,或者可能已损坏.

Setup has detected that the file '...' has either changed since it was initially published or may be corrupt.

我正在Visual Studio 2010中进行构建,而对该程序包或项目没有任何更改.当未安装Visual Studio 2012时,它将按预期工作."

I am building in Visual Studio 2010, with no changes to the package or projects. When Visual Studio 2012 is not installed, this works as expected."

我尝试在未安装VS2012的另一个工作站上构建此安装程序,并且该安装程序在客户端上通过了哈希验证(我遇到了签名问题,但那是另一回事).具有VS2012而不是客户端的构建计算机确实存在问题,因为在我的原始工作站上构建的软件包在不具有VS2012的计算机上也会失败.

I tried building this installer on another workstation with no VS2012 installed, and it passes the hash validation on the client (I ran into a signing issue, but thats a different story). It really is a problem with the build machine having VS2012, not the client, as the package built on my original workstation also fails on the machine that does not have VS2012.

其他人是否遇到过此问题,如果是这样,除了未安装VS2012以外,您是否找到了解决方法?

Has anyone else experienced this issue, if so, have you found a workaround besides not having VS2012 installed?

推荐答案

我使用了一个反射工具来查看引导程序生成MSBuild任务(在安装了.NET 4.5的计算机上),发现它增强了product.xml文件的<PackageFile />元素.具体来说,它尝试从每个文件计算公钥.如果可以找到,则将键与PublicKey属性的值进行比较.如果值不同,则会发出警告,但在两种情况下都将保留刚刚计算出的值.

I used a reflection tool to look at the bootstrapper generation MSBuild task (on a machine with .NET 4.5 installed) and found that it augments the product.xml file's <PackageFile /> elements. Specifically, it attempts to compute a public key from each file. If it can find one, it compares the key with the value of the PublicKey attribute. If the values are different, it emits a warning but in both cases it keeps the value it just computed.

如果无法确定公钥,则它将计算文件的SHA256哈希值,并与Hash属性的值进行相似的比较,如果它们不同则发出警告,并设置具有计算值的Hash属性.

If it couldn't determine a public key, it then computes a SHA256 hash of the file and performs a similar comparison with the value of the Hash attribute, emitting a warning if they are different and setting the value of the Hash attribute with the computed value.

您可以通过从所得的setup.exe中提取SETUPCFG资源来确认这些发现;这是product.xml文件合并的文本版本.

You can confirm these findings by extracting the SETUPCFG resource from the resulting setup.exe; it's a text version of a merge of the product.xml files.

无论如何,还记得我说过的话,如果找不到公共密钥,它将如何计算文件的SHA256哈希? < PackageFiles>的文档元素(Bootstrapper)表示Hash属性的值应为SHA1哈希.

Anyway, remember how I said it computes a SHA256 hash of the files if it could not find a public key? The documentation for the <PackageFiles> Element (Bootstrapper) says the value of the Hash attribute should be a SHA1 hash.

我无法验证结果setup.exe使用哪个SHA1或SHA256来验证Hash属性的值(它是非托管代码,我无法找到它的符号),但请记录下来显示对引导生成器MSBuild任务的.NET 4.0版本的类似观察表明,它确实是在使用SHA1算法来计算Hash属性的值,因此通过推论我们可以说setup.bin(至少Windows SDK v7.0A中的一种)正在使用SHA1.我很确定我尝试使用Windows SDK v8.0A中的setup.bin,并且得到了相同(错误)结果. (可以通过将setup.bin从v8.0A SDK复制到仅.NET 4.0的计算机上,并查看生成的setup.exe是否可以使用基于散列的验证来安装自定义引导程序包,来确认这一点)

I was not able to verify which of SHA1 or SHA256 the resulting setup.exe uses to verify the value of the Hash attribute (it's unmanaged code and I couldn't find the symbols for it), but let the record show that a similar look at the .NET 4.0 version of the bootstrapper generator MSBuild task reveals that it is indeed using the SHA1 algorithm for computing the value of the Hash attribute, so by deduction we can say setup.bin (at least the one from the Windows SDK v7.0A) is using SHA1. I'm pretty sure I tried using the setup.bin from the Windows SDK v8.0A and I got the same (wrong) results. (One could confirm this by copying the setup.bin from the v8.0A SDK to a .NET 4.0-only machine and seeing if the resulting setup.exe can install a custom bootstrapper package using hash-based verification)

因此,如果在安装程序引导程序中破坏了基于哈希的验证,我们至少可以使用公钥(基于证书)验证.好消息是,如果引导程序生成器能够从包文件中提取证书的公钥,它将自动开始使用此机制.坏消息是,这意味着每个软件包文件必须使用signtool.exe和有效的代码签名证书进行签名(并非每个人都可能拥有代码签名证书,尽管如果这样做的话)单击一次,您就可以...).

So, if hash-based verification is broken in the setup bootstrapper, we can at least use the public key (certificate-based) verification instead. The good news is that the bootstrapper generator will automatically start using this mechanism if it was able to extract the certificate's public key from the package file. The bad news is that this means each package file must be signed with signtool.exe and a valid code-signing certificate (not everybody might have a code-signing certificate lying around, although if you're doing click-once you might...).

一旦我对自定义引导程序使用的软件包文件进行了签名,当我使用安装了.NET 4.5的计算机构建项目时,在运行时就停止出现安装失败,同时在使用计算机时仍会生成有效的引导程序没有安装.NET 4.5的计算机.

Once I signed the package files used by our custom bootstrapper, I stopped getting the installation failures at run-time when I built the project using a machine that had .NET 4.5 installed, while still producing a valid bootstrapper when using a machine that did not have .NET 4.5 installed.

tl; dr:使用代码签名证书对软件包文件进行签名,以避免.NET 4.5中引入的缺陷.

tl;dr: Sign your package files with a code-signing certificate to avoid a defect introduced in .NET 4.5.

这篇关于ClickOnce前提条件:错误:已发布的安装程序可能已损坏的文章就介绍到这了,希望我们推荐的答案对大家有所帮助,也希望大家多多支持IT屋!

查看全文
登录 关闭
扫码关注1秒登录
发送“验证码”获取 | 15天全站免登陆