Windows Installer XML (WiX) toolset › wix-users

(no subject)

17 messages

(no subject)

Reply Threaded

The WiX manual contains the following:

"The first is a RemoveFolder element, which ensures the
ApplicationProgramsFolder is correctly removed from the Start Menu when the
user uninstalls the application. The second creates a registry entry on
install that indicates the application is installed."

I have two question about this:

(1) Why do I have to care about removing the start menu folder? I know, that
this is some issue with the Windows Installer Server (even I actually do not
understand the issue). But since it is a *general* issue that *any* Start
Menu folder will suffer from, why does WiX not solve the problem on it's own
but instead forces the .wsi author to remind this in each and every .wsi
file?

(2) If I (as an MSI beginner) understood correctly, the idea of the key file
is to have one unique "thing" that Windows Installer will check to see if
the component is installed currently. What I do not understand here is, why
the the abovementioned example is using an artifical (not further needed)
registry key to remind itself about the need to remove the Start Menu
folder? I mean, why isn't it possible to reference the start menu folder
itself, or at least, why not referencing the installation's main file
instead of introducing an artificial registry entry?

Sorry for my silly questions, but I want to really understand this, and MSDN
does not really say why but only what.

Thanks

Markus

------------------------------------------------------------------------------
Come build with us! The BlackBerry(R) Developer Conference in SF, CA
is the only developer event you need to attend this year. Jumpstart your
developing skills, take BlackBerry mobile applications to market and stay
ahead of the curve. Join us from November 9 - 12, 2009. Register now!
http://p.sf.net/sfu/devconference
_______________________________________________
WiX-users mailing list
[hidden email]
https://lists.sourceforge.net/lists/listinfo/wix-users

Blair-2

Re: (no subject)

Reply Threaded

Read the descriptions of the following ICEs: ICE18, ICE38, ICE43, ICE57*,
ICE64, & ICE91. (I'm sure I'm missing one or more additional pertinent ones
somewhere)
*ICE57 doesn't check the value of ALLUSERS because that property can be
overridden during an installation, so if it thinks the referenced location
*might* be user-profile, it is considered user-profile.

In general, any installation that puts things in both per-machine and
per-profile locations will eventually (depending on circumstances,
especially with roaming profiles and with multiple users on the same box)
"cause problems", either with reinstallation or with orphaning data, or
both. It is best to make your installations pure-perMachine or pure-perUser
and never mix them, and treat data generated during the running of the
application as user data, not program data (even if it isn't formatted for
the user's direct use nor placed in their "Documents" (or "My Documents")
folder).

