当程序集与强名称ke签名时，安装自定义操作失败 [英] Install custom action fails when assembly signed w/ strong name ke
问题描述
你好，
我有一个包含安装的C＃应用程序并运行
即服务的解决方案。该解决方案还包含几个DLL，其中一些是C＃
程序集，一些是C ++ DLL。服务应用程序引用了
DLL。该服务应用程序还有一个安装程序类，设置为在安装项目中作为
自定义操作运行。
我在签名时遇到问题集会。如果我向其中一个C＃DLL添加一个强名称密钥
，安装项目构建正常，但当我尝试将
安装在客户端计算机上时，安装失败在服务期间
自定义操作步骤。我得到无法在[我的服务]
程序集中获取安装程序类型。 - 无法加载一个或多个请求的类型。检索
LoaderExceptions属性以获取更多信息。
为什么在其中一个引用的程序集中添加强名称键导致
自定义操作以这种方式失败？我如何签署我的组件和
仍有自定义操作？
谢谢，
杰克
你好杰克，
从你的描述中，我知道你已经开发了一个Windows服务
通过Visual Studio，windows服务应用程序引用其他一些
c ++ dll和.net类库程序集（其中一些是强名称的）。
然而，你发现windows服务项目的安装程序
将失败（执行服务的安装程序自定义操作类时），
是否正确？
根据解决方案结构和装配设置，我在本地执行了一些测试。这是我的测试步骤：
1.创建VS 2005 Windows服务项目（添加安装程序类）
2.创建两个类库（c＃）项目在相同的解决方案和参考中
它们在主窗口服务项目中
3.使用密钥文件来强名称的类库项目
4.添加一个安装项目（参考windows服务项目的主要
输出）
但是，在启动安装程序包时，Windows服务可以正确部署，并复制引用的类库（强名称和
私有）。因此，我认为问题应该特定于你的解决方案中的其他内容。在您的解决方案中是否有任何特定类型引用
场景？
BTW，对于一般装配/装订故障排除，您可以使用
" fuslogvw.exe"实用程序，用于跟踪运行时如何定位和绑定
程序集：
#Assembly绑定日志查看器（Fuslogvw.exe）
http://msdn2.microsoft.com/en-us /lib...c4(VS.80).aspx
http://blogs.msdn.com/ianhu/archive/...12/663834.aspx
此致，
Steven Cheng
Microsoft MSDN在线支持主管
====== ============================================
通过电子邮件收到我的帖子通知？请参阅
http://msdn.microsoft .com / subscripti ... ult.aspx＃notif
ications。
注意：MSDN托管新闻组支持服务是针对非紧急问题
如果社区或微软支持人员在1个工作日内做出初步回复是可以接受的。请注意，每个跟随
的响应可能需要大约2个工作日作为支持
专业人士与您合作可能需要进一步调查才能达到
最有效的分辨率。该产品不适用于需要紧急，实时或基于电话的交互或复杂的b $ b项目分析和转储分析问题的情况。这种性质的问题最好通过联系
Microsoft客户支持服务（CSS）处理
href =http://msdn.microsoft.com/subscriptions/support/default.aspx\"target =_ blank> http://msdn.microsoft.com/subscripti...t/default.aspx 。
==================================== ==============
此帖子按原样提供。没有保证，也没有授予任何权利。
感谢您的回复，Steven。我将看一下使用fuslogvw.exe来获得更多的洞察力。
在你列出的重现我的问题的步骤中，我相信有你遗漏了一件事b $ b：我在我的windows中添加了一个安装程序类
服务项目，并为安装和提交添加了一个自定义操作
调用Service''安装程序类的步骤。请试试这个，然后看看是否
然后你遇到了我所看到的问题。如果我删除自定义操作，
部署没有问题。自定义操作会触发问题。
-
-Jack
Steven，
我已将fuslogvw.exe复制到客户端计算机并将其设置为Log all
绑定到磁盘。保存此设置后，我重新启动fuslogvw.exe然后运行
我的安装程序捕获导致无法获得
安装程序类型的绑定错误。 Fuslogvw.exe没有显示绑定错误。它列出的每个绑定
表示操作成功完成。这个
表明它不是一个引发这个问题的绑定错误。
-
-Jack
Hello,
I have a solution that contains a C# application that is installed and runs
as a service. The solution also contains several DLLs, some of which are C#
assemblies and some are C++ DLLs. The service application references the
DLLs. The service app also has an installer class that is set up to run as a
custom action in the Setup Project.
I am having a problem with signing an assembly. If I add a strong name key
to one of the C# DLLs, the setup project builds fine, but when I attempt to
install it on a client machine, installation fails during the service''s
custom action step. I get "Unable to get installer types in the [my service]
assembly. --Unable to load one ore more of the requested types. Retrieve
the LoaderExceptions property for more information."
Why does adding a strong name key to one of the referenced assemblies cause
the custom action to fail this way? And how can I sign my assemblies and
still have custom actions?
Thanks,
Jack
Hi Jack,
From your description, I understand you''ve developed an windows service
through Visual Studio, the windows service application reference some other
c++ dll and .net class library assemblies(some of which are strong-named).
However, you found that the setup program of the windows service project
will fail(when executing the service''s installer custom action class),
correct?
According to the solution structure and assembly settings, I have performed
some test on my local side. Here is my test steps:
1.Create a VS 2005 windows service project (add a installer class)
2. Create two class library(c#) projects in the same solution and reference
them in the main windows service project
3. use a keyfile to strong-name of of the class library project
4. add a setup project (reference to windows service project''s primary
output)
However, when launching the setup package, the windows service can be
correctly deployed, with the referenced class library(strong-named and
private ones) copied. Therefore, I think the problem should be specific to
something else of your solution. Is there any particular type referencing
scenario in your solution?
BTW, for general assembly loading/binding troubleshooting, you can use the
"fuslogvw.exe" utility to track how the runtime locating and binding the
assembly:
#Assembly Binding Log Viewer (Fuslogvw.exe)
http://msdn2.microsoft.com/en-us/lib...c4(VS.80).aspx
http://blogs.msdn.com/ianhu/archive/...12/663834.aspx
Sincerely,
Steven Cheng
Microsoft MSDN Online Support Lead
==================================================
Get notification to my posts through email? Please refer to
http://msdn.microsoft.com/subscripti...ult.aspx#notif
ications.
Note: The MSDN Managed Newsgroup support offering is for non-urgent issues
where an initial response from the community or a Microsoft Support
Engineer within 1 business day is acceptable. Please note that each follow
up response may take approximately 2 business days as the support
professional working with you may need further investigation to reach the
most efficient resolution. The offering is not appropriate for situations
that require urgent, real-time or phone-based interactions or complex
project analysis and dump analysis issues. Issues of this nature are best
handled working with a dedicated Microsoft Support Engineer by contacting
Microsoft Customer Support Services (CSS) at
http://msdn.microsoft.com/subscripti...t/default.aspx.
==================================================
This posting is provided "AS IS" with no warranties, and confers no rights.
Thank you for replying, Steven. I will take a look at using fuslogvw.exe to
gain more insight.
In the steps you have listed to reproduce my issue, I believe there is one
thing that you left out: I have added an Installer class to my windows
service project and have added a Custom Action for the Install and Commit
steps that calls the Service'' installer class. Please try this and see if
you then run into the problem I am seeing. If I remove the custom actions,
there is no problem with deployment. The custom actions trigger the problem.
--
-Jack
Steven,
I have copied fuslogvw.exe to the client machine and set it to "Log all
binds to disk." After saving this setting, I restarted fuslogvw.exe then ran
my installer to capture the binds that occur leading up to the "Unable to get
installer types" error. Fuslogvw.exe shows no binding errors. Every bind
that it lists states that the operation completed successfully. This
suggests that it is not a binding error that is triggering this problem.
--
-Jack
这篇关于当程序集与强名称ke签名时，安装自定义操作失败的文章就介绍到这了，希望我们推荐的答案对大家有所帮助，也希望大家多多支持IT屋！
