Install custom action fails when assembly signed w/ strong name ke

[Guest]

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

 

[Steven Cheng[MSFT]]

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/library/e74a18c4(VS.80).aspx

http://blogs.msdn.com/ianhu/archive/2006/07/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/subscriptions/managednewsgroups/default.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/subscriptions/support/default.aspx.

==================================================



This posting is provided "AS IS" with no warranties, and confers no rights.

 

[Guest]

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.

 

[Guest]

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.

 

[Steven Cheng[MSFT]]

Thanks for your reply Jack,

If the fuslogvw utility can not capture the error, it seems the assembly is
correctly located and bound. For the "installer class custom action", I did
have added a installer class in the windows service and create custom
action item for it in the setup project. Do you mean any other custom
actoin? I've added the installer class(in windows service project) and
custom action(in setup project) follow this kb article:

#How to create a setup project for a Windows Service application in Visual
C# .NET and in Visual C# 2005
http://support.microsoft.com/kb/816169/

Please let me know if this is what you mean. If you feel necessary, I can
send you my test solution through email since it is a quite simple and
typical one.

Sincerely,

Steven Cheng

Microsoft MSDN Online Support Lead


This posting is provided "AS IS" with no warranties, and confers no rights.

 

[Guest]

Steven,

Yes. That is what I meant regarding a custom action. I wasn't sure if you
used that step in your test as the steps 1-4 that you have listed didn't
mention specifically adding the custom action to the setup project.

Please do send your sample project for me to take a look at.

Thanks,
Jack

 

[Guest]

Steven,

It has been a nearly full day and I haven't yet received your sample
solution via email. Please send it my way as soon as you can.

Thanks,
Jack

 

[Steven Cheng[MSFT]]

Hi Jack,

Sorry for the delay. Would you send a mail to my email (the one in my
signature and remove the "online") so that I can get your address and send
it to you offline?

Sincerely,

Steven Cheng

Microsoft MSDN Online Support Lead


This posting is provided "AS IS" with no warranties, and confers no rights.

 

[Steven Cheng[MSFT]]

Hi Jack,

I have sent you a test setup solution package, have you received it and
tested it on your side? If there is any new finding or anything need help,
please feel free to post here.

Sincerely,

Steven Cheng

Microsoft MSDN Online Support Lead


This posting is provided "AS IS" with no warranties, and confers no rights.

 

[Guest]

Hi Steven,

I apologize - I didn't realize you had posted back to here, as for some
reason this thread is not being bumped to the top of the listing for this
forum after a new post is added when viewed using the web-based MSDN Managed
Newsgroups viewer. Also, I didn't receive an email notification of your
reply, even though I have "notify me of replies" checked whenever I post to
this forum using the web-based MSDN Managed Newsgroups viewer.

In any event, I sent an email to you today with the results of my search and
am posting them here for posterity. Your simple sample solution seems to
work, but it didn't help me to figure out why my real-world solution failed
to perform my custom actions when I strong name keyed any of the assemblies.
However, through a bunch of UseNet searching and reading of MSDN blogs, I
found a lot of information about using managed code to write custom actions.
Basically, it's not a good idea and is not even supported by Windows
Installer. Why Visual Studio makes it so easy to do via Installer Classes is
a philosophical question that I haven't found an answer for, but the advice
given is that your custom actions should be written in native C++. So that's
what I've done over the past couple of weeks. I have re-written our custom
actions in native, unmanaged C++ and everything seems to be working well now.
Thanks for your help on this matter.

 

[Steven Cheng[MSFT]]

Thanks for your followup Jack,

So you've changed the custom action to a pure unmanaged c++ one and make it
working. For .net managed custom action, it it provided for those ones who
prefer .net programming language and want to develop custom actions
conveniently. Also, this require that .net framework runtime become a
prerequisiute for such setup package.

Here, I'm not sure what's the exact cause make managed custom action not
working for your scenario. Anyway, glad that you've found a way to make it
working.

Thanks again for your posting .

Sincerely,

Steven Cheng

Microsoft MSDN Online Support Lead


This posting is provided "AS IS" with no warranties, and confers no rights.