Since the directory property values associated with the Start menu vary
(based on ALLUSERS) and can be profile data (but don't have to be) the ICE
tests kick in and impose requirements that, for pure perMachine
installations, often seem completely brain-dead. Since the requirement that
the ICE test is intending to protect you from may not apply to your
installation, you may not want the requirement to add useless additional
registry keys in places you prohibit yourself from placing resources. WiX
supplying those additional resources on your behalf without you knowing or
explicitly consenting to would not be considered a good thing by many who
depend on authoring and knowing exactly what is in their packages, and who
are prepared to deal with ignoring certain ICE reports they consider
irrelevant to their package.

"... roaming profiles seemed like such a good idea at the time ..."
wistfully heard around SetupLand.

The rational for using registry instead of file location for the Start menu
is this:
If the keypath of the component is user "A"s Start menu, then user "B" will
never have a shortcut (since it points to a particular non-profile-generic
location. If, on the other hand, the keypath is a HKCU registry key/value,
then when user "B" touches the installation, they will get the shortcut
added because its component will be seen as "missing" invoking a repair.
However, you shouldn't do that to your users since you should be putting
your shortcuts in "All Users" if you install perMachine, and B will never be
able to access the program if it was installed perUser in A's profile,
negating the problem in the first place. Thus, the logic of the ICE is
flawed, in my opinion, if you employ reasonable rules, and may possibly be
ignored. However, if you are seeking approval for Windows Logo, you may not
be able to ignore these ICEs (I don't really know, I have never submitted an
application for Logo), thus "your mileage may vary".

In C++, if I forget to call delete in a tight loop that calls new and leak
memory as a result, I don't want the compiler calling delete for me, since
that tight loop may actually be storing those pointers somewhere (it may not
be a memory leak after all). Same principles apply here. Just as C++ gives
you the Windows Platform with only some protection, WiX gives you Windows
Installer with only some protection. It hands you the loaded gun. It doesn't
force the direction in which you point it. That direction is up to you. Just
as you have to understand the technology you program to make effective and
secure use of it, you have to understand the technology you author to make
effective and secure use of it.

Just because many of the other toolsets for Windows Installer try to hide
the technology (and usually do unsafe or unreliable things as a result)
from the developer doesn't mean that WiX should. Back in the 90s we used to
say that VB protected you from the platform and C++ allowed you to hang
yourself with it. Both VB and C++ have progressed since then, but the basic
idea is still the same: if you want/need the power of the platform, you go
with the tool that gives you that power, but with that comes the
responsibility to understand the platform. Tools that don't give you the
full power may never be able to address all your needs (or may become so
complex in attempting to do so in a safe fashion that you get caught in the
seams) that they become too expensive one way or another for your needs.

Yes, we recognize that Windows Installer is a technology area that hasn't
yet received enough good documentation and explanation. Some of us are
working on that (slowly, as we can). Please keep these questions coming.
They help us remember what we didn't understand when we were first
confronted with this space, and that is invaluable in trying to get us to
improve the way we disseminate the "tribal knowledge" associated with
application deployment and servicing on Windows Platforms.

-----Original Message-----
From: Markus Karg [mailto:[hidden email]]
Sent: Sunday, November 01, 2009 8:48 AM
To: 'General discussion for Windows Installer XML toolset.'
Subject: [WiX-users] (no subject)

The WiX manual contains the following:

"The first is a RemoveFolder element, which ensures the
ApplicationProgramsFolder is correctly removed from the Start Menu when the
user uninstalls the application. The second creates a registry entry on
install that indicates the application is installed."

I have two question about this:

(1) Why do I have to care about removing the start menu folder? I know, that
this is some issue with the Windows Installer Server (even I actually do not
understand the issue). But since it is a *general* issue that *any* Start
Menu folder will suffer from, why does WiX not solve the problem on it's own
but instead forces the .wsi author to remind this in each and every .wsi
file?

(2) If I (as an MSI beginner) understood correctly, the idea of the key file
is to have one unique "thing" that Windows Installer will check to see if
the component is installed currently. What I do not understand here is, why
the the abovementioned example is using an artifical (not further needed)
registry key to remind itself about the need to remove the Start Menu
folder? I mean, why isn't it possible to reference the start menu folder
itself, or at least, why not referencing the installation's main file
instead of introducing an artificial registry entry?

Sorry for my silly questions, but I want to really understand this, and MSDN
does not really say why but only what.

Thanks

Markus

----------------------------------------------------------------------------
--
Come build with us! The BlackBerry(R) Developer Conference in SF, CA
is the only developer event you need to attend this year. Jumpstart your
developing skills, take BlackBerry mobile applications to market and stay
ahead of the curve. Join us from November 9 - 12, 2009. Register now!
http://p.sf.net/sfu/devconference
_______________________________________________
WiX-users mailing list
[hidden email]
https://lists.sourceforge.net/lists/listinfo/wix-users

------------------------------------------------------------------------------
Come build with us! The BlackBerry(R) Developer Conference in SF, CA
is the only developer event you need to attend this year. Jumpstart your
developing skills, take BlackBerry mobile applications to market and stay
ahead of the curve. Join us from November 9 - 12, 2009. Register now!
http://p.sf.net/sfu/devconference
_______________________________________________
WiX-users mailing list
[hidden email]
https://lists.sourceforge.net/lists/listinfo/wix-users

Markus KARG

Per User / Per Machine

Reply Threaded

Blair,

in a different context you wrote:

> It is best to make your installations pure-perMachine or pure-
> perUser
> and never mix them

There is one thing I do not understand in that context: I always had the
impression that it is up to the *administrator* to decide whether to install
a software Per User / Per Machine: Isn't that what msiexec's /ju and /jm
options are good for?

Now reading your above comment (and the MSDN chapter about the ALLUSERS
property) I am a bit confused.

If it is up to the .msi *author* to decide about Per User / Per Machine
(using the ALLUSERS property), for what is /ju and /jm good then? And what
will happen if my .msi file is for Per User, but the administrator is using
/jm (or vice versa)?

Thanks
Markus

------------------------------------------------------------------------------
Come build with us! The BlackBerry(R) Developer Conference in SF, CA
is the only developer event you need to attend this year. Jumpstart your
developing skills, take BlackBerry mobile applications to market and stay
ahead of the curve. Join us from November 9 - 12, 2009. Register now!
http://p.sf.net/sfu/devconference
_______________________________________________
WiX-users mailing list
[hidden email]
https://lists.sourceforge.net/lists/listinfo/wix-users

Blair-2

Re: Per User / Per Machine

Reply Threaded

All resources (files, registry entries, etc.) can generally be divided into
three spaces: those that live in administrator per-machine areas (C:\Program
Files, etc.), those that live in the user profile, and those very few that
live in shared document regions.

If your installation requires access to administrator-controlled regions of
the computer, it should be a pure perMachine and NOT place anything in
perUser (profile) areas, and vice-versa. Until MSI 5.0 (which is currently
only available on Windows 7 AFAIK) it has been extremely difficult to author
a package that can go either way, although it was somewhat easier before
Vista/UAC entered the picture.

Administrators are supposed to follow author's guidelines when using
advertising to make a program available to users. /ju and /jm don't actually
install the software and they don't set ALLUSERS.

Also, personally, I haven't found /ju to be very useful: it doesn't provide
a place to designate the user to advertise to, and if that user doesn't
already have admin privileges, the command will fail while if the user does
have those privileges, the command isn't needed. Then again, maybe I haven't
found the magic incantation yet.

-----Original Message-----
From: Markus Karg [mailto:[hidden email]]
Sent: Monday, November 02, 2009 11:01 AM
To: 'General discussion for Windows Installer XML toolset.'
Subject: [WiX-users] Per User / Per Machine

Blair,

in a different context you wrote:

> It is best to make your installations pure-perMachine or pure-
> perUser
> and never mix them

There is one thing I do not understand in that context: I always had the
impression that it is up to the *administrator* to decide whether to install
a software Per User / Per Machine: Isn't that what msiexec's /ju and /jm
options are good for?

Now reading your above comment (and the MSDN chapter about the ALLUSERS
property) I am a bit confused.

If it is up to the .msi *author* to decide about Per User / Per Machine
(using the ALLUSERS property), for what is /ju and /jm good then? And what
will happen if my .msi file is for Per User, but the administrator is using
/jm (or vice versa)?

Thanks
Markus

----------------------------------------------------------------------------
--
Come build with us! The BlackBerry(R) Developer Conference in SF, CA
is the only developer event you need to attend this year. Jumpstart your
developing skills, take BlackBerry mobile applications to market and stay
ahead of the curve. Join us from November 9 - 12, 2009. Register now!
http://p.sf.net/sfu/devconference
_______________________________________________
WiX-users mailing list
[hidden email]
https://lists.sourceforge.net/lists/listinfo/wix-users

------------------------------------------------------------------------------
Come build with us! The BlackBerry(R) Developer Conference in SF, CA
is the only developer event you need to attend this year. Jumpstart your
developing skills, take BlackBerry mobile applications to market and stay
ahead of the curve. Join us from November 9 - 12, 2009. Register now!
http://p.sf.net/sfu/devconference
_______________________________________________
WiX-users mailing list
[hidden email]
https://lists.sourceforge.net/lists/listinfo/wix-users

Markus KARG

Re: Per User / Per Machine

Reply Threaded

Blair,

now I am more confused than before. On one hand you say, I shall write a
.msi that is either perUser OR perMachine, on the other hand you say that it
is very hard to do when not using MSI 5 (which is only available on Windows
7). So for me this reads like: "For a MSI beginner it is impossible to write
a correctly working setup on any OS before W7.";-(

Regards
Markus

> -----Original Message-----
> From: Blair [mailto:[hidden email]]
> Sent: Montag, 2. November 2009 21:43
> To: 'General discussion for Windows Installer XML toolset.'
> Subject: Re: [WiX-users] Per User / Per Machine
>
> All resources (files, registry entries, etc.) can generally be divided
> into
> three spaces: those that live in administrator per-machine areas
> (C:\Program
> Files, etc.), those that live in the user profile, and those very few
> that
> live in shared document regions.
>
> If your installation requires access to administrator-controlled
> regions of
> the computer, it should be a pure perMachine and NOT place anything in
> perUser (profile) areas, and vice-versa. Until MSI 5.0 (which is
> currently
> only available on Windows 7 AFAIK) it has been extremely difficult to
> author
> a package that can go either way, although it was somewhat easier
> before
> Vista/UAC entered the picture.
>
> Administrators are supposed to follow author's guidelines when using
> advertising to make a program available to users. /ju and /jm don't
> actually
> install the software and they don't set ALLUSERS.
>
> Also, personally, I haven't found /ju to be very useful: it doesn't
> provide
> a place to designate the user to advertise to, and if that user doesn't
> already have admin privileges, the command will fail while if the user
> does
> have those privileges, the command isn't needed. Then again, maybe I
> haven't
> found the magic incantation yet.
>
> -----Original Message-----
> From: Markus Karg [mailto:[hidden email]]
> Sent: Monday, November 02, 2009 11:01 AM
> To: 'General discussion for Windows Installer XML toolset.'
> Subject: [WiX-users] Per User / Per Machine
>
> Blair,
>
> in a different context you wrote:
>
> > It is best to make your installations pure-perMachine or pure-
> > perUser
> > and never mix them
>
> There is one thing I do not understand in that context: I always had
> the
> impression that it is up to the *administrator* to decide whether to
> install
> a software Per User / Per Machine: Isn't that what msiexec's /ju and
> /jm
> options are good for?
>
> Now reading your above comment (and the MSDN chapter about the ALLUSERS
> property) I am a bit confused.
>
> If it is up to the .msi *author* to decide about Per User / Per Machine
> (using the ALLUSERS property), for what is /ju and /jm good then? And
> what
> will happen if my .msi file is for Per User, but the administrator is
> using
> /jm (or vice versa)?
>
> Thanks
> Markus
>
>
> -----------------------------------------------------------------------
> -----
> --
> Come build with us! The BlackBerry(R) Developer Conference in SF, CA
> is the only developer event you need to attend this year. Jumpstart
> your
> developing skills, take BlackBerry mobile applications to market and
> stay
> ahead of the curve. Join us from November 9 - 12, 2009. Register now!
> http://p.sf.net/sfu/devconference
> _______________________________________________
> WiX-users mailing list
> [hidden email]
> https://lists.sourceforge.net/lists/listinfo/wix-users
>
>
> -----------------------------------------------------------------------
> -------
> Come build with us! The BlackBerry(R) Developer Conference in SF, CA
> is the only developer event you need to attend this year. Jumpstart
> your
> developing skills, take BlackBerry mobile applications to market and
> stay
> ahead of the curve. Join us from November 9 - 12, 2009. Register now!
> http://p.sf.net/sfu/devconference
> _______________________________________________
> WiX-users mailing list
> [hidden email]
> https://lists.sourceforge.net/lists/listinfo/wix-users

Blair-2

Re: Per User / Per Machine

Reply Threaded

Sorry if I am confusing you.

I recommend you decide upfront if your installation will be per-user or
per-machine. Don't try to make a package that is intended to be switchable.

Then author the package based on your decision.

MSI 5 (Windows 7 or Windows Server 2008 R2) is required to make workable
packages that can be switched during installation. However, the advice is
still: don't do it. Make it one or the other and prevent the one you don't
support.

-----Original Message-----
From: Markus Karg [mailto:[hidden email]]
Sent: Tuesday, November 03, 2009 9:28 AM
To: 'General discussion for Windows Installer XML toolset.'
Subject: Re: [WiX-users] Per User / Per Machine

Blair,

now I am more confused than before. On one hand you say, I shall write a
.msi that is either perUser OR perMachine, on the other hand you say that it
is very hard to do when not using MSI 5 (which is only available on Windows
7). So for me this reads like: "For a MSI beginner it is impossible to write
a correctly working setup on any OS before W7.";-(

Regards
Markus

Andreas Mertens

Re: Per User / Per Machine

Reply Threaded

I have been following this thread (as it has a definite impact on what I am
working on).
Searching through the online MSDN docs, I came across the following that
describes Per Machine/Per User installs and the impact of the ALLUSERS
variable. It has also been updated with the Windows 7 details.

http://msdn.microsoft.com/en-us/library/aa367559(VS.85).aspx

I hope this sheds some light. One thing I need to figure out is using the
"All User" profile for installation vs. doing a Per Machine install.

Andreas

-----Original Message-----
From: Blair [mailto:[hidden email]]
Sent: November-03-09 9:47 PM
To: 'General discussion for Windows Installer XML toolset.'
Subject: Re: [WiX-users] Per User / Per Machine

Sorry if I am confusing you.

I recommend you decide upfront if your installation will be per-user or
per-machine. Don't try to make a package that is intended to be switchable.

Then author the package based on your decision.

MSI 5 (Windows 7 or Windows Server 2008 R2) is required to make workable
packages that can be switched during installation. However, the advice is
still: don't do it. Make it one or the other and prevent the one you don't
support.

-----Original Message-----
From: Markus Karg [mailto:[hidden email]]
Sent: Tuesday, November 03, 2009 9:28 AM
To: 'General discussion for Windows Installer XML toolset.'
Subject: Re: [WiX-users] Per User / Per Machine

Blair,

now I am more confused than before. On one hand you say, I shall write a
.msi that is either perUser OR perMachine, on the other hand you say that it
is very hard to do when not using MSI 5 (which is only available on Windows
7). So for me this reads like: "For a MSI beginner it is impossible to write
a correctly working setup on any OS before W7.";-(

Regards
Markus

----------------------------------------------------------------------------
--
Come build with us! The BlackBerry(R) Developer Conference in SF, CA
is the only developer event you need to attend this year. Jumpstart your
developing skills, take BlackBerry mobile applications to market and stay
ahead of the curve. Join us from November 9 - 12, 2009. Register now!
http://p.sf.net/sfu/devconference
_______________________________________________
WiX-users mailing list
[hidden email]
https://lists.sourceforge.net/lists/listinfo/wix-users

----------------------------------------------------------------------------
--
Let Crystal Reports handle the reporting - Free Crystal Reports 2008 30-Day
trial. Simplify your report design, integration and deployment - and focus
on
what you do best, core application coding. Discover what's new with
Crystal Reports now. http://p.sf.net/sfu/bobj-july
_______________________________________________
WiX-users mailing list
[hidden email]
https://lists.sourceforge.net/lists/listinfo/wix-users

------------------------------------------------------------------------------
Let Crystal Reports handle the reporting - Free Crystal Reports 2008 30-Day
trial. Simplify your report design, integration and deployment - and focus on
what you do best, core application coding. Discover what's new with
Crystal Reports now. http://p.sf.net/sfu/bobj-july
_______________________________________________
WiX-users mailing list
[hidden email]
https://lists.sourceforge.net/lists/listinfo/wix-users

Andreas Mertens

Re: Per User / Per Machine

Reply Threaded

In reply to this post by Blair-2

Not to flog a dead horse or anything, but consider this scenario

I create my single installer package. Inside I provide two different
features:
- Feature 1: All Users (Per Machine) install, will required elevation
- Feature 2: Per User install, can be installed by any standard user or
better.

Structure the UI so that only one of the two features can be set.

So here are a few scenarios:
Scenario A:
- I install for All Users (as admin). Everyone can use it.
- If another user tries to install again, it goes to Maintenance mode as per
usual.
- Only if the user is an admin could he change it from All Users to Current
User in maintenance mode. Or Uninstall, Repair, etc.

Scenario B:
- I install for Current User. Only I can see the install
- If another (standard) user performs the installation, they can perform the
Current User install (only) and can access the installation. Either I or
the other user can uninstall our instances without impact on the other.
- If a user (admin) performs an install for All Users, I am not sure what
would happen. But all users should be able to access the installation. My
installation would either still be my primary installation, or it would be
superseded by the All Users install. Either way I could still run the
installed product. I could later uninstall my installation and still have
access to the All Users installation.

Does this make any sense? Are there any drawbacks to this thinking?

Thanks,

Andreas Mertens

-----Original Message-----
From: Blair [mailto:[hidden email]]
Sent: November-03-09 9:47 PM
To: 'General discussion for Windows Installer XML toolset.'
Subject: Re: [WiX-users] Per User / Per Machine

Sorry if I am confusing you.

I recommend you decide upfront if your installation will be per-user or
per-machine. Don't try to make a package that is intended to be switchable.

Then author the package based on your decision.

MSI 5 (Windows 7 or Windows Server 2008 R2) is required to make workable
packages that can be switched during installation. However, the advice is
still: don't do it. Make it one or the other and prevent the one you don't
support.

-----Original Message-----
From: Markus Karg [mailto:[hidden email]]
Sent: Tuesday, November 03, 2009 9:28 AM
To: 'General discussion for Windows Installer XML toolset.'
Subject: Re: [WiX-users] Per User / Per Machine

Blair,

now I am more confused than before. On one hand you say, I shall write a
.msi that is either perUser OR perMachine, on the other hand you say that it
is very hard to do when not using MSI 5 (which is only available on Windows
7). So for me this reads like: "For a MSI beginner it is impossible to write
a correctly working setup on any OS before W7.";-(

Regards
Markus

Markus KARG

Re: Per User / Per Machine

Reply Threaded

In reply to this post by Blair-2

But how to do that, "author the package based on your decision"?

I mean, I just have two files, one program menu item and one extension verb.
The .wxs file is more or less a copy of the WiX manual's samples / WiX
tutorial code snippets.

The WiX manual does not say something about "authoring the packaging based
on your decision", nor does the WiX tutorial.

Is it enough to just set the ALLUSERS property, or how is that to be done
"author the package based on your decision"?

Sorry for one more silly questions, but I just can't find a How-To for that.

Thanks
Markus

> -----Original Message-----
> From: Blair [mailto:[hidden email]]
> Sent: Mittwoch, 4. November 2009 06:47
> To: 'General discussion for Windows Installer XML toolset.'
> Subject: Re: [WiX-users] Per User / Per Machine
>
> Sorry if I am confusing you.
>
> I recommend you decide upfront if your installation will be per-user or
> per-machine. Don't try to make a package that is intended to be
> switchable.
>
> Then author the package based on your decision.
>
> MSI 5 (Windows 7 or Windows Server 2008 R2) is required to make
> workable
> packages that can be switched during installation. However, the advice
> is
> still: don't do it. Make it one or the other and prevent the one you
> don't
> support.
>
> -----Original Message-----
> From: Markus Karg [mailto:[hidden email]]
> Sent: Tuesday, November 03, 2009 9:28 AM
> To: 'General discussion for Windows Installer XML toolset.'
> Subject: Re: [WiX-users] Per User / Per Machine
>
> Blair,
>
> now I am more confused than before. On one hand you say, I shall write
> a
> .msi that is either perUser OR perMachine, on the other hand you say
> that it
> is very hard to do when not using MSI 5 (which is only available on
> Windows
> 7). So for me this reads like: "For a MSI beginner it is impossible to
> write
> a correctly working setup on any OS before W7.";-(
>
> Regards
> Markus
>
> > -----Original Message-----
> > From: Blair [mailto:[hidden email]]
> > Sent: Montag, 2. November 2009 21:43
> > To: 'General discussion for Windows Installer XML toolset.'
> > Subject: Re: [WiX-users] Per User / Per Machine
> >
> > All resources (files, registry entries, etc.) can generally be
> divided
> > into
> > three spaces: those that live in administrator per-machine areas
> > (C:\Program
> > Files, etc.), those that live in the user profile, and those very few
> > that
> > live in shared document regions.
> >
> > If your installation requires access to administrator-controlled
> > regions of
> > the computer, it should be a pure perMachine and NOT place anything
> in
> > perUser (profile) areas, and vice-versa. Until MSI 5.0 (which is
> > currently
> > only available on Windows 7 AFAIK) it has been extremely difficult to
> > author
> > a package that can go either way, although it was somewhat easier
> > before
> > Vista/UAC entered the picture.
> >
> > Administrators are supposed to follow author's guidelines when using
> > advertising to make a program available to users. /ju and /jm don't
> > actually
> > install the software and they don't set ALLUSERS.
> >
> > Also, personally, I haven't found /ju to be very useful: it doesn't
> > provide
> > a place to designate the user to advertise to, and if that user
> doesn't
> > already have admin privileges, the command will fail while if the
> user
> > does
> > have those privileges, the command isn't needed. Then again, maybe I
> > haven't
> > found the magic incantation yet.
> >
> > -----Original Message-----
> > From: Markus Karg [mailto:[hidden email]]
> > Sent: Monday, November 02, 2009 11:01 AM
> > To: 'General discussion for Windows Installer XML toolset.'
> > Subject: [WiX-users] Per User / Per Machine
> >
> > Blair,
> >
> > in a different context you wrote:
> >
> > > It is best to make your installations pure-perMachine or pure-
> > > perUser
> > > and never mix them
> >
> > There is one thing I do not understand in that context: I always had
> > the
> > impression that it is up to the *administrator* to decide whether to
> > install
> > a software Per User / Per Machine: Isn't that what msiexec's /ju and
> > /jm
> > options are good for?
> >
> > Now reading your above comment (and the MSDN chapter about the
> ALLUSERS
> > property) I am a bit confused.
> >
> > If it is up to the .msi *author* to decide about Per User / Per
> Machine
> > (using the ALLUSERS property), for what is /ju and /jm good then? And
> > what
> > will happen if my .msi file is for Per User, but the administrator is
> > using
> > /jm (or vice versa)?
> >
> > Thanks
> > Markus
> >
> >
> > ---------------------------------------------------------------------
> --
> > -----
> > --
> > Come build with us! The BlackBerry(R) Developer Conference in SF, CA
> > is the only developer event you need to attend this year. Jumpstart
> > your
> > developing skills, take BlackBerry mobile applications to market and
> > stay
> > ahead of the curve. Join us from November 9 - 12, 2009. Register now!
> > http://p.sf.net/sfu/devconference
> > _______________________________________________
> > WiX-users mailing list
> > [hidden email]
> > https://lists.sourceforge.net/lists/listinfo/wix-users
> >
> >
> > ---------------------------------------------------------------------
> --
> > -------
> > Come build with us! The BlackBerry(R) Developer Conference in SF, CA
> > is the only developer event you need to attend this year. Jumpstart
> > your
> > developing skills, take BlackBerry mobile applications to market and
> > stay
> > ahead of the curve. Join us from November 9 - 12, 2009. Register now!
> > http://p.sf.net/sfu/devconference
> > _______________________________________________
> > WiX-users mailing list
> > [hidden email]
> > https://lists.sourceforge.net/lists/listinfo/wix-users
>
>
> -----------------------------------------------------------------------
> -----
> --
> Come build with us! The BlackBerry(R) Developer Conference in SF, CA
> is the only developer event you need to attend this year. Jumpstart
> your
> developing skills, take BlackBerry mobile applications to market and
> stay
> ahead of the curve. Join us from November 9 - 12, 2009. Register now!
> http://p.sf.net/sfu/devconference
> _______________________________________________
> WiX-users mailing list
> [hidden email]
> https://lists.sourceforge.net/lists/listinfo/wix-users
>
>
> -----------------------------------------------------------------------
> -------
> Let Crystal Reports handle the reporting - Free Crystal Reports 2008
> 30-Day
> trial. Simplify your report design, integration and deployment - and
> focus on
> what you do best, core application coding. Discover what's new with
> Crystal Reports now. http://p.sf.net/sfu/bobj-july
> _______________________________________________
> WiX-users mailing list
> [hidden email]
> https://lists.sourceforge.net/lists/listinfo/wix-users

Blair-2

Re: Per User / Per Machine

Reply Threaded

Some items' ultimate locations depend on the ALLUSERS value. Some examples:

HKCR is really a merge of a key under HKLM and a different key under HKCU.
If ALLUSERS is set to 1, you get the HKLM registration, otherwise (when it
is blank) you get the HKCU one.

The predefined property StartMenuFolder varies its value based on ALLUSERS
as well. See the following table:
Type of Install REFKNOWNFOLDERID CSIDL
Per-machine CommonStartMenu CSIDL_COMMON_STARTMENU
Per-user StartMenu CSIDL_STARTMENU

The portion of your authoring for items using those two values are "easy"
since the actual authoring doesn't change. However, the location of the
binary that the verb and the shortcut point to need to be in a location that
will be correctly identified, and that location should vary based on what
value of ALLUSERS you are supporting (if you use ProgramFilesFolder, for
instance, the location you get will be in a non-profile location that
requires elevation to access, that is, a per-machine location, so you can't
really use it in a per-user package.)

-----Original Message-----
From: Markus Karg [mailto:[hidden email]]
Sent: Wednesday, November 04, 2009 10:53 AM
To: 'General discussion for Windows Installer XML toolset.'
Subject: Re: [WiX-users] Per User / Per Machine

But how to do that, "author the package based on your decision"?

I mean, I just have two files, one program menu item and one extension verb.
The .wxs file is more or less a copy of the WiX manual's samples / WiX
tutorial code snippets.

The WiX manual does not say something about "authoring the packaging based
on your decision", nor does the WiX tutorial.

Is it enough to just set the ALLUSERS property, or how is that to be done
"author the package based on your decision"?

Sorry for one more silly questions, but I just can't find a How-To for that.

Thanks
Markus

Markus KARG

Re: Per User / Per Machine

Reply Threaded

Blair,

thank you very much for your detailed answer. :-)

So if I understand correctly, all I have to do is to set ALLUSERS to 1? Ok,
nice. :-)

