logo

CustomAction help

Micus posted on Friday, November 13, 2009 3:53 PM

Hello,

[VS 2003 Setup/Deployment project, Win Installer v2.0, C++]

I need some advice on CustomActions. My deployment project currently
has a CA during the install phase, which users enter a product key to verify
they are legitimate owners of the software. When the product key is
verified, the CA places an entry in the registry, which is referenced every
time the software is run. The CA is a dll with Install(MSIHANDLE) defined.
Everything works fine on all OS's except for Vista. I have found that with
Vista, any registry modifications have to be done in the Commit phase, not
the Install phase, of installation. If I move the CA to the Commit phase,
the installation is not rolled back when an invalid product key is entered.
What I need is a way to pass data entered in the Install phase CA to a CA in
the Commit phase to write info to the registry.

So far, I have tried defining 2 functions in the CA dll, Install(MSIHANDLE)
and Commit(MSIHANDLE). I tried using MsiSetProperty()/MsiGetProperty() to
pass data between the Install and Commit phases but  MsiSetProperty() fails
to create an installer property.

Install(MSIHANDLE mh)
{.
MsiSetProperty(mh, "NewProp", "DataString"); // returns non ERROR_SUCCESS
.}

I have also tried passing the data by writing a temp file in the windows
directory and reading it in the Commit CA - this also fails on Vista. The
file is not written.

The only other option that I can think of is using the clipboard but I was
hoping there was a cleaner way to pass the data. Another solution would be
to give the CA the rights of the user who launched the Install, but the
project does not have options to set the NonImpersonate flag for CAs.

Thanks In Advance,
M
reply


" I have found that with Vista, any registry modifications have to be done

Wilson, Phil replied to Micus on Friday, November 13, 2009 5:56 PM

the Commit phase, not the Install phase, of installation."

I think you are misunderstanding something here. Anyway, the issue is that
not until VS 2008 do VS setup projects do the right thing, which is to run
its custom actions without impersonation so they can in fact run elevated,
and yes, no versions of Visual Studio allow you to tweak those settings from
the UI. The UAC behavior is that even if you are administrator the
impersonated custom actions run as limited user, so they cannot do those
things requiring higher privilege.

--
Phil Wilson
The Definitive Guide to Windows Installer
http://www.apress.com/book/view/1590592972
reply

Thank you for your response.

Micus replied to Wilson, Phil on Friday, November 13, 2009 6:44 PM

Thank you for your response. My misunderstanding of the msi tech is not a
surprise, but I am trying. Do you have suggestions on how to pass data
between an Install CA and Commit CA?  I have VS 2003 EA mainly do to my apps
targeting Win 98 through the current OS's using VC++ and the Win32 API. VS
2008 does not target the old OS's or I'd buy it tonight.

Regards,
-M

in
from
defined.
not
phase,
CA
to
ERROR_SUCCESS
The
was
be
reply

Do not use a commit CA.

Kalle Olavi Niemitalo replied to Micus on Saturday, November 14, 2009 7:22 AM

Do not use a commit CA.  Put the code in the install CA, and set
the msidbCustomActionTypeNoImpersonate flag.  To do that, either
postprocess the MSI file generated by Visual Studio or switch to
some other tool entirely.  The postprocessing you could do with
WiRunSql.vbs or perhaps with Dennis Bareis' MAKEMSI.
reply

Not sure what you mean by "VS 2008 does not target the old OSs".

Phil Wilson replied to Micus on Saturday, November 14, 2009 2:23 PM

Not sure what you mean by "VS 2008 does not target the old OSs". You mean in
general or just setup projects?

--
Phil Wilson
[Microsoft MVP-Windows Installer]
reply

Thank you Kalle.

Micus replied to Phil Wilson on Saturday, November 14, 2009 3:37 PM

Thank you Kalle. Unfortunately, I do not have access to the
msidbCustomActionTypeNoImpersonate  [VS 2003 Setup/Deployment project, Win
Installer v2.0, C++].

Phil, from what I have read, the 2008 c++ compiler does not target Win98-WinME
OS's for non .NET applications.

Also, after creating some installation packages, I have found that I cannot
create a registry entry be it in the Install or Commit phase using CA's
(thus my misunderstanding?). I 'assumed' that I could...

So, my new question is: Given the setup project on VS 2003, is there any way
to create a registry entry in HKEY_LOCAL_MACHINE using a Custom Action?

I apologize for taking the scenic route,
-M


in
a
VS
done
that
phase,
a
reply

", the 2008 c++ compiler does not target Win98-WinME OS's for non .

Phil Wilson replied to Micus on Sunday, November 15, 2009 3:32 PM

applications."

