Lifestyle of the MSIdle - All Comments

re: CVS and CruiseControl.NET and password exposure

Christopher Painter — Mon, 22 Sep 2008 02:06:20 GMT

I read the title and first thing I thought of was the cvs login command. Ok, well, second thing... first thing was really VSTS/TFS rocks.

re: Vacation's Over!

Mom — Sat, 13 Sep 2008 14:58:43 GMT

Don't think we're ever on vacation - just taking a short break from the mundane.

re: Common Task: Optionally Cleanup User Data on Uninstall

SusanGorman — Fri, 05 Sep 2008 19:46:25 GMT

HookEm,

Yeah, I started out with custom actions to delete things, but it became undesirable for us for this reason:

By having the actions embedded in a custom action it was actually sort of hiding the actions from easy view. It defeats the table-driven intention of the MSI and moves code into, well, custom actions. We preferred to have the functionality more directly viewable in the tables.

That's also a good point about using UPGRADINGPRODUCTCODE. In our case, we DID want to ask the user what they wanted, so I'm keying off another property, but as you say, if you don't want to ask the user then the UPGRADINGPRODUCTCODE property is a good flag to use.

As always, excellent points!

re: Common Task: Optionally Cleanup User Data on Uninstall

HookEm — Fri, 05 Sep 2008 18:46:58 GMT

The conditioning of your custom "clean-up" CAs can be handled during an upgrade scenario by just using the standard MSI public property UPGRADINGPRODUCTCODE (msdn.microsoft.com/.../aa372380(VS.85).aspx).

The best way is to ask the user at uninstall whether or not they want to remove user data. If UPGRADINGPRODUCTCODE is set, don't ask the user to remove data and don't execute the CA that removes the data (b/c the uninstall is running during an upgrade scenario).

If you don't want to prompt the user, then best practice would be to leave the data when an uninstall is running via an upgrade scenario (UPGRADINGPRODUCTCODE is set) and remove the data if uninstall is being executed by the user via Add/Remove Programs / Software Explorer (NOT UPGRADINGPRODUCTCODE).

-C

re: I'm a slacker!

Christopher Painter — Tue, 02 Sep 2008 17:39:25 GMT

For your InstallScript issue, check out this thread:

community.acresso.com/showthread.php

It seems there is a hotfix KB article for IScript on 64bit OS that I think will help you.

Also I *believe* IS2009 doesn't use the TypeLib table anymore when doing COM Extract at build. If you don't want to upgrade, you could a) write a postbuild step that tweaks your output MSM or b) don't distribute merge modules, create a setup prereq instead ( since Microsoft offically says concurrent installs and third party merge modules now "suck" when it comes to servicing. )

re: What to do when there's nothing to do?

Airborne Bodhi — Fri, 08 Aug 2008 21:42:27 GMT

Hi Greg,

I look around the Internet to find old friends

as the world "gets smaller" on a daily basis.

This then brings me to the question: are you

The Greg David Gorman that at one time attended

SJV? It would be great to re-connect with you

if that is the case.

Your Old Pal,

Tommy Ward

re: RunOnce Key needed for limited user

jmcfadyen — Tue, 22 Jul 2008 07:51:15 GMT

hi Susan are you aware of Active Setup ? This could be another convenient way you can utilise a script driven user side action.

This is a non windows installer function and allows execution of any command line on a per user basis.

this is done by adding a key to

HKEY_LOCAL_MACHINE\SOFTWARE\Microsoft\Active Setup

cheers,

John

re: What to do when there's nothing to do?

SusanGorman — Wed, 02 Jul 2008 17:45:53 GMT

I love the idea of a single doc for the CAs as well as putting that doc in the Admin UI sequence. Good plan!

re: What to do when there's nothing to do?

HookEm — Wed, 02 Jul 2008 14:27:10 GMT

And if you want your MSI package to meet the MS Windows Logo Certification requirements then you know it's a requirement to provide system administrators with documentation explaining what each custom action in your MSI package does (except for type 19, 35, and 50 CAs).

If you use InstallShield to generate your package, they would have you create a separate text file for each CA. I hate that approach. I'd rather see all the CAs described in one document so I created an RTF file with a table for each CA that not only describes what each CA does, but also lists the type (broken down into the individual attribute flags such as "1+256+1024") and where it is sequenced in each of the sequence tables.

In addition, so as not to confuse the typical user who probably doesn't know anything about CAs or care what they are doing, I added a UI dialog to the Admin UI sequence that displays the RTF (similar to an EULA dialog) and allows the user running an administrative install in full UI mode to print the RTF.

re: Common Task: Validate a Path

SusanGorman — Tue, 20 May 2008 14:03:02 GMT

Great info, HookEm!

I checked this out and I put up a blog post commenting on this information.

gormanonline.com/.../customizing-the-pathedit-and-directorycombo-controls-to-validate-path-entries.aspx

Customizing the PathEdit and DirectoryCombo controls to validate path entries

Lifestyle of the MSIdle — Tue, 20 May 2008 13:53:58 GMT

My last post Common Tasks: Validating a Path received this comment from HookEm: Two of your 5 conditions

re: Common Task: Validate a Path

HookEm — Tue, 20 May 2008 04:19:55 GMT

Two of your 5 conditions can be handled without a custom action using the native MSI controls:

"Must be less than 200 characters in length": see the Text property of the PathEdit control (msdn.microsoft.com/.../aa370749(VS.85).aspx)

"must be on a fixed (local, non-removable) drive": see the available hexadecimal bit flags assignable to the Attributes property of the DirectoryCombo control (msdn.microsoft.com/.../aa368290(VS.85).aspx)

re: Basic Introduction to InstallShield and Windows Installer

SusanGorman — Thu, 08 May 2008 12:22:45 GMT

Totally right, Christopher.

Yes, you can also use InstallScript custom actions in a Basic MSI project.

The only thing it adds when you do that is InstallShield automatically embeds some run-time DLLs to the installation that it needs in order to be able to process the InstallScript.

Good point. Thanks!

re: Basic Introduction to InstallShield and Windows Installer

Christopher Painter — Wed, 07 May 2008 21:35:23 GMT

This is a nice article, but if I read it as a newbie, I'm left with the impression that there is only Basic MSI or InstallScript MSI. The reality is you can maintain a clean Basic MSI project but insert InstallScript CA's into the ControlEvents and Sequences in the same way you insert C++ CA's. This doesn't require the use of setup.exe, or the external UI handler.

You can easily migrate your VBScript CA's to InstallScript CA's. Other then differences between Session.Property( property ) and MsiGetProperty( handle, property, buffer, size ) line by line comparisons of VBScript and InstallScript functions are remarkably similar in appearance. C++ also looks alot like InstallScript except it's much more verbose as you have to write tomes of code to handle memory allocation and such.

Basic Introduction to InstallShield and Windows Installer

InstallSite Blog — Wed, 07 May 2008 07:56:43 GMT

Found a nice blog article by Susan Gorman that introduces Windows Installer and InstallShield's role