But actually, after decades of seeing lots of installers asking the
administrator where the *he* wants the files get copied to, I do not
understand why it is up to *the .msi author* to decide about this...
(actually I do not see any sense in deciding this *per .msi file* at all, as
virtually all currently installed products are installed *per machine*
anyways since no Windows before Seven was able to do a pure per-user
install, and nobody ever seriously complained about that, and with a
decision *per .msi file* chaos is likely to come...: "Hey admin, why can I
execute all programs but not this one? Why can everybody but me execute this
program? And why did it work on Vista but on Seven it is just vanished from
my Start menu?"). For me as a MSI starter this reads like: "You can't do it
right. I will fail anyways." ;-)

Regards
Markus

> -----Original Message-----
> From: Blair [mailto:[hidden email]]
> Sent: Donnerstag, 5. November 2009 12:57
> To: 'General discussion for Windows Installer XML toolset.'
> Subject: Re: [WiX-users] Per User / Per Machine
>
> Some items' ultimate locations depend on the ALLUSERS value. Some
> examples:
>
> HKCR is really a merge of a key under HKLM and a different key under
> HKCU.
> If ALLUSERS is set to 1, you get the HKLM registration, otherwise (when
> it
> is blank) you get the HKCU one.
>
> The predefined property StartMenuFolder varies its value based on
> ALLUSERS
> as well. See the following table:
> Type of Install REFKNOWNFOLDERID CSIDL
> Per-machine CommonStartMenu CSIDL_COMMON_STARTMENU
> Per-user StartMenu CSIDL_STARTMENU
>
> The portion of your authoring for items using those two values are
> "easy"
> since the actual authoring doesn't change. However, the location of the
> binary that the verb and the shortcut point to need to be in a location
> that
> will be correctly identified, and that location should vary based on
> what
> value of ALLUSERS you are supporting (if you use ProgramFilesFolder,
> for
> instance, the location you get will be in a non-profile location that
> requires elevation to access, that is, a per-machine location, so you
> can't
> really use it in a per-user package.)
>
> -----Original Message-----
> From: Markus Karg [mailto:[hidden email]]
> Sent: Wednesday, November 04, 2009 10:53 AM
> To: 'General discussion for Windows Installer XML toolset.'
> Subject: Re: [WiX-users] Per User / Per Machine
>
> But how to do that, "author the package based on your decision"?
>
> I mean, I just have two files, one program menu item and one extension
> verb.
> The .wxs file is more or less a copy of the WiX manual's samples / WiX
> tutorial code snippets.
>
> The WiX manual does not say something about "authoring the packaging
> based
> on your decision", nor does the WiX tutorial.
>
> Is it enough to just set the ALLUSERS property, or how is that to be
> done
> "author the package based on your decision"?
>
> Sorry for one more silly questions, but I just can't find a How-To for
> that.
>
> Thanks
> Markus
>
> > -----Original Message-----
> > From: Blair [mailto:[hidden email]]
> > Sent: Mittwoch, 4. November 2009 06:47
> > To: 'General discussion for Windows Installer XML toolset.'
> > Subject: Re: [WiX-users] Per User / Per Machine
> >
> > Sorry if I am confusing you.
> >
> > I recommend you decide upfront if your installation will be per-user
> or
> > per-machine. Don't try to make a package that is intended to be
> > switchable.
> >
> > Then author the package based on your decision.
> >
> > MSI 5 (Windows 7 or Windows Server 2008 R2) is required to make
> > workable
> > packages that can be switched during installation. However, the
> advice
> > is
> > still: don't do it. Make it one or the other and prevent the one you
> > don't
> > support.
> >
> > -----Original Message-----
> > From: Markus Karg [mailto:[hidden email]]
> > Sent: Tuesday, November 03, 2009 9:28 AM
> > To: 'General discussion for Windows Installer XML toolset.'
> > Subject: Re: [WiX-users] Per User / Per Machine
> >
> > Blair,
> >
> > now I am more confused than before. On one hand you say, I shall
> write
> > a
> > .msi that is either perUser OR perMachine, on the other hand you say
> > that it
> > is very hard to do when not using MSI 5 (which is only available on
> > Windows
> > 7). So for me this reads like: "For a MSI beginner it is impossible
> to
> > write
> > a correctly working setup on any OS before W7.";-(
> >
> > Regards
> > Markus
> >
> > > -----Original Message-----
> > > From: Blair [mailto:[hidden email]]
> > > Sent: Montag, 2. November 2009 21:43
> > > To: 'General discussion for Windows Installer XML toolset.'
> > > Subject: Re: [WiX-users] Per User / Per Machine
> > >
> > > All resources (files, registry entries, etc.) can generally be
> > divided
> > > into
> > > three spaces: those that live in administrator per-machine areas
> > > (C:\Program
> > > Files, etc.), those that live in the user profile, and those very
> few
> > > that
> > > live in shared document regions.
> > >
> > > If your installation requires access to administrator-controlled
> > > regions of
> > > the computer, it should be a pure perMachine and NOT place anything
> > in
> > > perUser (profile) areas, and vice-versa. Until MSI 5.0 (which is
> > > currently
> > > only available on Windows 7 AFAIK) it has been extremely difficult
> to
> > > author
> > > a package that can go either way, although it was somewhat easier
> > > before
> > > Vista/UAC entered the picture.
> > >
> > > Administrators are supposed to follow author's guidelines when
> using
> > > advertising to make a program available to users. /ju and /jm don't
> > > actually
> > > install the software and they don't set ALLUSERS.
> > >
> > > Also, personally, I haven't found /ju to be very useful: it doesn't
> > > provide
> > > a place to designate the user to advertise to, and if that user
> > doesn't
> > > already have admin privileges, the command will fail while if the
> > user
> > > does
> > > have those privileges, the command isn't needed. Then again, maybe
> I
> > > haven't
> > > found the magic incantation yet.
> > >
> > > -----Original Message-----
> > > From: Markus Karg [mailto:[hidden email]]
> > > Sent: Monday, November 02, 2009 11:01 AM
> > > To: 'General discussion for Windows Installer XML toolset.'
> > > Subject: [WiX-users] Per User / Per Machine
> > >
> > > Blair,
> > >
> > > in a different context you wrote:
> > >
> > > > It is best to make your installations pure-perMachine or pure-
> > > > perUser
> > > > and never mix them
> > >
> > > There is one thing I do not understand in that context: I always
> had
> > > the
> > > impression that it is up to the *administrator* to decide whether
> to
> > > install
> > > a software Per User / Per Machine: Isn't that what msiexec's /ju
> and
> > > /jm
> > > options are good for?
> > >
> > > Now reading your above comment (and the MSDN chapter about the
> > ALLUSERS
> > > property) I am a bit confused.
> > >
> > > If it is up to the .msi *author* to decide about Per User / Per
> > Machine
> > > (using the ALLUSERS property), for what is /ju and /jm good then?
> And
> > > what
> > > will happen if my .msi file is for Per User, but the administrator
> is
> > > using
> > > /jm (or vice versa)?
> > >
> > > Thanks
> > > Markus
> > >
> > >
> > > -------------------------------------------------------------------
> --
> > --
> > > -----
> > > --
> > > Come build with us! The BlackBerry(R) Developer Conference in SF,
> CA
> > > is the only developer event you need to attend this year. Jumpstart
> > > your
> > > developing skills, take BlackBerry mobile applications to market
> and
> > > stay
> > > ahead of the curve. Join us from November 9 - 12, 2009. Register
> now!
> > > http://p.sf.net/sfu/devconference
> > > _______________________________________________
> > > WiX-users mailing list
> > > [hidden email]
> > > https://lists.sourceforge.net/lists/listinfo/wix-users
> > >
> > >
> > > -------------------------------------------------------------------
> --
> > --
> > > -------
> > > Come build with us! The BlackBerry(R) Developer Conference in SF,
> CA
> > > is the only developer event you need to attend this year. Jumpstart
> > > your
> > > developing skills, take BlackBerry mobile applications to market
> and
> > > stay
> > > ahead of the curve. Join us from November 9 - 12, 2009. Register
> now!
> > > http://p.sf.net/sfu/devconference
> > > _______________________________________________
> > > WiX-users mailing list
> > > [hidden email]
> > > https://lists.sourceforge.net/lists/listinfo/wix-users
> >
> >
> > ---------------------------------------------------------------------
> --
> > -----
> > --
> > Come build with us! The BlackBerry(R) Developer Conference in SF, CA
> > is the only developer event you need to attend this year. Jumpstart
> > your
> > developing skills, take BlackBerry mobile applications to market and
> > stay
> > ahead of the curve. Join us from November 9 - 12, 2009. Register now!
> > http://p.sf.net/sfu/devconference
> > _______________________________________________
> > WiX-users mailing list
> > [hidden email]
> > https://lists.sourceforge.net/lists/listinfo/wix-users
> >
> >
> > ---------------------------------------------------------------------
> --
> > -------
> > Let Crystal Reports handle the reporting - Free Crystal Reports 2008
> > 30-Day
> > trial. Simplify your report design, integration and deployment - and
> > focus on
> > what you do best, core application coding. Discover what's new with
> > Crystal Reports now. http://p.sf.net/sfu/bobj-july
> > _______________________________________________
> > WiX-users mailing list
> > [hidden email]
> > https://lists.sourceforge.net/lists/listinfo/wix-users
>
>
> -----------------------------------------------------------------------
> -----
> --
> Let Crystal Reports handle the reporting - Free Crystal Reports 2008
> 30-Day
> trial. Simplify your report design, integration and deployment - and
> focus
> on
> what you do best, core application coding. Discover what's new with
> Crystal Reports now. http://p.sf.net/sfu/bobj-july
> _______________________________________________
> WiX-users mailing list
> [hidden email]
> https://lists.sourceforge.net/lists/listinfo/wix-users
>
>
> -----------------------------------------------------------------------
> -------
> Let Crystal Reports handle the reporting - Free Crystal Reports 2008
> 30-Day
> trial. Simplify your report design, integration and deployment - and
> focus on
> what you do best, core application coding. Discover what's new with
> Crystal Reports now. http://p.sf.net/sfu/bobj-july
> _______________________________________________
> WiX-users mailing list
> [hidden email]
> https://lists.sourceforge.net/lists/listinfo/wix-users

Wilson, Phil

Re: Per User / Per Machine

Reply Threaded

A couple of comments:

1. It's only since UAC that the per-machine/per-user difficulty has been around. It's not been there forever. MSIINSTALLPERUSER is the solution in MSI 5.0.
http://blogs.msdn.com/windows_installer_team/archive/2009/09/02/authoring-a-single-package-for-per-user-or-per-machine-installation-context-in-windows-7.aspx

2. It's hard to talk about per-user and per-machine without taking privilege into account. A lot of people seem to be under the impression that you don't need to be elevated to install a per-user MSI, and then author it to write to all kinds of restricted locations and wonder why they need admin privilege to install it. ALLUSERS=2 produces unexpected effects for non-elevated users where you get a per-user install when a per-system may have been assumed (some other user logs on and says "I can see the files are installed but there's no shortcut").

Phil Wilson

-----Original Message-----
From: Markus Karg [mailto:[hidden email]]
Sent: Thursday, November 05, 2009 11:53 AM
To: 'General discussion for Windows Installer XML toolset.'
Subject: Re: [WiX-users] Per User / Per Machine

Blair,

thank you very much for your detailed answer. :-)