Yes, but you want their setup projects that run custom actions with no
impersonation, not their C++ compiler. The only likely requirement is an
updated Windows Installer engine, 2.0 or 3.0.

To run inpersonated and elevated you would  have to launch the MSI from an
elevated prompt.

What are you writing to the registry that needs a custom action? (Rather
then the IDE)
--
Phil Wilson
reply

I am writing a software key to the registry that the installed

Micus replied to Phil Wilson on Monday, November 16, 2009 3:10 PM

I am writing a software key to the registry that the installed applications
check each time they are run. During installation, the CA prompts the user
to enter their software key. If the key is valid, the install completes,
otherwise the install is aborted. I have been playing around with
MsiSetProperty() in my CA to pass the key back to the installer, but the
function returns an invalid handle error. I am not even sure, even if I could
create a property, that I could use the property to create a registry entry
within the installer instead of the CA.

I think at this point, I need to either run a separate app before
installation, or pickup VS 2008 and hope I can configure an install package
that will satisfy my requirements.

Phil, Thank you for all your help.
-M

Win
cannot
mean
not
my
API.
to
reply

Where does the key come from?

Wilson, Phil replied to Micus on Monday, November 16, 2009 5:55 PM

Where does the key come from? If it is in an installer property than you can
just write it to the registry using the setup's Registry IDE in the same
whay you would  store the application folder by writing [TARGETDIR] or the cd key
using [PIDKEY] .
--
Phil Wilson
The Definitive Guide to Windows Installer
http://www.apress.com/book/view/1590592972
reply

If I recall correctly (it is a bit hazy), in order to get the rightprivileges

MikeMio replied to Micus on Thursday, November 19, 2009 11:12 PM

If I recall correctly (it is a bit hazy), in order to get the right
privileges for Vista, when using the older Visual Studio deployment projects,
you have to manually adjust the custom action type. This because, as Phil
mentioned, the older setup projects don???t set it correctly.

So, after creating the msi file, you have to manually adjust the custom
action type by turning on bit 12 (i.e. adding 0x800).

One way to do that is by opening Orca, finding the Custom Action table and
locating your function (your function name will appear in the 'Target'
column). Then take the value in the ???Type??? column and add 2048 (0x800) to it.
Save the changes and that???s it. It should work in Vista now.

I recall a Microsoft employee blog entry on the subject around the time
Vista was coming out but I can???t find a link.

Mike
reply

[Please do not mail me a copy of your followup]The main thing you are bashing

legalize+jeeve replied to Micus on Friday, November 20, 2009 5:27 PM

[Please do not mail me a copy of your followup]



The main thing you are bashing your head against here is the silly
constraints imposed on CAs by the VS.NET deployment project model.

The architecture I would use for your problem is this:

1) Dialog where the user is prompted for the serial number
information.  A custom action associated with the "Next" button on
this dialog validates the serial number and displays an error dialog
if the serial number is invalid.  This will prevent the install from
even starting if the serial number is invalid.  (There are some
slight additional work you want to do if you want to support a
UI-less install.)

2) If the serial number is valid, it is stored in a public property.
A public property is communicated between the UI phase and the system
modification phase.

3) The standard Registry actions are used to store the value of the
public property in the registry.

This approach still requires a custom action, but it is simpler than
the custom action you are attempting to write and it avoids all the
impersonation issues you are bumping into.

However, VS.NET deployment projects do not support directly authoring
this sort of scenario.  I always recommend using WiX instead of the
deployment project stuff because it is insufficient for all but the
simplest of installs.  You could easily recreate your installation as
a WiX project by using the WiX tools to decompile your MSI into a WiX
source file.
--
reply

In case you are still working on this, I found the blog article.

MikeMio replied to MikeMio on Thursday, November 26, 2009 12:21 PM

In case you are still working on this, I found the blog article. It is here:
https://blogs.msdn.com/astebner/archive/2006/10/23/mailbag-how-to-set-the-noimpersonate-flag-for-a-custom-action-in-visual-studio-2005.aspx
reply

 

Didn't Find The Answer You Were Looking For?

View Platform SDK MSI Posts   Ask A New Question

EggHeadCafe has experts online right now that may know the answer to your question.  We pay them a bonus for answering as many questions as they can.  So, why not help them and yourself by becoming a member (free) and ask them your question right now?
Create Account & Ask Question In Live Forum

Previous Platform SDK MSI conversation.

Mail    Networking Wireless    Plaform SDK Mapi    Platform SDK MSI    Platform SDK Security    Platform SDK Shell   




  $1000    Adam Houldsworth - $187  |  Jonathan VH - $139  |  Kirtan Patel - $117  |  F Cali - $116  |  Huggy Bear - $88  |  more Neado  |  Free Icons  |  Privacy  |   (c) 2010