Good to know for future reference as I have take Blair's good advice and no
longer fool with CA's to touch the registry or the event source and do those
with wix elements. My only custom action left decodes a des256 string to get
credentials for when I create the service and that works well. Install feels
much cleaner now with the HKCU registry, and CA's for event sources and the
registry stuff gone and I can live with having the user's digital detritus
left behind if someone uninstalls my app ;-)
There was this one caveat on the win64 attribute -->
"Specifies that a script custom action targets a 64-bit platform. Valid only
when used with the Script, VBScriptCall, and JScriptCall attributes" Do you
think it should work with a .NET assembly which has so far been pretty easy
to create and use. I'll try this sometime in the near future and report on
it.
Rob, Thanks for yours Blair's and everyone's help. You folks are very
generous with your time and knowledge for WIX! My installs/uninstalls are
running well now and so it is time to get back to getting my application and
2 services enhanced having taken time to convert from the VS2008 setup
projects to WIX which I am much happier with. Switching to WIX was worth is
alone just to get rid of the irritating weirdness in VS2008 where my 3 setup
projects kept expanding randomly in the solution folder as I opened up other
projects. And there is a lot more control in WIX and it's extendable. Thanks
to all!
I don't see much need for a VS2008 GUI wrapper around wix projects but would
love to see some more official VS2009 integration with Powershell and WIX
building or other tasks such as zipping up related files when wanting a
package for someone. For a full release build, I build three x64 and three
x86 msi files from a Powershell script I launch from a VS2008 project that I
modified from a C# project shell. Then I have another VS2008 project zip
those up with some other things such as .doc and .bat files to get my user
going. It works pretty well since I can have dependencies on the other
projects and with PS V2 I can catch/throw and have VS2008 stop building upon
problems.
- Dave
-Original Message-
From: Rob Mensching [mailto:r...@robmensching.com]
Sent: Sunday, October 25, 2009 2:11 AM
To: General discussion for Windows Installer XML toolset.
Subject: Re: [WiX-users] How do I add both a HKLM and a HKCU key to the
registry?
If you mark your custom action as a 64-bit action it should run in a 64-bit
process. I haven't tried it with DTF since I write all my custom actions in
C/C++.
On Sat, Oct 24, 2009 at 7:37 PM, Dave Kolb
wrote:
> Good information Blair and thanks. I did not know about the EventSource
> element but should have guesses there likely was one.
>
> I will rethink what I am doing with the registry given your guidelines.
> Especially since I just realized that my custom action, built for "Any
> CPU",
> is running against the 32 bit hive and I have to drop into Win32 Interop
if
> I want to set registry redirection which I could but would rather not do.
>
> Not that I will necessarily pursue this same path, but for future
> reference,
> is there a way to force DTF to run a managed custom action written for
"Any
> CPU" to run in 64 bit mode besides compiling the assembly for "x64"?
>
> - Dave
>
> -Original Message-
> From: Blair [mailto:os...@live.com]
> Sent: Saturday, October 24, 2009 7:09 PM
> To: 'General discussion for Windows Installer XML toolset.'
> Subject: Re: [WiX-users] How do I add both a HKLM and a HKCU key to the
> registry?
>
> Back in the good-old-days we simply wrote in the registry until it looked
> like what this page describes:
>
> http://msdn.microsoft.com/en-us/library/aa363661(VS.85).aspx
>
> However, the Wix Util Extension does have an EventSource element that
seems
> to fit the billing. Does it not work for you?
>
> If you install per-user for three different users, each installation is
> independent from the others. Per-user installations should never install
> anything "common" unless they have some independent means of coordinating
> the use of the common areas. That is why the WiX implementation of the
> per-user/per-machine switch creates a program installation directory
inside
> of the user profile.
>
> Per-user data (such as windows coordinates, etc.) are considered user
data,
> not program data, and are typically left behind. Besides, if your
> per-machine program is used by three users, there is no safe way to
"clean"
> that data from any of the users not running the installation.
>
> Today's best practice says: the installation of per-machine programs
supply
> "default" configuration in HKLM and never touch HKCU. The program itself
> manages HKCU for each user's customizations to that configuration, and
that
> is then considered "user data". You then migrate it during first launch of
> your application after you upgrade, and you orphan it when you uninstall.
> That way there is ZERO user-profile a
