coapp-developers team mailing list archive

[Rob Mensching <rob@xxxxxxxxxxxxxxxx>]

Everything in the core WiX namespace does map cleanly to the Windows
Installer layer. The Game Explorer stuff you mentioned comes from an
extension because the Windows Installer does not support Game Explorer
natively (and thus a Custom Action).

The fact that you couldn't tell fills me with much happiness (some might say
glee) because the goal is to make it all seem very seamless. <smile/>

On Thu, May 20, 2010 at 9:35 AM, Adam Kennedy <adam@xxxxxx> wrote:

> Thanks for the clarity, I had assumed that most of the WiX tags mapped
> cleanly to assets in the underlying layer.
>
> Adam K
>
> On Thu, May 20, 2010 at 10:36 AM, Rob Mensching <rob@xxxxxxxxxxxxxxxx>
> wrote:
> > Note that the game explorer
> install/uninstall/repair/upgrade/patch/rollback
> > in the WiX toolset is actually implemented by a Custom Action. We call it
> > one of the "WiX Standard Custom Actions".
> > It's hard to write Custom Actions correctly and people often use them
> > improperly which leads to Garrett's comment.
> >
> > virtually,
> >     Rob Mensching
> >     http://RobMensching.com LLC
> > On Wed, May 19, 2010 at 7:49 PM, Adam Baxter <voltagex@xxxxxxxxxxxx>
> wrote:
> >>
> >> Ah, that makes more sense. Thanks.
> >>
> >> On Thu, May 20, 2010 at 12:46 PM, Adam Kennedy
> >> <adamkennedybackup@xxxxxxxxx> wrote:
> >>>
> >>> Off the top of my head...
> >>>
> >>> WiX already has elements in it to add something to the game explorer,
> >>> so it isn't an action.
> >>>
> >>> Likewise, folder structure isn't an action either.
> >>>
> >>> Activation keys are needed to run something, not install it, so the
> >>> app should really ask itself at first startup.
> >>>
> >>> Registry additions have WiX elements, it's not an action either.
> >>>
> >>> Adam K
> >>>
> >>> On 19 May 2010 22:29, Adam Baxter <voltagex@xxxxxxxxxxxx> wrote:
> >>> > Hi,
> >>> > Do you think each package type should have pre and post install
> >>> > actions?
> >>> >
> >>> > For example,
> >>> > * an executable package might register itself to the Games Explorer
> on
> >>> > Vista/7 after installation
> >>> > * a source package might need a very specific folder structure
> >>> > * an executable might require non-CoApp resources to run, for example
> >>> > an
> >>> > activation key or data files from a CD (think a free application with
> >>> > non-free addons)
> >>> > * a package that is saving some configuration details to the registry
> >>> > (not
> >>> > recommended, limits portable installations)
> >>> > and so on
> >>> >
> >>> > If so, what would be the best way to document this? I was just going
> to
> >>> > add
> >>> > a "Pre & Post Install" section to each package blueprint.
> >>> >
> >>> > --Adam
> >>> > _______________________________________________
> >>> > Mailing list: https://launchpad.net/~coapp-developers<https://launchpad.net/%7Ecoapp-developers>
> >>> > Post to     : coapp-developers@xxxxxxxxxxxxxxxxxxx
> >>> > Unsubscribe : https://launchpad.net/~coapp-developers<https://launchpad.net/%7Ecoapp-developers>
> >>> > More help   : https://help.launchpad.net/ListHelp
> >>> >
> >>> >
> >>
> >>
> >> _______________________________________________
> >> Mailing list: https://launchpad.net/~coapp-developers<https://launchpad.net/%7Ecoapp-developers>
> >> Post to     : coapp-developers@xxxxxxxxxxxxxxxxxxx
> >> Unsubscribe : https://launchpad.net/~coapp-developers<https://launchpad.net/%7Ecoapp-developers>
> >> More help   : https://help.launchpad.net/ListHelp
> >>
> >
> >
>
>


-- 
virtually, Rob Mensching - http://RobMensching.com LLC