So if I understand correctly, all I have to do is to set ALLUSERS to 1? Ok,
nice. :-)

But actually, after decades of seeing lots of installers asking the
administrator where the *he* wants the files get copied to, I do not
understand why it is up to *the .msi author* to decide about this...
(actually I do not see any sense in deciding this *per .msi file* at all, as
virtually all currently installed products are installed *per machine*
anyways since no Windows before Seven was able to do a pure per-user
install, and nobody ever seriously complained about that, and with a
decision *per .msi file* chaos is likely to come...: "Hey admin, why can I
execute all programs but not this one? Why can everybody but me execute this
program? And why did it work on Vista but on Seven it is just vanished from
my Start menu?"). For me as a MSI starter this reads like: "You can't do it
right. I will fail anyways." ;-)

Regards
Markus

------------------------------------------------------------------------------
Let Crystal Reports handle the reporting - Free Crystal Reports 2008 30-Day
trial. Simplify your report design, integration and deployment - and focus on
what you do best, core application coding. Discover what's new with
Crystal Reports now. http://p.sf.net/sfu/bobj-july
_______________________________________________
WiX-users mailing list
[hidden email]
https://lists.sourceforge.net/lists/listinfo/wix-users

*** Confidentiality Notice: This e-mail, including any associated or attached files, is intended solely for the individual or entity to which it is addressed. This e-mail is confidential and may well also be legally privileged. If you have received it in error, you are on notice of its status. Please notify the sender immediately by reply e-mail and then delete this message from your system. Please do not copy it or use it for any purposes, or disclose its contents to any other person. This email comes from a division of the Invensys Group, owned by Invensys plc, which is a company registered in England and Wales with its registered office at Portland House, Bressenden Place, London, SW1E 5BF (Registered number 166023). For a list of European legal entities within the Invensys Group, please go to http://www.invensys.com/legal/default.asp?top_nav_id=77&nav_id=80&prev_id=77. You may contact Invensys plc on +44 (0)20 7821 3848 or e-mail [hidden email]. This e-mail and any attachments thereto may be subject to the terms of any agreements between Invensys (and/or its subsidiaries and affiliates) and the recipient (and/or its subsidiaries and affiliates).

------------------------------------------------------------------------------
Let Crystal Reports handle the reporting - Free Crystal Reports 2008 30-Day
trial. Simplify your report design, integration and deployment - and focus on
what you do best, core application coding. Discover what's new with
Crystal Reports now. http://p.sf.net/sfu/bobj-july
_______________________________________________
WiX-users mailing list
[hidden email]
https://lists.sourceforge.net/lists/listinfo/wix-users

Markus KARG

Re: Per User / Per Machine

Reply Threaded

But as I just tried out, it is impossible to author a elevated perUSer
installation: InstallScope="perUser" actually does override a manually coded
InstallPrivileges="elevated" attribute! So is that a bug in WiX?

> -----Original Message-----
> From: Wilson, Phil [mailto:[hidden email]]
> Sent: Donnerstag, 5. November 2009 21:44
> To: General discussion for Windows Installer XML toolset.
> Subject: Re: [WiX-users] Per User / Per Machine
>
> A couple of comments:
>
> 1. It's only since UAC that the per-machine/per-user difficulty has
> been around. It's not been there forever. MSIINSTALLPERUSER is the
> solution in MSI 5.0.
> http://blogs.msdn.com/windows_installer_team/archive/2009/09/02/authori
> ng-a-single-package-for-per-user-or-per-machine-installation-context-
> in-windows-7.aspx
>
> 2. It's hard to talk about per-user and per-machine without taking
> privilege into account. A lot of people seem to be under the impression
> that you don't need to be elevated to install a per-user MSI, and then
> author it to write to all kinds of restricted locations and wonder why
> they need admin privilege to install it. ALLUSERS=2 produces unexpected
> effects for non-elevated users where you get a per-user install when a
> per-system may have been assumed (some other user logs on and says "I
> can see the files are installed but there's no shortcut").
>
> Phil Wilson
>
> -----Original Message-----
> From: Markus Karg [mailto:[hidden email]]
> Sent: Thursday, November 05, 2009 11:53 AM
> To: 'General discussion for Windows Installer XML toolset.'
> Subject: Re: [WiX-users] Per User / Per Machine
>
> Blair,
>
> thank you very much for your detailed answer. :-)
>
> So if I understand correctly, all I have to do is to set ALLUSERS to 1?
> Ok,
> nice. :-)
>
> But actually, after decades of seeing lots of installers asking the
> administrator where the *he* wants the files get copied to, I do not
> understand why it is up to *the .msi author* to decide about this...
> (actually I do not see any sense in deciding this *per .msi file* at
> all, as
> virtually all currently installed products are installed *per machine*
> anyways since no Windows before Seven was able to do a pure per-user
> install, and nobody ever seriously complained about that, and with a
> decision *per .msi file* chaos is likely to come...: "Hey admin, why
> can I
> execute all programs but not this one? Why can everybody but me execute
> this
> program? And why did it work on Vista but on Seven it is just vanished
> from
> my Start menu?"). For me as a MSI starter this reads like: "You can't
> do it
> right. I will fail anyways." ;-)
>
> Regards
> Markus
>
> > -----Original Message-----
> > From: Blair [mailto:[hidden email]]
> > Sent: Donnerstag, 5. November 2009 12:57
> > To: 'General discussion for Windows Installer XML toolset.'
> > Subject: Re: [WiX-users] Per User / Per Machine
> >
> > Some items' ultimate locations depend on the ALLUSERS value. Some
> > examples:
> >
> > HKCR is really a merge of a key under HKLM and a different key under
> > HKCU.
> > If ALLUSERS is set to 1, you get the HKLM registration, otherwise
> (when
> > it
> > is blank) you get the HKCU one.
> >
> > The predefined property StartMenuFolder varies its value based on
> > ALLUSERS
> > as well. See the following table:
> > Type of Install REFKNOWNFOLDERID CSIDL
> > Per-machine CommonStartMenu CSIDL_COMMON_STARTMENU
> > Per-user StartMenu CSIDL_STARTMENU
> >
> > The portion of your authoring for items using those two values are
> > "easy"
> > since the actual authoring doesn't change. However, the location of
> the
> > binary that the verb and the shortcut point to need to be in a
> location
> > that
> > will be correctly identified, and that location should vary based on
> > what
> > value of ALLUSERS you are supporting (if you use ProgramFilesFolder,
> > for
> > instance, the location you get will be in a non-profile location that
> > requires elevation to access, that is, a per-machine location, so you
> > can't
> > really use it in a per-user package.)
> >
> > -----Original Message-----
> > From: Markus Karg [mailto:[hidden email]]
> > Sent: Wednesday, November 04, 2009 10:53 AM
> > To: 'General discussion for Windows Installer XML toolset.'
> > Subject: Re: [WiX-users] Per User / Per Machine
> >
> > But how to do that, "author the package based on your decision"?
> >
> > I mean, I just have two files, one program menu item and one
> extension
> > verb.
> > The .wxs file is more or less a copy of the WiX manual's samples /
> WiX
> > tutorial code snippets.
> >
> > The WiX manual does not say something about "authoring the packaging
> > based
> > on your decision", nor does the WiX tutorial.
> >
> > Is it enough to just set the ALLUSERS property, or how is that to be
> > done
> > "author the package based on your decision"?
> >
> > Sorry for one more silly questions, but I just can't find a How-To
> for
> > that.
> >
> > Thanks
> > Markus
> >
> > > -----Original Message-----
> > > From: Blair [mailto:[hidden email]]
> > > Sent: Mittwoch, 4. November 2009 06:47
> > > To: 'General discussion for Windows Installer XML toolset.'
> > > Subject: Re: [WiX-users] Per User / Per Machine
> > >
> > > Sorry if I am confusing you.
> > >
> > > I recommend you decide upfront if your installation will be per-
> user
> > or
> > > per-machine. Don't try to make a package that is intended to be
> > > switchable.
> > >
> > > Then author the package based on your decision.
> > >
> > > MSI 5 (Windows 7 or Windows Server 2008 R2) is required to make
> > > workable
> > > packages that can be switched during installation. However, the
> > advice
> > > is
> > > still: don't do it. Make it one or the other and prevent the one
> you
> > > don't
> > > support.
> > >
> > > -----Original Message-----
> > > From: Markus Karg [mailto:[hidden email]]
> > > Sent: Tuesday, November 03, 2009 9:28 AM
> > > To: 'General discussion for Windows Installer XML toolset.'
> > > Subject: Re: [WiX-users] Per User / Per Machine
> > >
> > > Blair,
> > >
> > > now I am more confused than before. On one hand you say, I shall
> > write
> > > a
> > > .msi that is either perUser OR perMachine, on the other hand you
> say
> > > that it
> > > is very hard to do when not using MSI 5 (which is only available on
> > > Windows
> > > 7). So for me this reads like: "For a MSI beginner it is impossible
> > to
> > > write
> > > a correctly working setup on any OS before W7.";-(
> > >
> > > Regards
> > > Markus
> > >
> > > > -----Original Message-----
> > > > From: Blair [mailto:[hidden email]]
> > > > Sent: Montag, 2. November 2009 21:43
> > > > To: 'General discussion for Windows Installer XML toolset.'
> > > > Subject: Re: [WiX-users] Per User / Per Machine
> > > >
> > > > All resources (files, registry entries, etc.) can generally be
> > > divided
> > > > into
> > > > three spaces: those that live in administrator per-machine areas
> > > > (C:\Program
> > > > Files, etc.), those that live in the user profile, and those very
> > few
> > > > that
> > > > live in shared document regions.
> > > >
> > > > If your installation requires access to administrator-controlled
> > > > regions of
> > > > the computer, it should be a pure perMachine and NOT place
> anything
> > > in
> > > > perUser (profile) areas, and vice-versa. Until MSI 5.0 (which is
> > > > currently
> > > > only available on Windows 7 AFAIK) it has been extremely
> difficult
> > to
> > > > author
> > > > a package that can go either way, although it was somewhat easier
> > > > before
> > > > Vista/UAC entered the picture.
> > > >
> > > > Administrators are supposed to follow author's guidelines when
> > using
> > > > advertising to make a program available to users. /ju and /jm
> don't
> > > > actually
> > > > install the software and they don't set ALLUSERS.
> > > >
> > > > Also, personally, I haven't found /ju to be very useful: it
> doesn't
> > > > provide
> > > > a place to designate the user to advertise to, and if that user
> > > doesn't
> > > > already have admin privileges, the command will fail while if the
> > > user
> > > > does
> > > > have those privileges, the command isn't needed. Then again,
> maybe
> > I
> > > > haven't
> > > > found the magic incantation yet.
> > > >
> > > > -----Original Message-----
> > > > From: Markus Karg [mailto:[hidden email]]
> > > > Sent: Monday, November 02, 2009 11:01 AM
> > > > To: 'General discussion for Windows Installer XML toolset.'
> > > > Subject: [WiX-users] Per User / Per Machine
> > > >
> > > > Blair,
> > > >
> > > > in a different context you wrote:
> > > >
> > > > > It is best to make your installations pure-perMachine or pure-
> > > > > perUser
> > > > > and never mix them
> > > >
> > > > There is one thing I do not understand in that context: I always
> > had
> > > > the
> > > > impression that it is up to the *administrator* to decide whether
> > to
> > > > install
> > > > a software Per User / Per Machine: Isn't that what msiexec's /ju
> > and
> > > > /jm
> > > > options are good for?
> > > >
> > > > Now reading your above comment (and the MSDN chapter about the
> > > ALLUSERS
> > > > property) I am a bit confused.
> > > >
> > > > If it is up to the .msi *author* to decide about Per User / Per
> > > Machine
> > > > (using the ALLUSERS property), for what is /ju and /jm good then?
> > And
> > > > what
> > > > will happen if my .msi file is for Per User, but the
> administrator
> > is
> > > > using
> > > > /jm (or vice versa)?
> > > >
> > > > Thanks
> > > > Markus
> > > >
> > > >
> > > > -----------------------------------------------------------------
> --
> > --
> > > --
> > > > -----
> > > > --
> > > > Come build with us! The BlackBerry(R) Developer Conference in SF,
> > CA
> > > > is the only developer event you need to attend this year.
> Jumpstart
> > > > your
> > > > developing skills, take BlackBerry mobile applications to market
> > and
> > > > stay
> > > > ahead of the curve. Join us from November 9 - 12, 2009. Register
> > now!
> > > > http://p.sf.net/sfu/devconference
> > > > _______________________________________________
> > > > WiX-users mailing list
> > > > [hidden email]
> > > > https://lists.sourceforge.net/lists/listinfo/wix-users
> > > >
> > > >
> > > > -----------------------------------------------------------------
> --
> > --
> > > --
> > > > -------
> > > > Come build with us! The BlackBerry(R) Developer Conference in SF,
> > CA
> > > > is the only developer event you need to attend this year.
> Jumpstart
> > > > your
> > > > developing skills, take BlackBerry mobile applications to market
> > and
> > > > stay
> > > > ahead of the curve. Join us from November 9 - 12, 2009. Register
> > now!
> > > > http://p.sf.net/sfu/devconference
> > > > _______________________________________________
> > > > WiX-users mailing list
> > > > [hidden email]
> > > > https://lists.sourceforge.net/lists/listinfo/wix-users
> > >
> > >
> > > -------------------------------------------------------------------
> --
> > --
> > > -----
> > > --
> > > Come build with us! The BlackBerry(R) Developer Conference in SF,
> CA
> > > is the only developer event you need to attend this year. Jumpstart
> > > your
> > > developing skills, take BlackBerry mobile applications to market
> and
> > > stay
> > > ahead of the curve. Join us from November 9 - 12, 2009. Register
> now!
> > > http://p.sf.net/sfu/devconference
> > > _______________________________________________
> > > WiX-users mailing list
> > > [hidden email]
> > > https://lists.sourceforge.net/lists/listinfo/wix-users
> > >
> > >
> > > -------------------------------------------------------------------
> --
> > --
> > > -------
> > > Let Crystal Reports handle the reporting - Free Crystal Reports
> 2008
> > > 30-Day
> > > trial. Simplify your report design, integration and deployment -
> and
> > > focus on
> > > what you do best, core application coding. Discover what's new with
> > > Crystal Reports now. http://p.sf.net/sfu/bobj-july
> > > _______________________________________________
> > > WiX-users mailing list
> > > [hidden email]
> > > https://lists.sourceforge.net/lists/listinfo/wix-users
> >
> >
> > ---------------------------------------------------------------------
> --
> > -----
> > --
> > Let Crystal Reports handle the reporting - Free Crystal Reports 2008
> > 30-Day
> > trial. Simplify your report design, integration and deployment - and
> > focus
> > on
> > what you do best, core application coding. Discover what's new with
> > Crystal Reports now. http://p.sf.net/sfu/bobj-july
> > _______________________________________________
> > WiX-users mailing list
> > [hidden email]
> > https://lists.sourceforge.net/lists/listinfo/wix-users
> >
> >
> > ---------------------------------------------------------------------
> --
> > -------
> > Let Crystal Reports handle the reporting - Free Crystal Reports 2008
> > 30-Day
> > trial. Simplify your report design, integration and deployment - and
> > focus on
> > what you do best, core application coding. Discover what's new with
> > Crystal Reports now. http://p.sf.net/sfu/bobj-july
> > _______________________________________________
> > WiX-users mailing list
> > [hidden email]
> > https://lists.sourceforge.net/lists/listinfo/wix-users
>
>
> -----------------------------------------------------------------------
> -------
> Let Crystal Reports handle the reporting - Free Crystal Reports 2008
> 30-Day
> trial. Simplify your report design, integration and deployment - and
> focus on
> what you do best, core application coding. Discover what's new with
> Crystal Reports now. http://p.sf.net/sfu/bobj-july
> _______________________________________________
> WiX-users mailing list
> [hidden email]
> https://lists.sourceforge.net/lists/listinfo/wix-users
>
>
>
> *** Confidentiality Notice: This e-mail, including any associated or
> attached files, is intended solely for the individual or entity to
> which it is addressed. This e-mail is confidential and may well also be
> legally privileged. If you have received it in error, you are on notice
> of its status. Please notify the sender immediately by reply e-mail and
> then delete this message from your system. Please do not copy it or use
> it for any purposes, or disclose its contents to any other person. This
> email comes from a division of the Invensys Group, owned by Invensys
> plc, which is a company registered in England and Wales with its
> registered office at Portland House, Bressenden Place, London, SW1E 5BF
> (Registered number 166023). For a list of European legal entities
> within the Invensys Group, please go to
> http://www.invensys.com/legal/default.asp?top_nav_id=77&nav_id=80&prev_
> id=77. You may contact Invensys plc on +44 (0)20 7821 3848 or e-mail
> [hidden email]. This e-mail and any attachments thereto
> may be subject to the terms of any agreements between Invensys (and/or
> its subsidiaries and affiliates) and the recipient (and/or its
> subsidiaries and affiliates).
>
>
>
> -----------------------------------------------------------------------
> -------
> Let Crystal Reports handle the reporting - Free Crystal Reports 2008
> 30-Day
> trial. Simplify your report design, integration and deployment - and
> focus on
> what you do best, core application coding. Discover what's new with
> Crystal Reports now. http://p.sf.net/sfu/bobj-july
> _______________________________________________
> WiX-users mailing list
> [hidden email]
> https://lists.sourceforge.net/lists/listinfo/wix-users

Wilson, Phil

Re: Per User / Per Machine

Reply Threaded

InstallPrivileges is to do with whether Windows can show the UAC prompt or not. InstallScope sets the ALLUSERS per machine/per user value. I'm not sure what you mean by one overriding the other. If you can author a true per-user install that you know doesn't require elevation then you do a per-user install and set InstallPrivileges to limited and it installs without a UAC prompt. I don't know why you can't author a per-user that elevates, unless you're referring to a non-admin user. You run it and it asks for a UAC prompt if you're an administrator, and that elevates it. If you're not an administrator, of course you can't take an MSI and have it run elevated. Elevation isn't in the package - it depends on the installing user's privileges. Other scenarios will produce the "over the shoulder" dialog where the administrator supplies credentials on behalf of the non-admin user.

Phil Wilson

-----Original Message-----
From: Markus Karg [mailto:[hidden email]]
Sent: Thursday, November 05, 2009 1:04 PM
To: 'General discussion for Windows Installer XML toolset.'
Subject: Re: [WiX-users] Per User / Per Machine

But as I just tried out, it is impossible to author a elevated perUSer
installation: InstallScope="perUser" actually does override a manually coded
InstallPrivileges="elevated" attribute! So is that a bug in WiX?

Markus KARG

Re: Per User / Per Machine

Reply Threaded

> -----Original Message-----
> From: Wilson, Phil [mailto:[hidden email]]
> Sent: Donnerstag, 5. November 2009 23:33
> To: General discussion for Windows Installer XML toolset.
> Subject: Re: [WiX-users] Per User / Per Machine
>
> InstallPrivileges is to do with whether Windows can show the UAC prompt
> or not. InstallScope sets the ALLUSERS per machine/per user value. I'm
> not sure what you mean by one overriding the other.

With "overriding" I mean: InstallScope="perUser"
InstallPriviliges="elevated". That does not work. InstallScope="perUser"
will ignore the valued of "elevated" and replace it by "limited".

Why do I want to do that? Because I want to have one .msi that each user can
run. Only the user that has it run, will have the shortcuts (per User) it
creates (this only works with "perUser"). But the program files will get
shared in %ProgramFiles% (this only works with "perMachine").

See my dilemma?

Thanks
Markus

> If you can author a
> true per-user install that you know doesn't require elevation then you
> do a per-user install and set InstallPrivileges to limited and it
> installs without a UAC prompt. I don't know why you can't author a per-
> user that elevates, unless you're referring to a non-admin user. You
> run it and it asks for a UAC prompt if you're an administrator, and
> that elevates it. If you're not an administrator, of course you can't
> take an MSI and have it run elevated. Elevation isn't in the package -
> it depends on the installing user's privileges. Other scenarios will
> produce the "over the shoulder" dialog where the administrator supplies
> credentials on behalf of the non-admin user.
>
> Phil Wilson
>
>
> -----Original Message-----
> From: Markus Karg [mailto:[hidden email]]
> Sent: Thursday, November 05, 2009 1:04 PM
> To: 'General discussion for Windows Installer XML toolset.'
> Subject: Re: [WiX-users] Per User / Per Machine
>
> But as I just tried out, it is impossible to author a elevated perUSer
> installation: InstallScope="perUser" actually does override a manually
> coded
> InstallPrivileges="elevated" attribute! So is that a bug in WiX?
>
> > -----Original Message-----
> > From: Wilson, Phil [mailto:[hidden email]]
> > Sent: Donnerstag, 5. November 2009 21:44
> > To: General discussion for Windows Installer XML toolset.
> > Subject: Re: [WiX-users] Per User / Per Machine
> >
> > A couple of comments:
> >
> > 1. It's only since UAC that the per-machine/per-user difficulty has
> > been around. It's not been there forever. MSIINSTALLPERUSER is the
> > solution in MSI 5.0.
> >
> http://blogs.msdn.com/windows_installer_team/archive/2009/09/02/authori
> > ng-a-single-package-for-per-user-or-per-machine-installation-context-
> > in-windows-7.aspx
> >
> > 2. It's hard to talk about per-user and per-machine without taking
> > privilege into account. A lot of people seem to be under the
> impression
> > that you don't need to be elevated to install a per-user MSI, and
> then
> > author it to write to all kinds of restricted locations and wonder
> why
> > they need admin privilege to install it. ALLUSERS=2 produces
> unexpected
> > effects for non-elevated users where you get a per-user install when
> a
> > per-system may have been assumed (some other user logs on and says "I
> > can see the files are installed but there's no shortcut").
> >
> > Phil Wilson
> >
> > -----Original Message-----
> > From: Markus Karg [mailto:[hidden email]]
> > Sent: Thursday, November 05, 2009 11:53 AM
> > To: 'General discussion for Windows Installer XML toolset.'
> > Subject: Re: [WiX-users] Per User / Per Machine
> >
> > Blair,
> >
> > thank you very much for your detailed answer. :-)
> >
> > So if I understand correctly, all I have to do is to set ALLUSERS to
> 1?
> > Ok,
> > nice. :-)
> >
> > But actually, after decades of seeing lots of installers asking the
> > administrator where the *he* wants the files get copied to, I do not
> > understand why it is up to *the .msi author* to decide about this...
> > (actually I do not see any sense in deciding this *per .msi file* at
> > all, as
> > virtually all currently installed products are installed *per
> machine*
> > anyways since no Windows before Seven was able to do a pure per-user
> > install, and nobody ever seriously complained about that, and with a
> > decision *per .msi file* chaos is likely to come...: "Hey admin, why
> > can I
> > execute all programs but not this one? Why can everybody but me
> execute
> > this
> > program? And why did it work on Vista but on Seven it is just
> vanished
> > from
> > my Start menu?"). For me as a MSI starter this reads like: "You can't
> > do it
> > right. I will fail anyways." ;-)
> >
> > Regards
> > Markus
> >
> > > -----Original Message-----
> > > From: Blair [mailto:[hidden email]]
> > > Sent: Donnerstag, 5. November 2009 12:57
> > > To: 'General discussion for Windows Installer XML toolset.'
> > > Subject: Re: [WiX-users] Per User / Per Machine
> > >
> > > Some items' ultimate locations depend on the ALLUSERS value. Some
> > > examples:
> > >
> > > HKCR is really a merge of a key under HKLM and a different key
> under
> > > HKCU.
> > > If ALLUSERS is set to 1, you get the HKLM registration, otherwise
> > (when
> > > it
> > > is blank) you get the HKCU one.
> > >
> > > The predefined property StartMenuFolder varies its value based on
> > > ALLUSERS
> > > as well. See the following table:
> > > Type of Install REFKNOWNFOLDERID CSIDL
> > > Per-machine CommonStartMenu CSIDL_COMMON_STARTMENU
> > > Per-user StartMenu CSIDL_STARTMENU
> > >
> > > The portion of your authoring for items using those two values are
> > > "easy"
> > > since the actual authoring doesn't change. However, the location of
> > the
> > > binary that the verb and the shortcut point to need to be in a
> > location
> > > that
> > > will be correctly identified, and that location should vary based
> on
> > > what
> > > value of ALLUSERS you are supporting (if you use
> ProgramFilesFolder,
> > > for
> > > instance, the location you get will be in a non-profile location
> that
> > > requires elevation to access, that is, a per-machine location, so
> you
> > > can't
> > > really use it in a per-user package.)
> > >
> > > -----Original Message-----
> > > From: Markus Karg [mailto:[hidden email]]
> > > Sent: Wednesday, November 04, 2009 10:53 AM
> > > To: 'General discussion for Windows Installer XML toolset.'
> > > Subject: Re: [WiX-users] Per User / Per Machine
> > >
> > > But how to do that, "author the package based on your decision"?
> > >
> > > I mean, I just have two files, one program menu item and one
> > extension
> > > verb.
> > > The .wxs file is more or less a copy of the WiX manual's samples /
> > WiX
> > > tutorial code snippets.
> > >
> > > The WiX manual does not say something about "authoring the
> packaging
> > > based
> > > on your decision", nor does the WiX tutorial.
> > >
> > > Is it enough to just set the ALLUSERS property, or how is that to
> be
> > > done
> > > "author the package based on your decision"?
> > >
> > > Sorry for one more silly questions, but I just can't find a How-To
> > for
> > > that.
> > >
> > > Thanks
> > > Markus
> > >
> > > > -----Original Message-----
> > > > From: Blair [mailto:[hidden email]]
> > > > Sent: Mittwoch, 4. November 2009 06:47
> > > > To: 'General discussion for Windows Installer XML toolset.'
> > > > Subject: Re: [WiX-users] Per User / Per Machine
> > > >
> > > > Sorry if I am confusing you.
> > > >
> > > > I recommend you decide upfront if your installation will be per-
> > user
> > > or
> > > > per-machine. Don't try to make a package that is intended to be
> > > > switchable.
> > > >
> > > > Then author the package based on your decision.
> > > >
> > > > MSI 5 (Windows 7 or Windows Server 2008 R2) is required to make
> > > > workable
> > > > packages that can be switched during installation. However, the
> > > advice
> > > > is
> > > > still: don't do it. Make it one or the other and prevent the one
> > you
> > > > don't
> > > > support.
> > > >
> > > > -----Original Message-----
> > > > From: Markus Karg [mailto:[hidden email]]
> > > > Sent: Tuesday, November 03, 2009 9:28 AM
> > > > To: 'General discussion for Windows Installer XML toolset.'
> > > > Subject: Re: [WiX-users] Per User / Per Machine
> > > >
> > > > Blair,
> > > >
> > > > now I am more confused than before. On one hand you say, I shall
> > > write
> > > > a
> > > > .msi that is either perUser OR perMachine, on the other hand you
> > say
> > > > that it
> > > > is very hard to do when not using MSI 5 (which is only available
> on
> > > > Windows
> > > > 7). So for me this reads like: "For a MSI beginner it is
> impossible
> > > to
> > > > write
> > > > a correctly working setup on any OS before W7.";-(
> > > >
> > > > Regards
> > > > Markus
> > > >
> > > > > -----Original Message-----
> > > > > From: Blair [mailto:[hidden email]]
> > > > > Sent: Montag, 2. November 2009 21:43
> > > > > To: 'General discussion for Windows Installer XML toolset.'
> > > > > Subject: Re: [WiX-users] Per User / Per Machine
> > > > >
> > > > > All resources (files, registry entries, etc.) can generally be
> > > > divided
> > > > > into
> > > > > three spaces: those that live in administrator per-machine
> areas
> > > > > (C:\Program
> > > > > Files, etc.), those that live in the user profile, and those
> very
> > > few
> > > > > that
> > > > > live in shared document regions.
> > > > >
> > > > > If your installation requires access to administrator-
> controlled
> > > > > regions of
> > > > > the computer, it should be a pure perMachine and NOT place
> > anything
> > > > in
> > > > > perUser (profile) areas, and vice-versa. Until MSI 5.0 (which
> is
> > > > > currently
> > > > > only available on Windows 7 AFAIK) it has been extremely
> > difficult
> > > to
> > > > > author
> > > > > a package that can go either way, although it was somewhat
> easier
> > > > > before
> > > > > Vista/UAC entered the picture.
> > > > >
> > > > > Administrators are supposed to follow author's guidelines when
> > > using
> > > > > advertising to make a program available to users. /ju and /jm
> > don't
> > > > > actually
> > > > > install the software and they don't set ALLUSERS.
> > > > >
> > > > > Also, personally, I haven't found /ju to be very useful: it
> > doesn't
> > > > > provide
> > > > > a place to designate the user to advertise to, and if that user
> > > > doesn't
> > > > > already have admin privileges, the command will fail while if
> the
> > > > user
> > > > > does
> > > > > have those privileges, the command isn't needed. Then again,
> > maybe
> > > I
> > > > > haven't
> > > > > found the magic incantation yet.
> > > > >
> > > > > -----Original Message-----
> > > > > From: Markus Karg [mailto:[hidden email]]
> > > > > Sent: Monday, November 02, 2009 11:01 AM
> > > > > To: 'General discussion for Windows Installer XML toolset.'
> > > > > Subject: [WiX-users] Per User / Per Machine
> > > > >
> > > > > Blair,
> > > > >
> > > > > in a different context you wrote:
> > > > >
> > > > > > It is best to make your installations pure-perMachine or
> pure-
> > > > > > perUser
> > > > > > and never mix them
> > > > >
> > > > > There is one thing I do not understand in that context: I
> always
> > > had
> > > > > the
> > > > > impression that it is up to the *administrator* to decide
> whether
> > > to
> > > > > install
> > > > > a software Per User / Per Machine: Isn't that what msiexec's
> /ju
> > > and
> > > > > /jm
> > > > > options are good for?
> > > > >
> > > > > Now reading your above comment (and the MSDN chapter about the
> > > > ALLUSERS
> > > > > property) I am a bit confused.
> > > > >
> > > > > If it is up to the .msi *author* to decide about Per User / Per
> > > > Machine
> > > > > (using the ALLUSERS property), for what is /ju and /jm good
> then?
> > > And
> > > > > what
> > > > > will happen if my .msi file is for Per User, but the
> > administrator
> > > is
> > > > > using
> > > > > /jm (or vice versa)?
> > > > >
> > > > > Thanks
> > > > > Markus
> > > > >
> > > > >
> > > > > ---------------------------------------------------------------
> --
> > --
> > > --
> > > > --
> > > > > -----
> > > > > --
> > > > > Come build with us! The BlackBerry(R) Developer Conference in
> SF,
> > > CA
> > > > > is the only developer event you need to attend this year.
> > Jumpstart
> > > > > your
> > > > > developing skills, take BlackBerry mobile applications to
> market
> > > and
> > > > > stay
> > > > > ahead of the curve. Join us from November 9 - 12, 2009.
> Register
> > > now!
> > > > > http://p.sf.net/sfu/devconference
> > > > > _______________________________________________
> > > > > WiX-users mailing list
> > > > > [hidden email]
> > > > > https://lists.sourceforge.net/lists/listinfo/wix-users
> > > > >
> > > > >
> > > > > ---------------------------------------------------------------
> --
> > --
> > > --
> > > > --
> > > > > -------
> > > > > Come build with us! The BlackBerry(R) Developer Conference in
> SF,
> > > CA
> > > > > is the only developer event you need to attend this year.
> > Jumpstart
> > > > > your
> > > > > developing skills, take BlackBerry mobile applications to
> market
> > > and
> > > > > stay
> > > > > ahead of the curve. Join us from November 9 - 12, 2009.
> Register
> > > now!
> > > > > http://p.sf.net/sfu/devconference
> > > > > _______________________________________________
> > > > > WiX-users mailing list
> > > > > [hidden email]
> > > > > https://lists.sourceforge.net/lists/listinfo/wix-users
> > > >
> > > >
> > > > -----------------------------------------------------------------
> --
> > --
> > > --
> > > > -----
> > > > --
> > > > Come build with us! The BlackBerry(R) Developer Conference in SF,
> > CA
> > > > is the only developer event you need to attend this year.
> Jumpstart
> > > > your
> > > > developing skills, take BlackBerry mobile applications to market
> > and
> > > > stay
> > > > ahead of the curve. Join us from November 9 - 12, 2009. Register
> > now!
> > > > http://p.sf.net/sfu/devconference
> > > > _______________________________________________
> > > > WiX-users mailing list
> > > > [hidden email]
> > > > https://lists.sourceforge.net/lists/listinfo/wix-users
> > > >
> > > >
> > > > -----------------------------------------------------------------
> --
> > --
> > > --
> > > > -------
> > > > Let Crystal Reports handle the reporting - Free Crystal Reports
> > 2008
> > > > 30-Day
> > > > trial. Simplify your report design, integration and deployment -
> > and
> > > > focus on
> > > > what you do best, core application coding. Discover what's new
> with
> > > > Crystal Reports now. http://p.sf.net/sfu/bobj-july
> > > > _______________________________________________
> > > > WiX-users mailing list
> > > > [hidden email]
> > > > https://lists.sourceforge.net/lists/listinfo/wix-users
> > >
> > >
> > > -------------------------------------------------------------------
> --
> > --
> > > -----
> > > --
> > > Let Crystal Reports handle the reporting - Free Crystal Reports
> 2008
> > > 30-Day
> > > trial. Simplify your report design, integration and deployment -
> and
> > > focus
> > > on
> > > what you do best, core application coding. Discover what's new with
> > > Crystal Reports now. http://p.sf.net/sfu/bobj-july
> > > _______________________________________________
> > > WiX-users mailing list
> > > [hidden email]
> > > https://lists.sourceforge.net/lists/listinfo/wix-users
> > >
> > >
> > > -------------------------------------------------------------------
> --
> > --
> > > -------
> > > Let Crystal Reports handle the reporting - Free Crystal Reports
> 2008
> > > 30-Day
> > > trial. Simplify your report design, integration and deployment -
> and
> > > focus on
> > > what you do best, core application coding. Discover what's new with
> > > Crystal Reports now. http://p.sf.net/sfu/bobj-july
> > > _______________________________________________
> > > WiX-users mailing list
> > > [hidden email]
> > > https://lists.sourceforge.net/lists/listinfo/wix-users
> >
> >
> > ---------------------------------------------------------------------
> --
> > -------
> > Let Crystal Reports handle the reporting - Free Crystal Reports 2008
> > 30-Day
> > trial. Simplify your report design, integration and deployment - and
> > focus on
> > what you do best, core application coding. Discover what's new with
> > Crystal Reports now. http://p.sf.net/sfu/bobj-july
> > _______________________________________________
> > WiX-users mailing list
> > [hidden email]
> > https://lists.sourceforge.net/lists/listinfo/wix-users
> >
> >
> >
> > *** Confidentiality Notice: This e-mail, including any associated or
> > attached files, is intended solely for the individual or entity to
> > which it is addressed. This e-mail is confidential and may well also
> be
> > legally privileged. If you have received it in error, you are on
> notice
> > of its status. Please notify the sender immediately by reply e-mail
> and
> > then delete this message from your system. Please do not copy it or
> use
> > it for any purposes, or disclose its contents to any other person.
> This
> > email comes from a division of the Invensys Group, owned by Invensys
> > plc, which is a company registered in England and Wales with its
> > registered office at Portland House, Bressenden Place, London, SW1E
> 5BF
> > (Registered number 166023). For a list of European legal entities
> > within the Invensys Group, please go to
> >
> http://www.invensys.com/legal/default.asp?top_nav_id=77&nav_id=80&prev_
> > id=77. You may contact Invensys plc on +44 (0)20 7821 3848 or e-mail
> > [hidden email]. This e-mail and any attachments thereto
> > may be subject to the terms of any agreements between Invensys
> (and/or
> > its subsidiaries and affiliates) and the recipient (and/or its
> > subsidiaries and affiliates).
> >
> >
> >
> > ---------------------------------------------------------------------
> --
> > -------
> > Let Crystal Reports handle the reporting - Free Crystal Reports 2008
> > 30-Day
> > trial. Simplify your report design, integration and deployment - and
> > focus on
> > what you do best, core application coding. Discover what's new with
> > Crystal Reports now. http://p.sf.net/sfu/bobj-july
> > _______________________________________________
> > WiX-users mailing list
> > [hidden email]
> > https://lists.sourceforge.net/lists/listinfo/wix-users
>
>
> -----------------------------------------------------------------------
> -------
> Let Crystal Reports handle the reporting - Free Crystal Reports 2008
> 30-Day
> trial. Simplify your report design, integration and deployment - and
> focus on
> what you do best, core application coding. Discover what's new with
> Crystal Reports now. http://p.sf.net/sfu/bobj-july
> _______________________________________________
> WiX-users mailing list
> [hidden email]
> https://lists.sourceforge.net/lists/listinfo/wix-users
>
>
>
> *** Confidentiality Notice: This e-mail, including any associated or
> attached files, is intended solely for the individual or entity to
> which it is addressed. This e-mail is confidential and may well also be
> legally privileged. If you have received it in error, you are on notice
> of its status. Please notify the sender immediately by reply e-mail and
> then delete this message from your system. Please do not copy it or use
> it for any purposes, or disclose its contents to any other person. This
> email comes from a division of the Invensys Group, owned by Invensys
> plc, which is a company registered in England and Wales with its
> registered office at Portland House, Bressenden Place, London, SW1E 5BF
> (Registered number 166023). For a list of European legal entities
> within the Invensys Group, please go to
> http://www.invensys.com/legal/default.asp?top_nav_id=77&nav_id=80&prev_
> id=77. You may contact Invensys plc on +44 (0)20 7821 3848 or e-mail
> [hidden email]. This e-mail and any attachments thereto
> may be subject to the terms of any agreements between Invensys (and/or
> its subsidiaries and affiliates) and the recipient (and/or its
> subsidiaries and affiliates).
>
>
>
> -----------------------------------------------------------------------
> -------
> Let Crystal Reports handle the reporting - Free Crystal Reports 2008
> 30-Day
> trial. Simplify your report design, integration and deployment - and
> focus on
> what you do best, core application coding. Discover what's new with
> Crystal Reports now. http://p.sf.net/sfu/bobj-july
> _______________________________________________
> WiX-users mailing list
> [hidden email]
> https://lists.sourceforge.net/lists/listinfo/wix-users

Blair-2

Re: Per User / Per Machine

Reply Threaded

If you want per-User packages that don't require elevation, you simply can't
use "C:\Program Files" (or similar locations) and you don't try writing
per-Machine packages or access any resources that require administrative
privileges during your transactions. You MUST then pick a spot under the
user's AppData folder where you will place your application files.

-----Original Message-----
From: Markus Karg [mailto:[hidden email]]
Sent: Friday, November 06, 2009 1:11 AM
To: 'General discussion for Windows Installer XML toolset.'
Subject: Re: [WiX-users] Per User / Per Machine

> -----Original Message-----
> From: Wilson, Phil [mailto:[hidden email]]
> Sent: Donnerstag, 5. November 2009 23:33
> To: General discussion for Windows Installer XML toolset.
> Subject: Re: [WiX-users] Per User / Per Machine
>
> InstallPrivileges is to do with whether Windows can show the UAC prompt
> or not. InstallScope sets the ALLUSERS per machine/per user value. I'm
> not sure what you mean by one overriding the other.

With "overriding" I mean: InstallScope="perUser"
InstallPriviliges="elevated". That does not work. InstallScope="perUser"
will ignore the valued of "elevated" and replace it by "limited".

Why do I want to do that? Because I want to have one .msi that each user can
run. Only the user that has it run, will have the shortcuts (per User) it
creates (this only works with "perUser"). But the program files will get
shared in %ProgramFiles% (this only works with "perMachine").

See my dilemma?

Thanks
Markus

Markus KARG

Re: Per User / Per Machine

Reply Threaded

Blair,

I did some experiments, and as it seems, "perMachine" actually is what I
want: It installs the software once (I don't need separate *software*), but
for each user, it does not install my extension verb unless the particular
user at least once started the software from the start menu (by
avertised="yes"). This is exactly what I want! No need for "perUser". :-)

"perUser" actually (I didn't understand that til today) targets in
separating *the software*, what I do not see any benefit in.

Thanks
Markus

> -----Original Message-----
> From: Blair [mailto:[hidden email]]
> Sent: Freitag, 6. November 2009 15:30
> To: 'General discussion for Windows Installer XML toolset.'
> Subject: Re: [WiX-users] Per User / Per Machine
>
> If you want per-User packages that don't require elevation, you simply
> can't
> use "C:\Program Files" (or similar locations) and you don't try writing
> per-Machine packages or access any resources that require
> administrative
> privileges during your transactions. You MUST then pick a spot under
> the
> user's AppData folder where you will place your application files.
>
> -----Original Message-----
> From: Markus Karg [mailto:[hidden email]]
> Sent: Friday, November 06, 2009 1:11 AM
> To: 'General discussion for Windows Installer XML toolset.'
> Subject: Re: [WiX-users] Per User / Per Machine
>
>
> > -----Original Message-----
> > From: Wilson, Phil [mailto:[hidden email]]
> > Sent: Donnerstag, 5. November 2009 23:33
> > To: General discussion for Windows Installer XML toolset.
> > Subject: Re: [WiX-users] Per User / Per Machine
> >
> > InstallPrivileges is to do with whether Windows can show the UAC
> prompt
> > or not. InstallScope sets the ALLUSERS per machine/per user value.
> I'm
> > not sure what you mean by one overriding the other.
>
> With "overriding" I mean: InstallScope="perUser"
> InstallPriviliges="elevated". That does not work.
> InstallScope="perUser"
> will ignore the valued of "elevated" and replace it by "limited".
>
> Why do I want to do that? Because I want to have one .msi that each
> user can
> run. Only the user that has it run, will have the shortcuts (per User)
> it
> creates (this only works with "perUser"). But the program files will
> get
> shared in %ProgramFiles% (this only works with "perMachine").
>
> See my dilemma?
>
> Thanks
> Markus
>
> > If you can author a
> > true per-user install that you know doesn't require elevation then
> you
> > do a per-user install and set InstallPrivileges to limited and it
> > installs without a UAC prompt. I don't know why you can't author a
> per-
> > user that elevates, unless you're referring to a non-admin user. You
> > run it and it asks for a UAC prompt if you're an administrator, and
> > that elevates it. If you're not an administrator, of course you can't
> > take an MSI and have it run elevated. Elevation isn't in the package
> -
> > it depends on the installing user's privileges. Other scenarios will
> > produce the "over the shoulder" dialog where the administrator
> supplies
> > credentials on behalf of the non-admin user.
> >
> > Phil Wilson
> >
> >
> > -----Original Message-----
> > From: Markus Karg [mailto:[hidden email]]
> > Sent: Thursday, November 05, 2009 1:04 PM
> > To: 'General discussion for Windows Installer XML toolset.'
> > Subject: Re: [WiX-users] Per User / Per Machine
> >
> > But as I just tried out, it is impossible to author a elevated
> perUSer
> > installation: InstallScope="perUser" actually does override a
> manually
> > coded
> > InstallPrivileges="elevated" attribute! So is that a bug in WiX?
> >
> > > -----Original Message-----
> > > From: Wilson, Phil [mailto:[hidden email]]
> > > Sent: Donnerstag, 5. November 2009 21:44
> > > To: General discussion for Windows Installer XML toolset.
> > > Subject: Re: [WiX-users] Per User / Per Machine
> > >
> > > A couple of comments:
> > >
> > > 1. It's only since UAC that the per-machine/per-user difficulty has
> > > been around. It's not been there forever. MSIINSTALLPERUSER is the
> > > solution in MSI 5.0.
> > >
> >
> http://blogs.msdn.com/windows_installer_team/archive/2009/09/02/authori
> > > ng-a-single-package-for-per-user-or-per-machine-installation-
> context-
> > > in-windows-7.aspx
> > >
> > > 2. It's hard to talk about per-user and per-machine without taking
> > > privilege into account. A lot of people seem to be under the
> > impression
> > > that you don't need to be elevated to install a per-user MSI, and
> > then
> > > author it to write to all kinds of restricted locations and wonder
> > why
> > > they need admin privilege to install it. ALLUSERS=2 produces
> > unexpected
> > > effects for non-elevated users where you get a per-user install
> when
> > a
> > > per-system may have been assumed (some other user logs on and says
> "I
> > > can see the files are installed but there's no shortcut").
> > >
> > > Phil Wilson
> > >
> > > -----Original Message-----
> > > From: Markus Karg [mailto:[hidden email]]
> > > Sent: Thursday, November 05, 2009 11:53 AM
> > > To: 'General discussion for Windows Installer XML toolset.'
> > > Subject: Re: [WiX-users] Per User / Per Machine
> > >
> > > Blair,
> > >
> > > thank you very much for your detailed answer. :-)
> > >
> > > So if I understand correctly, all I have to do is to set ALLUSERS
> to
> > 1?
> > > Ok,
> > > nice. :-)
> > >
> > > But actually, after decades of seeing lots of installers asking the
> > > administrator where the *he* wants the files get copied to, I do
> not
> > > understand why it is up to *the .msi author* to decide about
> this...
> > > (actually I do not see any sense in deciding this *per .msi file*
> at
> > > all, as
> > > virtually all currently installed products are installed *per
> > machine*
> > > anyways since no Windows before Seven was able to do a pure per-
> user
> > > install, and nobody ever seriously complained about that, and with
> a
> > > decision *per .msi file* chaos is likely to come...: "Hey admin,
> why
> > > can I
> > > execute all programs but not this one? Why can everybody but me
> > execute
> > > this
> > > program? And why did it work on Vista but on Seven it is just
> > vanished
> > > from
> > > my Start menu?"). For me as a MSI starter this reads like: "You
> can't
> > > do it
> > > right. I will fail anyways." ;-)
> > >
> > > Regards
> > > Markus
> > >
> > > > -----Original Message-----
> > > > From: Blair [mailto:[hidden email]]
> > > > Sent: Donnerstag, 5. November 2009 12:57
> > > > To: 'General discussion for Windows Installer XML toolset.'
> > > > Subject: Re: [WiX-users] Per User / Per Machine
> > > >
> > > > Some items' ultimate locations depend on the ALLUSERS value. Some
> > > > examples:
> > > >
> > > > HKCR is really a merge of a key under HKLM and a different key
> > under
> > > > HKCU.
> > > > If ALLUSERS is set to 1, you get the HKLM registration, otherwise
> > > (when
> > > > it
> > > > is blank) you get the HKCU one.
> > > >
> > > > The predefined property StartMenuFolder varies its value based on
> > > > ALLUSERS
> > > > as well. See the following table:
> > > > Type of Install REFKNOWNFOLDERID CSIDL
> > > > Per-machine CommonStartMenu CSIDL_COMMON_STARTMENU
> > > > Per-user StartMenu CSIDL_STARTMENU
> > > >
> > > > The portion of your authoring for items using those two values
> are
> > > > "easy"
> > > > since the actual authoring doesn't change. However, the location
> of
> > > the
> > > > binary that the verb and the shortcut point to need to be in a
> > > location
> > > > that
> > > > will be correctly identified, and that location should vary based
> > on
> > > > what
> > > > value of ALLUSERS you are supporting (if you use
> > ProgramFilesFolder,
> > > > for
> > > > instance, the location you get will be in a non-profile location
> > that
> > > > requires elevation to access, that is, a per-machine location, so
> > you
> > > > can't
> > > > really use it in a per-user package.)
> > > >
> > > > -----Original Message-----
> > > > From: Markus Karg [mailto:[hidden email]]
> > > > Sent: Wednesday, November 04, 2009 10:53 AM
> > > > To: 'General discussion for Windows Installer XML toolset.'
> > > > Subject: Re: [WiX-users] Per User / Per Machine
> > > >
> > > > But how to do that, "author the package based on your decision"?
> > > >
> > > > I mean, I just have two files, one program menu item and one
> > > extension
> > > > verb.
> > > > The .wxs file is more or less a copy of the WiX manual's samples
> /
> > > WiX
> > > > tutorial code snippets.
> > > >
> > > > The WiX manual does not say something about "authoring the
> > packaging
> > > > based
> > > > on your decision", nor does the WiX tutorial.
> > > >
> > > > Is it enough to just set the ALLUSERS property, or how is that to
> > be
> > > > done
> > > > "author the package based on your decision"?
> > > >
> > > > Sorry for one more silly questions, but I just can't find a How-
> To
> > > for
> > > > that.
> > > >
> > > > Thanks
> > > > Markus
> > > >
> > > > > -----Original Message-----
> > > > > From: Blair [mailto:[hidden email]]
> > > > > Sent: Mittwoch, 4. November 2009 06:47
> > > > > To: 'General discussion for Windows Installer XML toolset.'
> > > > > Subject: Re: [WiX-users] Per User / Per Machine
> > > > >
> > > > > Sorry if I am confusing you.
> > > > >
> > > > > I recommend you decide upfront if your installation will be
> per-
> > > user
> > > > or
> > > > > per-machine. Don't try to make a package that is intended to be
> > > > > switchable.
> > > > >
> > > > > Then author the package based on your decision.
> > > > >
> > > > > MSI 5 (Windows 7 or Windows Server 2008 R2) is required to make
> > > > > workable
> > > > > packages that can be switched during installation. However, the
> > > > advice
> > > > > is
> > > > > still: don't do it. Make it one or the other and prevent the
> one
> > > you
> > > > > don't
> > > > > support.
> > > > >
> > > > > -----Original Message-----
> > > > > From: Markus Karg [mailto:[hidden email]]
> > > > > Sent: Tuesday, November 03, 2009 9:28 AM
> > > > > To: 'General discussion for Windows Installer XML toolset.'
> > > > > Subject: Re: [WiX-users] Per User / Per Machine
> > > > >
> > > > > Blair,
> > > > >
> > > > > now I am more confused than before. On one hand you say, I
> shall
> > > > write
> > > > > a
> > > > > .msi that is either perUser OR perMachine, on the other hand
> you
> > > say
> > > > > that it
> > > > > is very hard to do when not using MSI 5 (which is only
> available
> > on
> > > > > Windows
> > > > > 7). So for me this reads like: "For a MSI beginner it is
> > impossible
> > > > to
> > > > > write
> > > > > a correctly working setup on any OS before W7.";-(
> > > > >
> > > > > Regards
> > > > > Markus
> > > > >
> > > > > > -----Original Message-----
> > > > > > From: Blair [mailto:[hidden email]]
> > > > > > Sent: Montag, 2. November 2009 21:43
> > > > > > To: 'General discussion for Windows Installer XML toolset.'
> > > > > > Subject: Re: [WiX-users] Per User / Per Machine
> > > > > >
> > > > > > All resources (files, registry entries, etc.) can generally
> be
> > > > > divided
> > > > > > into
> > > > > > three spaces: those that live in administrator per-machine
> > areas
> > > > > > (C:\Program
> > > > > > Files, etc.), those that live in the user profile, and those
> > very
> > > > few
> > > > > > that
> > > > > > live in shared document regions.
> > > > > >
> > > > > > If your installation requires access to administrator-
> > controlled
> > > > > > regions of
> > > > > > the computer, it should be a pure perMachine and NOT place
> > > anything
> > > > > in
> > > > > > perUser (profile) areas, and vice-versa. Until MSI 5.0 (which
> > is
> > > > > > currently
> > > > > > only available on Windows 7 AFAIK) it has been extremely
> > > difficult
> > > > to
> > > > > > author
> > > > > > a package that can go either way, although it was somewhat
> > easier
> > > > > > before
> > > > > > Vista/UAC entered the picture.
> > > > > >
> > > > > > Administrators are supposed to follow author's guidelines
> when
> > > > using
> > > > > > advertising to make a program available to users. /ju and /jm
> > > don't
> > > > > > actually
> > > > > > install the software and they don't set ALLUSERS.
> > > > > >
> > > > > > Also, personally, I haven't found /ju to be very useful: it
> > > doesn't
> > > > > > provide
> > > > > > a place to designate the user to advertise to, and if that
> user
> > > > > doesn't
> > > > > > already have admin privileges, the command will fail while if
> > the
> > > > > user
> > > > > > does
> > > > > > have those privileges, the command isn't needed. Then again,
> > > maybe
> > > > I
> > > > > > haven't
> > > > > > found the magic incantation yet.
> > > > > >
> > > > > > -----Original Message-----
> > > > > > From: Markus Karg [mailto:[hidden email]]
> > > > > > Sent: Monday, November 02, 2009 11:01 AM
> > > > > > To: 'General discussion for Windows Installer XML toolset.'
> > > > > > Subject: [WiX-users] Per User / Per Machine
> > > > > >
> > > > > > Blair,
> > > > > >
> > > > > > in a different context you wrote:
> > > > > >
> > > > > > > It is best to make your installations pure-perMachine or
> > pure-
> > > > > > > perUser
> > > > > > > and never mix them
> > > > > >
> > > > > > There is one thing I do not understand in that context: I
> > always
> > > > had
> > > > > > the
> > > > > > impression that it is up to the *administrator* to decide
> > whether
> > > > to
> > > > > > install
> > > > > > a software Per User / Per Machine: Isn't that what msiexec's
> > /ju
> > > > and
> > > > > > /jm
> > > > > > options are good for?
> > > > > >
> > > > > > Now reading your above comment (and the MSDN chapter about
> the
> > > > > ALLUSERS
> > > > > > property) I am a bit confused.
> > > > > >
> > > > > > If it is up to the .msi *author* to decide about Per User /
> Per
> > > > > Machine
> > > > > > (using the ALLUSERS property), for what is /ju and /jm good
> > then?
> > > > And
> > > > > > what
> > > > > > will happen if my .msi file is for Per User, but the
> > > administrator
> > > > is
> > > > > > using
> > > > > > /jm (or vice versa)?
> > > > > >
> > > > > > Thanks
> > > > > > Markus
> > > > > >
> > > > > >
> > > > > > -------------------------------------------------------------
> --
> > --
> > > --
> > > > --
> > > > > --
> > > > > > -----
> > > > > > --
> > > > > > Come build with us! The BlackBerry(R) Developer Conference in
> > SF,
> > > > CA
> > > > > > is the only developer event you need to attend this year.
> > > Jumpstart
> > > > > > your
> > > > > > developing skills, take BlackBerry mobile applications to
> > market
> > > > and
> > > > > > stay
> > > > > > ahead of the curve. Join us from November 9 - 12, 2009.
> > Register
> > > > now!
> > > > > > http://p.sf.net/sfu/devconference
> > > > > > _______________________________________________
> > > > > > WiX-users mailing list
> > > > > > [hidden email]
> > > > > > https://lists.sourceforge.net/lists/listinfo/wix-users
> > > > > >
> > > > > >
> > > > > > -------------------------------------------------------------
> --
> > --
> > > --
> > > > --
> > > > > --
> > > > > > -------
> > > > > > Come build with us! The BlackBerry(R) Developer Conference in
> > SF,
> > > > CA
> > > > > > is the only developer event you need to attend this year.
> > > Jumpstart
> > > > > > your
> > > > > > developing skills, take BlackBerry mobile applications to
> > market
> > > > and
> > > > > > stay
> > > > > > ahead of the curve. Join us from November 9 - 12, 2009.
> > Register
> > > > now!
> > > > > > http://p.sf.net/sfu/devconference
> > > > > > _______________________________________________
> > > > > > WiX-users mailing list
> > > > > > [hidden email]
> > > > > > https://lists.sourceforge.net/lists/listinfo/wix-users
> > > > >
> > > > >
> > > > > ---------------------------------------------------------------
> --
> > --
> > > --
> > > > --
> > > > > -----
> > > > > --
> > > > > Come build with us! The BlackBerry(R) Developer Conference in
> SF,
> > > CA
> > > > > is the only developer event you need to attend this year.
> > Jumpstart
> > > > > your
> > > > > developing skills, take BlackBerry mobile applications to
> market
> > > and
> > > > > stay
> > > > > ahead of the curve. Join us from November 9 - 12, 2009.
> Register
> > > now!
> > > > > http://p.sf.net/sfu/devconference
> > > > > _______________________________________________
> > > > > WiX-users mailing list
> > > > > [hidden email]
> > > > > https://lists.sourceforge.net/lists/listinfo/wix-users
> > > > >
> > > > >
> > > > > ---------------------------------------------------------------
> --
> > --
> > > --
> > > > --
> > > > > -------
> > > > > Let Crystal Reports handle the reporting - Free Crystal Reports
> > > 2008
> > > > > 30-Day
> > > > > trial. Simplify your report design, integration and deployment
> -
> > > and
> > > > > focus on
> > > > > what you do best, core application coding. Discover what's new
> > with
> > > > > Crystal Reports now. http://p.sf.net/sfu/bobj-july
> > > > > _______________________________________________
> > > > > WiX-users mailing list
> > > > > [hidden email]
> > > > > https://lists.sourceforge.net/lists/listinfo/wix-users
> > > >
> > > >
> > > > -----------------------------------------------------------------
> --
> > --
> > > --
> > > > -----
> > > > --
> > > > Let Crystal Reports handle the reporting - Free Crystal Reports
> > 2008
> > > > 30-Day
> > > > trial. Simplify your report design, integration and deployment -
> > and
> > > > focus
> > > > on
> > > > what you do best, core application coding. Discover what's new
> with
> > > > Crystal Reports now. http://p.sf.net/sfu/bobj-july
> > > > _______________________________________________
> > > > WiX-users mailing list
> > > > [hidden email]
> > > > https://lists.sourceforge.net/lists/listinfo/wix-users
> > > >
> > > >
> > > > -----------------------------------------------------------------
> --
> > --
> > > --
> > > > -------
> > > > Let Crystal Reports handle the reporting - Free Crystal Reports
> > 2008
> > > > 30-Day
> > > > trial. Simplify your report design, integration and deployment -
> > and
> > > > focus on
> > > > what you do best, core application coding. Discover what's new
> with
> > > > Crystal Reports now. http://p.sf.net/sfu/bobj-july
> > > > _______________________________________________
> > > > WiX-users mailing list
> > > > [hidden email]
> > > > https://lists.sourceforge.net/lists/listinfo/wix-users
> > >
> > >
> > > -------------------------------------------------------------------
> --
> > --
> > > -------
> > > Let Crystal Reports handle the reporting - Free Crystal Reports
> 2008
> > > 30-Day
> > > trial. Simplify your report design, integration and deployment -
> and
> > > focus on
> > > what you do best, core application coding. Discover what's new with
> > > Crystal Reports now. http://p.sf.net/sfu/bobj-july
> > > _______________________________________________
> > > WiX-users mailing list
> > > [hidden email]
> > > https://lists.sourceforge.net/lists/listinfo/wix-users
> > >
> > >
> > >
> > > *** Confidentiality Notice: This e-mail, including any associated
> or
> > > attached files, is intended solely for the individual or entity to
> > > which it is addressed. This e-mail is confidential and may well
> also
> > be
> > > legally privileged. If you have received it in error, you are on
> > notice
> > > of its status. Please notify the sender immediately by reply e-mail
> > and
> > > then delete this message from your system. Please do not copy it or
> > use
> > > it for any purposes, or disclose its contents to any other person.
> > This
> > > email comes from a division of the Invensys Group, owned by
> Invensys
> > > plc, which is a company registered in England and Wales with its
> > > registered office at Portland House, Bressenden Place, London, SW1E
> > 5BF
> > > (Registered number 166023). For a list of European legal entities
> > > within the Invensys Group, please go to
> > >
> >
> http://www.invensys.com/legal/default.asp?top_nav_id=77&nav_id=80&prev_
> > > id=77. You may contact Invensys plc on +44 (0)20 7821 3848 or e-
> mail
> > > [hidden email]. This e-mail and any attachments
> thereto
> > > may be subject to the terms of any agreements between Invensys
> > (and/or
> > > its subsidiaries and affiliates) and the recipient (and/or its
> > > subsidiaries and affiliates).
> > >
> > >
> > >
> > > -------------------------------------------------------------------
> --
> > --
> > > -------
> > > Let Crystal Reports handle the reporting - Free Crystal Reports
> 2008
> > > 30-Day
> > > trial. Simplify your report design, integration and deployment -
> and
> > > focus on
> > > what you do best, core application coding. Discover what's new with
> > > Crystal Reports now. http://p.sf.net/sfu/bobj-july
> > > _______________________________________________
> > > WiX-users mailing list
> > > [hidden email]
> > > https://lists.sourceforge.net/lists/listinfo/wix-users
> >
> >
> > ---------------------------------------------------------------------
> --
> > -------
> > Let Crystal Reports handle the reporting - Free Crystal Reports 2008
> > 30-Day
> > trial. Simplify your report design, integration and deployment - and
> > focus on
> > what you do best, core application coding. Discover what's new with
> > Crystal Reports now. http://p.sf.net/sfu/bobj-july
> > _______________________________________________
> > WiX-users mailing list
> > [hidden email]
> > https://lists.sourceforge.net/lists/listinfo/wix-users
> >
> >
> >
> > *** Confidentiality Notice: This e-mail, including any associated or
> > attached files, is intended solely for the individual or entity to
> > which it is addressed. This e-mail is confidential and may well also
> be
> > legally privileged. If you have received it in error, you are on
> notice
> > of its status. Please notify the sender immediately by reply e-mail
> and
> > then delete this message from your system. Please do not copy it or
> use
> > it for any purposes, or disclose its contents to any other person.
> This
> > email comes from a division of the Invensys Group, owned by Invensys
> > plc, which is a company registered in England and Wales with its
> > registered office at Portland House, Bressenden Place, London, SW1E
> 5BF
> > (Registered number 166023). For a list of European legal entities
> > within the Invensys Group, please go to
> >
> http://www.invensys.com/legal/default.asp?top_nav_id=77&nav_id=80&prev_
> > id=77. You may contact Invensys plc on +44 (0)20 7821 3848 or e-mail
> > [hidden email]. This e-mail and any attachments thereto
> > may be subject to the terms of any agreements between Invensys
> (and/or
> > its subsidiaries and affiliates) and the recipient (and/or its
> > subsidiaries and affiliates).
> >
> >
> >
> > ---------------------------------------------------------------------
> --
> > -------
> > Let Crystal Reports handle the reporting - Free Crystal Reports 2008
> > 30-Day
> > trial. Simplify your report design, integration and deployment - and
> > focus on
> > what you do best, core application coding. Discover what's new with
> > Crystal Reports now. http://p.sf.net/sfu/bobj-july
> > _______________________________________________
> > WiX-users mailing list
> > [hidden email]
> > https://lists.sourceforge.net/lists/listinfo/wix-users
>
>
> -----------------------------------------------------------------------
> -----
> --
> Let Crystal Reports handle the reporting - Free Crystal Reports 2008
> 30-Day
> trial. Simplify your report design, integration and deployment - and
> focus
> on
> what you do best, core application coding. Discover what's new with
> Crystal Reports now. http://p.sf.net/sfu/bobj-july
> _______________________________________________
> WiX-users mailing list
> [hidden email]
> https://lists.sourceforge.net/lists/listinfo/wix-users
>
>
> -----------------------------------------------------------------------
> -------
> Let Crystal Reports handle the reporting - Free Crystal Reports 2008
> 30-Day
> trial. Simplify your report design, integration and deployment - and
> focus on
> what you do best, core application coding. Discover what's new with
> Crystal Reports now. http://p.sf.net/sfu/bobj-july
> _______________________________________________
> WiX-users mailing list
> [hidden email]
> https://lists.sourceforge.net/lists/listinfo/wix-users