[WiX-users] Some STUPID Limitations in WiX

[Dong Fang Xie (Excell Data Corporation)]

I'm working on a small and simple installer using WiX toolset (the latest stable version 2.0.3719.0). To my surprise, it is really very very tough !! It almost drove me crazy. I really don't understand why there are so many stupid limitations:

LIMIT 1:
Since FileSearch, DirectorySearch, RegistrySearch are WiX elements, Why there is no ProcessSearch or TaskSearch ?! I need to know whether a specific process is running before installation/uninstallation.

LIMIT 2:
If all files in a msi package are from different small projects, I can build a module for each small project, and create a main wxs file to merge all modules. It should be a good idea, but how can I use the files from different modules ? There is no way for now. I must control all custom actions in the main wxs file, and some custom actions need a FileKey to a file in a module. I cannot distribute all cutom actions in different modules, if I do so, how can I control the InstallSequence ? Using stupid numbers?

LIMIT 3:
I defined a dialog which must be shown not only during installation but also during uninstallation. But how to make it shown during uninstallation ? the UILevel will be set to basic UI or no UI automatically by msiexec.exe. How can I beg Windows NOT do that for me? I can use command "msiexec /qf /x msifile", but how can I know my customer can do that each time they want to uninstall the msi file ? Is there any way I can define UILevel of uninstallation inside msi file ?

WiX is a very good toolset, but far from perfect ! I bet the developers of WiX toolset have never built a powerful installer for customers. I will never know the limit if I wasn't assigned the job to build a small and simple installer.

I noticed that there are some extensions in WiX 3.0, but it is still far from enough.

For LIMIT 1, I've built my own dll to detect running processes. But how to break LIMIT 2 and LIMIT 3 ? Can you guys give me some ideas ?

Thanks in advance

[Pierson Lee (Volt)]

Just FYI - The WiX toolset is used to help write custom MSI packages but still need to follow the underlying Windows Installer rules and guidelines. I don't think the issues that you are mentioning are "issues" that pertain only to WiX

-----Original Message-----
From: wix-users-***@lists.sourceforge.net [mailto:wix-users-***@lists.sourceforge.net] On Behalf Of Dong Fang Xie (Excell Data Corporation)
Sent: Tuesday, September 25, 2007 12:04 PM
To: wix-***@lists.sourceforge.net
Subject: [WiX-users] Some STUPID Limitations in WiX

I'm working on a small and simple installer using WiX toolset (the latest stable version 2.0.3719.0). To my surprise, it is really very very tough !! It almost drove me crazy. I really don't understand why there are so many stupid limitations:

LIMIT 1:
Since FileSearch, DirectorySearch, RegistrySearch are WiX elements, Why there is no ProcessSearch or TaskSearch ?! I need to know whether a specific process is running before installation/uninstallation.

LIMIT 2:
If all files in a msi package are from different small projects, I can build a module for each small project, and create a main wxs file to merge all modules. It should be a good idea, but how can I use the files from different modules ? There is no way for now. I must control all custom actions in the main wxs file, and some custom actions need a FileKey to a file in a module. I cannot distribute all cutom actions in different modules, if I do so, how can I control the InstallSequence ? Using stupid numbers?

LIMIT 3:
I defined a dialog which must be shown not only during installation but also during uninstallation. But how to make it shown during uninstallation ? the UILevel will be set to basic UI or no UI automatically by msiexec.exe. How can I beg Windows NOT do that for me? I can use command "msiexec /qf /x msifile", but how can I know my customer can do that each time they want to uninstall the msi file ? Is there any way I can define UILevel of uninstallation inside msi file ?

WiX is a very good toolset, but far from perfect ! I bet the developers of WiX toolset have never built a powerful installer for customers. I will never know the limit if I wasn't assigned the job to build a small and simple installer.

I noticed that there are some extensions in WiX 3.0, but it is still far from enough.

For LIMIT 1, I've built my own dll to detect running processes. But how to break LIMIT 2 and LIMIT 3 ? Can you guys give me some ideas ?

Thanks in advance


-------------------------------------------------------------------------
This SF.net email is sponsored by: Microsoft
Defy all challenges. Microsoft(R) Visual Studio 2005.
http://clk.atdmt.com/MRT/go/vse0120000070mrt/direct/01/

[Wilson, Phil]

1) Why do you care? Wix has support for Custom Actions that can close
apps, and Windows Installer has FilesInUse detection, so the issue is
about what you want to do if you knew that some process was running.

2) There's a merge module facility to get custom actions merged, the
ModuleInstallExecuteSequence table where you say you want your custom
actions after or before other actions, not stupid numbers. I don't know
exactly how WiX builds these, but I think it supports it.

3) You can do this, but as Pierson says it's a Windows Installer thing.
You'd typically add your own handler into Add/Remove Programs. However
again the interesting question is why you need an uninstall dialog? This
is one of those "I've designed something but it's really difficult to
do" times, where the design doesn't fit the framework.


Phil Wilson


-----Original Message-----
From: wix-users-***@lists.sourceforge.net
[mailto:wix-users-***@lists.sourceforge.net] On Behalf Of Pierson
Lee (Volt)
Sent: Tuesday, September 25, 2007 12:23 PM
To: Dong Fang Xie (Excell Data Corporation);
wix-***@lists.sourceforge.net
Subject: Re: [WiX-users] Some STUPID Limitations in WiX

Just FYI - The WiX toolset is used to help write custom MSI packages but
still need to follow the underlying Windows Installer rules and
guidelines. I don't think the issues that you are mentioning are
"issues" that pertain only to WiX

-----Original Message-----
From: wix-users-***@lists.sourceforge.net
[mailto:wix-users-***@lists.sourceforge.net] On Behalf Of Dong Fang
Xie (Excell Data Corporation)
Sent: Tuesday, September 25, 2007 12:04 PM
To: wix-***@lists.sourceforge.net
Subject: [WiX-users] Some STUPID Limitations in WiX

I'm working on a small and simple installer using WiX toolset (the
latest stable version 2.0.3719.0). To my surprise, it is really very
very tough !! It almost drove me crazy. I really don't understand why
there are so many stupid limitations:

LIMIT 1:
Since FileSearch, DirectorySearch, RegistrySearch are WiX elements, Why
there is no ProcessSearch or TaskSearch ?! I need to know whether a
specific process is running before installation/uninstallation.

LIMIT 2:
If all files in a msi package are from different small projects, I can
build a module for each small project, and create a main wxs file to
merge all modules. It should be a good idea, but how can I use the files
from different modules ? There is no way for now. I must control all
custom actions in the main wxs file, and some custom actions need a
FileKey to a file in a module. I cannot distribute all cutom actions in
different modules, if I do so, how can I control the InstallSequence ?
Using stupid numbers?

LIMIT 3:
I defined a dialog which must be shown not only during installation but
also during uninstallation. But how to make it shown during
uninstallation ? the UILevel will be set to basic UI or no UI
automatically by msiexec.exe. How can I beg Windows NOT do that for me?
I can use command "msiexec /qf /x msifile", but how can I know my
customer can do that each time they want to uninstall the msi file ? Is
there any way I can define UILevel of uninstallation inside msi file ?

WiX is a very good toolset, but far from perfect ! I bet the developers
of WiX toolset have never built a powerful installer for customers. I
will never know the limit if I wasn't assigned the job to build a small
and simple installer.

I noticed that there are some extensions in WiX 3.0, but it is still far
from enough.

For LIMIT 1, I've built my own dll to detect running processes. But how
to break LIMIT 2 and LIMIT 3 ? Can you guys give me some ideas ?

Thanks in advance


------------------------------------------------------------------------
-
This SF.net email is sponsored by: Microsoft
Defy all challenges. Microsoft(R) Visual Studio 2005.
http://clk.atdmt.com/MRT/go/vse0120000070mrt/direct/01/
_______________________________________________
WiX-users mailing list
WiX-***@lists.sourceforge.net
https://lists.sourceforge.net/lists/listinfo/wix-users

------------------------------------------------------------------------
-
This SF.net email is sponsored by: Microsoft
Defy all challenges. Microsoft(R) Visual Studio 2005.
http://clk.atdmt.com/MRT/go/vse0120000070mrt/direct/01/

[Steve Maillet]

"I bet the developers of WiX toolset have never built a powerful
installer for customers."
You'd lose that bet! Microsoft Office 2007 installation is built with
WIX.

WIX is built on top of the Microsoft Installer so is "limited" in the
same way as the Windows Installer is. As you found you can create custom
actions to handle pretty much anything not already covered by the MSI
engine, but it takes care to get those write with regard to rollback and
un-install.

LIMIT 2:
Not sure what you are trying to say here. We've built up a number of
wixlibs from fragments with a bunch of files and actions etc.. you just
use a ComponentRef or CustomActionRef, etc... to pull in the elements of
the fragment you are interested in.

-----Original Message-----
From: wix-users-***@lists.sourceforge.net
[mailto:wix-users-***@lists.sourceforge.net] On Behalf Of Dong Fang
Xie (Excell Data Corporation)
Sent: Tuesday, September 25, 2007 3:04 PM
To: wix-***@lists.sourceforge.net
Subject: [WiX-users] Some STUPID Limitations in WiX

I'm working on a small and simple installer using WiX toolset (the
latest stable version 2.0.3719.0). To my surprise, it is really very
very tough !! It almost drove me crazy. I really don't understand why
there are so many stupid limitations:

LIMIT 1:
Since FileSearch, DirectorySearch, RegistrySearch are WiX elements, Why
there is no ProcessSearch or TaskSearch ?! I need to know whether a
specific process is running before installation/uninstallation.

LIMIT 2:
If all files in a msi package are from different small projects, I can
build a module for each small project, and create a main wxs file to
merge all modules. It should be a good idea, but how can I use the files
from different modules ? There is no way for now. I must control all
custom actions in the main wxs file, and some custom actions need a
FileKey to a file in a module. I cannot distribute all cutom actions in
different modules, if I do so, how can I control the InstallSequence ?
Using stupid numbers?

LIMIT 3:
I defined a dialog which must be shown not only during installation but
also during uninstallation. But how to make it shown during
uninstallation ? the UILevel will be set to basic UI or no UI
automatically by msiexec.exe. How can I beg Windows NOT do that for me?
I can use command "msiexec /qf /x msifile", but how can I know my
customer can do that each time they want to uninstall the msi file ? Is
there any way I can define UILevel of uninstallation inside msi file ?

WiX is a very good toolset, but far from perfect ! I bet the developers
of WiX toolset have never built a powerful installer for customers. I
will never know the limit if I wasn't assigned the job to build a small
and simple installer.

I noticed that there are some extensions in WiX 3.0, but it is still far
from enough.

For LIMIT 1, I've built my own dll to detect running processes. But how
to break LIMIT 2 and LIMIT 3 ? Can you guys give me some ideas ?

Thanks in advance


------------------------------------------------------------------------
-
This SF.net email is sponsored by: Microsoft
Defy all challenges. Microsoft(R) Visual Studio 2005.
http://clk.atdmt.com/MRT/go/vse0120000070mrt/direct/01/

[Justin Rockwood]

Hey, Dong, thanks for the laugh! :) While we appreciate feedback on the WiX
toolset, it's typically not a good idea to call it STUPID and then in the
same sentence ask for help. You're biting the hand that feeds you. Plus if
you think it's stupid then why would you trust the advice from the people
that created it? At any rate, good luck with your "powerful installer."
Since we don't really know how to build those (smile), you may want to take
any advice we give with a grain of salt.

Justin

-----Original Message-----
From: wix-users-***@lists.sourceforge.net
[mailto:wix-users-***@lists.sourceforge.net] On Behalf Of Dong Fang Xie
(Excell Data Corporation)
Sent: Tuesday, September 25, 2007 12:04 PM
To: wix-***@lists.sourceforge.net
Subject: [WiX-users] Some STUPID Limitations in WiX

I'm working on a small and simple installer using WiX toolset (the latest
stable version 2.0.3719.0). To my surprise, it is really very very tough !!
It almost drove me crazy. I really don't understand why there are so many
stupid limitations:

LIMIT 1:
Since FileSearch, DirectorySearch, RegistrySearch are WiX elements, Why
there is no ProcessSearch or TaskSearch ?! I need to know whether a
specific process is running before installation/uninstallation.

LIMIT 2:
If all files in a msi package are from different small projects, I can build
a module for each small project, and create a main wxs file to merge all
modules. It should be a good idea, but how can I use the files from
different modules ? There is no way for now. I must control all custom
actions in the main wxs file, and some custom actions need a FileKey to a
file in a module. I cannot distribute all cutom actions in different
modules, if I do so, how can I control the InstallSequence ? Using stupid
numbers?

LIMIT 3:
I defined a dialog which must be shown not only during installation but also
during uninstallation. But how to make it shown during uninstallation ? the
UILevel will be set to basic UI or no UI automatically by msiexec.exe. How
can I beg Windows NOT do that for me? I can use command "msiexec /qf /x
msifile", but how can I know my customer can do that each time they want to
uninstall the msi file ? Is there any way I can define UILevel of
uninstallation inside msi file ?

WiX is a very good toolset, but far from perfect ! I bet the developers of
WiX toolset have never built a powerful installer for customers. I will
never know the limit if I wasn't assigned the job to build a small and
simple installer.

I noticed that there are some extensions in WiX 3.0, but it is still far
from enough.

For LIMIT 1, I've built my own dll to detect running processes. But how to
break LIMIT 2 and LIMIT 3 ? Can you guys give me some ideas ?

Thanks in advance


-------------------------------------------------------------------------
This SF.net email is sponsored by: Microsoft
Defy all challenges. Microsoft(R) Visual Studio 2005.
http://clk.atdmt.com/MRT/go/vse0120000070mrt/direct/01/

[Dong Fang Xie (Excell Data Corporation)]

Justin,

Thank you for your advice. I'll improve my attitude towards WiX and Windows Installer.

BTW, you didn't answer my question. How to break those limitations ?

Thanks,
DongFang



-----Original Message-----
From: Justin Rockwood [mailto:***@cs.stanford.edu]
Sent: Tuesday, September 25, 2007 2:22 PM
To: Dong Fang Xie (Excell Data Corporation); wix-***@lists.sourceforge.net
Subject: RE: Some STUPID Limitations in WiX

Hey, Dong, thanks for the laugh! :) While we appreciate feedback on the WiX
toolset, it's typically not a good idea to call it STUPID and then in the
same sentence ask for help. You're biting the hand that feeds you. Plus if
you think it's stupid then why would you trust the advice from the people
that created it? At any rate, good luck with your "powerful installer."
Since we don't really know how to build those (smile), you may want to take
any advice we give with a grain of salt.

Justin

-----Original Message-----
From: wix-users-***@lists.sourceforge.net
[mailto:wix-users-***@lists.sourceforge.net] On Behalf Of Dong Fang Xie
(Excell Data Corporation)
Sent: Tuesday, September 25, 2007 12:04 PM
To: wix-***@lists.sourceforge.net
Subject: [WiX-users] Some STUPID Limitations in WiX

I'm working on a small and simple installer using WiX toolset (the latest
stable version 2.0.3719.0). To my surprise, it is really very very tough !!
It almost drove me crazy. I really don't understand why there are so many
stupid limitations:

LIMIT 1:
Since FileSearch, DirectorySearch, RegistrySearch are WiX elements, Why
there is no ProcessSearch or TaskSearch ?! I need to know whether a
specific process is running before installation/uninstallation.

LIMIT 2:
If all files in a msi package are from different small projects, I can build
a module for each small project, and create a main wxs file to merge all
modules. It should be a good idea, but how can I use the files from
different modules ? There is no way for now. I must control all custom
actions in the main wxs file, and some custom actions need a FileKey to a
file in a module. I cannot distribute all cutom actions in different
modules, if I do so, how can I control the InstallSequence ? Using stupid
numbers?

LIMIT 3:
I defined a dialog which must be shown not only during installation but also
during uninstallation. But how to make it shown during uninstallation ? the
UILevel will be set to basic UI or no UI automatically by msiexec.exe. How
can I beg Windows NOT do that for me? I can use command "msiexec /qf /x
msifile", but how can I know my customer can do that each time they want to
uninstall the msi file ? Is there any way I can define UILevel of
uninstallation inside msi file ?

WiX is a very good toolset, but far from perfect ! I bet the developers of
WiX toolset have never built a powerful installer for customers. I will
never know the limit if I wasn't assigned the job to build a small and
simple installer.

I noticed that there are some extensions in WiX 3.0, but it is still far
from enough.

For LIMIT 1, I've built my own dll to detect running processes. But how to
break LIMIT 2 and LIMIT 3 ? Can you guys give me some ideas ?

Thanks in advance

[Peter Marcu]

For #1. FileSearch, RegistrySearch, and DirectorySearch search are part of core Windows Installer functionality. This is why WiX has those contructs in the language and not the others.

For #2. Use libraries instead of modules. My advice is to produce modules only if you are shipping them for consumption in a setup you have no control over. They have additional limitations when you get into patching that make them hard to service. WiX supports msm's because Windows installer supports them but I would only recommend using them as a last resort :) Dont use them to share setup logic within your own system. Take advantage of the linker to separate things into smaller projects and pull it all together in the end.

-----Original Message-----
From: wix-users-***@lists.sourceforge.net [mailto:wix-users-***@lists.sourceforge.net] On Behalf Of Dong Fang Xie (Excell Data Corporation)
Sent: Tuesday, September 25, 2007 2:29 PM
To: Justin Rockwood; wix-***@lists.sourceforge.net
Subject: Re: [WiX-users] Some STUPID Limitations in WiX

Justin,

Thank you for your advice. I'll improve my attitude towards WiX and Windows Installer.

BTW, you didn't answer my question. How to break those limitations ?

Thanks,
DongFang



-----Original Message-----
From: Justin Rockwood [mailto:***@cs.stanford.edu]
Sent: Tuesday, September 25, 2007 2:22 PM
To: Dong Fang Xie (Excell Data Corporation); wix-***@lists.sourceforge.net
Subject: RE: Some STUPID Limitations in WiX

Hey, Dong, thanks for the laugh! :) While we appreciate feedback on the WiX
toolset, it's typically not a good idea to call it STUPID and then in the
same sentence ask for help. You're biting the hand that feeds you. Plus if
you think it's stupid then why would you trust the advice from the people
that created it? At any rate, good luck with your "powerful installer."
Since we don't really know how to build those (smile), you may want to take
any advice we give with a grain of salt.

Justin

-----Original Message-----
From: wix-users-***@lists.sourceforge.net
[mailto:wix-users-***@lists.sourceforge.net] On Behalf Of Dong Fang Xie
(Excell Data Corporation)
Sent: Tuesday, September 25, 2007 12:04 PM
To: wix-***@lists.sourceforge.net
Subject: [WiX-users] Some STUPID Limitations in WiX

I'm working on a small and simple installer using WiX toolset (the latest
stable version 2.0.3719.0). To my surprise, it is really very very tough !!
It almost drove me crazy. I really don't understand why there are so many
stupid limitations:

LIMIT 1:
Since FileSearch, DirectorySearch, RegistrySearch are WiX elements, Why
there is no ProcessSearch or TaskSearch ?! I need to know whether a
specific process is running before installation/uninstallation.

LIMIT 2:
If all files in a msi package are from different small projects, I can build
a module for each small project, and create a main wxs file to merge all
modules. It should be a good idea, but how can I use the files from
different modules ? There is no way for now. I must control all custom
actions in the main wxs file, and some custom actions need a FileKey to a
file in a module. I cannot distribute all cutom actions in different
modules, if I do so, how can I control the InstallSequence ? Using stupid
numbers?

LIMIT 3:
I defined a dialog which must be shown not only during installation but also
during uninstallation. But how to make it shown during uninstallation ? the
UILevel will be set to basic UI or no UI automatically by msiexec.exe. How
can I beg Windows NOT do that for me? I can use command "msiexec /qf /x
msifile", but how can I know my customer can do that each time they want to
uninstall the msi file ? Is there any way I can define UILevel of
uninstallation inside msi file ?

WiX is a very good toolset, but far from perfect ! I bet the developers of
WiX toolset have never built a powerful installer for customers. I will
never know the limit if I wasn't assigned the job to build a small and
simple installer.

I noticed that there are some extensions in WiX 3.0, but it is still far
from enough.

For LIMIT 1, I've built my own dll to detect running processes. But how to
break LIMIT 2 and LIMIT 3 ? Can you guys give me some ideas ?

Thanks in advance


-------------------------------------------------------------------------
This SF.net email is sponsored by: Microsoft
Defy all challenges. Microsoft(R) Visual Studio 2005.
http://clk.atdmt.com/MRT/go/vse0120000070mrt/direct/01/

[R***@quixotecorp.com]

DongFang,

Breaking the limitations you have observed is probably not possible in
WiX since WiX is just a mechanism for authoring files which are then
handled by Microsoft Installer. Unfortunately, if what you are
attempting to accomplish is not handled by Microsoft Installer itself
(and I would agree there are, IMHO some questionable oversights) then
WiX won't help make the solution easy. While WiX may be open source,
Microsoft installer is not, and so we are either left at the mercy of
Microsoft (who would need an appropriate business justification for any
such modifications) or find ourselves in the situation of writing lots
of custom actions (bearing in mind that we must do so *very carefully*
to avoid a fragile installation process).

Good luck with your installation challenges!

Regards,
Richard

-----Original Message-----
From: wix-users-***@lists.sourceforge.net
[mailto:wix-users-***@lists.sourceforge.net] On Behalf Of Dong Fang
Xie (Excell Data Corporation)
Sent: Tuesday, September 25, 2007 5:29 PM
To: Justin Rockwood; wix-***@lists.sourceforge.net
Subject: Re: [WiX-users] Some STUPID Limitations in WiX

Justin,

Thank you for your advice. I'll improve my attitude towards WiX and
Windows Installer.

BTW, you didn't answer my question. How to break those limitations ?

Thanks,
DongFang



* C O N F I D E N T I A L I T Y N O T I C E *
-----------------------------------------------------------
The content of this e-mail is intended solely for the use of the individual or entity to whom it is addressed. If you have received this communication in error, be aware that forwarding it, copying it, or in any way disclosing its content to any other person, is strictly prohibited. Quixote Traffic Corporation is neither liable for the contents, nor for the proper, complete and timely transmission of (the information contained in) this communication. If you have received this communication in error, please notify the author by replying to this e-mail immediately and delete the material from any computer.

[Aaron Shurts]

I have seen this time and time again. When someone doesn't understand the
subtle nuances of the Windows Installer service, all of a sudden all the
tools built around it suck or are "STUPID". :-)

Post by Justin Rockwood
Hey, Dong, thanks for the laugh! :) While we appreciate feedback on the WiX
toolset, it's typically not a good idea to call it STUPID and then in the
same sentence ask for help. You're biting the hand that feeds you. Plus if
you think it's stupid then why would you trust the advice from the people
that created it? At any rate, good luck with your "powerful installer."
Since we don't really know how to build those (smile), you may want to take
any advice we give with a grain of salt.
Justin
-----Original Message-----
(Excell Data Corporation)
Sent: Tuesday, September 25, 2007 12:04 PM
Subject: [WiX-users] Some STUPID Limitations in WiX
I'm working on a small and simple installer using WiX toolset (the latest
stable version 2.0.3719.0). To my surprise, it is really very very tough !!
It almost drove me crazy. I really don't understand why there are so many
Since FileSearch, DirectorySearch, RegistrySearch are WiX elements, Why
there is no ProcessSearch or TaskSearch ?! I need to know whether a
specific process is running before installation/uninstallation.
If all files in a msi package are from different small projects, I can build
a module for each small project, and create a main wxs file to merge all
modules. It should be a good idea, but how can I use the files from
different modules ? There is no way for now. I must control all custom
actions in the main wxs file, and some custom actions need a FileKey to a
file in a module. I cannot distribute all cutom actions in different
modules, if I do so, how can I control the InstallSequence ? Using stupid
numbers?
I defined a dialog which must be shown not only during installation but also
during uninstallation. But how to make it shown during uninstallation ? the
UILevel will be set to basic UI or no UI automatically by msiexec.exe
. How
can I beg Windows NOT do that for me? I can use command "msiexec /qf /x
msifile", but how can I know my customer can do that each time they want to
uninstall the msi file ? Is there any way I can define UILevel of
uninstallation inside msi file ?
WiX is a very good toolset, but far from perfect ! I bet the developers of
WiX toolset have never built a powerful installer for customers. I will
never know the limit if I wasn't assigned the job to build a small and
simple installer.
I noticed that there are some extensions in WiX 3.0, but it is still far from enough.
For LIMIT 1, I've built my own dll to detect running processes. But how to
break LIMIT 2 and LIMIT 3 ? Can you guys give me some ideas ?
Thanks in advance
-------------------------------------------------------------------------
This SF.net email is sponsored by: Microsoft
Defy all challenges. Microsoft(R) Visual Studio 2005.
http://clk.atdmt.com/MRT/go/vse0120000070mrt/direct/01/
_______________________________________________
WiX-users mailing list
https://lists.sourceforge.net/lists/listinfo/wix-users
-------------------------------------------------------------------------
This SF.net email is sponsored by: Microsoft
Defy all challenges. Microsoft(R) Visual Studio 2005.
http://clk.atdmt.com/MRT/go/vse0120000070mrt/direct/01/
_______________________________________________
WiX-users mailing list
https://lists.sourceforge.net/lists/listinfo/wix-users

[Justin Rockwood]

True. Although, there's a grain of truth in Dong's frustrations, which is
why I was just joking around in my initial response (I really did think
Dong's email was funny and didn't take offense). I do think that Windows
Installer could be a lot easier to understand and work with and I think that
we still have a good ways to go to make it easier in WiX for novice users
(not necessarily calling Dong a novice).



Justin



From: wix-users-***@lists.sourceforge.net
[mailto:wix-users-***@lists.sourceforge.net] On Behalf Of Aaron Shurts
Sent: Tuesday, September 25, 2007 2:44 PM
To: wix-***@lists.sourceforge.net
Subject: Re: [WiX-users] Some STUPID Limitations in WiX



I have seen this time and time again. When someone doesn't understand the
subtle nuances of the Windows Installer service, all of a sudden all the
tools built around it suck or are "STUPID". :-)

On 9/25/07, Justin Rockwood <***@cs.stanford.edu> wrote:

Hey, Dong, thanks for the laugh! :) While we appreciate feedback on the WiX
toolset, it's typically not a good idea to call it STUPID and then in the
same sentence ask for help. You're biting the hand that feeds you. Plus if
you think it's stupid then why would you trust the advice from the people
that created it? At any rate, good luck with your "powerful installer."
Since we don't really know how to build those (smile), you may want to take
any advice we give with a grain of salt.

Justin

-----Original Message-----
From: wix-users-***@lists.sourceforge.net
[mailto: <mailto:wix-users-***@lists.sourceforge.net>
wix-users-***@lists.sourceforge.net] On Behalf Of Dong Fang Xie
(Excell Data Corporation)
Sent: Tuesday, September 25, 2007 12:04 PM
To: wix-***@lists.sourceforge.net
Subject: [WiX-users] Some STUPID Limitations in WiX

I'm working on a small and simple installer using WiX toolset (the latest
stable version 2.0.3719.0). To my surprise, it is really very very tough !!
It almost drove me crazy. I really don't understand why there are so many
stupid limitations:

LIMIT 1:
Since FileSearch, DirectorySearch, RegistrySearch are WiX elements, Why
there is no ProcessSearch or TaskSearch ?! I need to know whether a
specific process is running before installation/uninstallation.

LIMIT 2:
If all files in a msi package are from different small projects, I can build
a module for each small project, and create a main wxs file to merge all
modules. It should be a good idea, but how can I use the files from
different modules ? There is no way for now. I must control all custom
actions in the main wxs file, and some custom actions need a FileKey to a
file in a module. I cannot distribute all cutom actions in different
modules, if I do so, how can I control the InstallSequence ? Using stupid
numbers?

LIMIT 3:
I defined a dialog which must be shown not only during installation but also

during uninstallation. But how to make it shown during uninstallation ? the
UILevel will be set to basic UI or no UI automatically by msiexec.exe. How
can I beg Windows NOT do that for me? I can use command "msiexec /qf /x
msifile", but how can I know my customer can do that each time they want to
uninstall the msi file ? Is there any way I can define UILevel of
uninstallation inside msi file ?

WiX is a very good toolset, but far from perfect ! I bet the developers of
WiX toolset have never built a powerful installer for customers. I will
never know the limit if I wasn't assigned the job to build a small and
simple installer.

I noticed that there are some extensions in WiX 3.0, but it is still far
from enough.

For LIMIT 1, I've built my own dll to detect running processes. But how to
break LIMIT 2 and LIMIT 3 ? Can you guys give me some ideas ?

Thanks in advance


-------------------------------------------------------------------------
This SF.net email is sponsored by: Microsoft
Defy all challenges. Microsoft(R) Visual Studio 2005.
http://clk.atdmt.com/MRT/go/vse0120000070mrt/direct/01/
_______________________________________________
WiX-users mailing list
WiX-***@lists.sourceforge.net
https://lists.sourceforge.net/lists/listinfo/wix-users


-------------------------------------------------------------------------
This SF.net email is sponsored by: Microsoft
Defy all challenges. Microsoft(R) Visual Studio 2005.
http://clk.atdmt.com/MRT/go/vse0120000070mrt/direct/01/

[Chris Mumford]

Hi Justin:

Even though your advice and comments to Dong are 100% correct I'm still
going easy on him. I've had many frustrating days with Windows
Installer/WiX. I would say that these are most surely issues with Windows
Installer's complexity and not WiX - however WiX's tendency to assume that
you are already a Windows Installer expert, and it's missing support for UI
(until recently) never helped matters.

Post by Justin Rockwood
Hey, Dong, thanks for the laugh! :) While we appreciate feedback on the WiX
toolset, it's typically not a good idea to call it STUPID and then in the
same sentence ask for help. You're biting the hand that feeds you. Plus if
you think it's stupid then why would you trust the advice from the people
that created it? At any rate, good luck with your "powerful installer."
Since we don't really know how to build those (smile), you may want to take
any advice we give with a grain of salt.
Justin
-----Original Message-----
(Excell Data Corporation)
Sent: Tuesday, September 25, 2007 12:04 PM
Subject: [WiX-users] Some STUPID Limitations in WiX
I'm working on a small and simple installer using WiX toolset (the latest
stable version 2.0.3719.0). To my surprise, it is really very very tough !!
It almost drove me crazy. I really don't understand why there are so many
Since FileSearch, DirectorySearch, RegistrySearch are WiX elements, Why
there is no ProcessSearch or TaskSearch ?! I need to know whether a
specific process is running before installation/uninstallation.
If all files in a msi package are from different small projects, I can build
a module for each small project, and create a main wxs file to merge all
modules. It should be a good idea, but how can I use the files from
different modules ? There is no way for now. I must control all custom
actions in the main wxs file, and some custom actions need a FileKey to a
file in a module. I cannot distribute all cutom actions in different
modules, if I do so, how can I control the InstallSequence ? Using stupid
numbers?
I defined a dialog which must be shown not only during installation but also
during uninstallation. But how to make it shown during uninstallation ? the
UILevel will be set to basic UI or no UI automatically by msiexec.exe
. How
can I beg Windows NOT do that for me? I can use command "msiexec /qf /x
msifile", but how can I know my customer can do that each time they want to
uninstall the msi file ? Is there any way I can define UILevel of
uninstallation inside msi file ?
WiX is a very good toolset, but far from perfect ! I bet the developers of
WiX toolset have never built a powerful installer for customers. I will
never know the limit if I wasn't assigned the job to build a small and
simple installer.
I noticed that there are some extensions in WiX 3.0, but it is still far from enough.
For LIMIT 1, I've built my own dll to detect running processes. But how to
break LIMIT 2 and LIMIT 3 ? Can you guys give me some ideas ?
Thanks in advance
-------------------------------------------------------------------------
This SF.net email is sponsored by: Microsoft
Defy all challenges. Microsoft(R) Visual Studio 2005.
http://clk.atdmt.com/MRT/go/vse0120000070mrt/direct/01/
_______________________________________________
WiX-users mailing list
https://lists.sourceforge.net/lists/listinfo/wix-users
-------------------------------------------------------------------------
This SF.net email is sponsored by: Microsoft
Defy all challenges. Microsoft(R) Visual Studio 2005.
http://clk.atdmt.com/MRT/go/vse0120000070mrt/direct/01/
_______________________________________________
WiX-users mailing list
https://lists.sourceforge.net/lists/listinfo/wix-users

[Justin Rockwood]

Yep, I agree (see my last email - we crossed responses). I wasn't intending
to come down on Dong. I was writing tongue-in-cheek, but I'm not sure if
that came across. I still get frustrated with Windows Installer/WiX, so I
know the feeling.



Thanks,

Justin



From: Chris Mumford [mailto:***@cmumford.com]
Sent: Tuesday, September 25, 2007 2:50 PM
To: Justin Rockwood
Cc: Dong Fang Xie (Excell Data Corporation); wix-***@lists.sourceforge.net
Subject: Re: [WiX-users] Some STUPID Limitations in WiX



Hi Justin:

Even though your advice and comments to Dong are 100% correct I'm still
going easy on him. I've had many frustrating days with Windows
Installer/WiX. I would say that these are most surely issues with Windows
Installer's complexity and not WiX - however WiX's tendency to assume that
you are already a Windows Installer expert, and it's missing support for UI
(until recently) never helped matters.

On 9/25/07, Justin Rockwood <***@cs.stanford.edu> wrote:

Hey, Dong, thanks for the laugh! :) While we appreciate feedback on the WiX
toolset, it's typically not a good idea to call it STUPID and then in the
same sentence ask for help. You're biting the hand that feeds you. Plus if
you think it's stupid then why would you trust the advice from the people
that created it? At any rate, good luck with your "powerful installer."
Since we don't really know how to build those (smile), you may want to take
any advice we give with a grain of salt.

Justin

-----Original Message-----
From: wix-users-***@lists.sourceforge.net
[mailto: <mailto:wix-users-***@lists.sourceforge.net>
wix-users-***@lists.sourceforge.net] On Behalf Of Dong Fang Xie
(Excell Data Corporation)
Sent: Tuesday, September 25, 2007 12:04 PM
To: wix-***@lists.sourceforge.net
Subject: [WiX-users] Some STUPID Limitations in WiX

I'm working on a small and simple installer using WiX toolset (the latest
stable version 2.0.3719.0). To my surprise, it is really very very tough !!
It almost drove me crazy. I really don't understand why there are so many
stupid limitations:

LIMIT 1:
Since FileSearch, DirectorySearch, RegistrySearch are WiX elements, Why
there is no ProcessSearch or TaskSearch ?! I need to know whether a
specific process is running before installation/uninstallation.

LIMIT 2:
If all files in a msi package are from different small projects, I can build
a module for each small project, and create a main wxs file to merge all
modules. It should be a good idea, but how can I use the files from
different modules ? There is no way for now. I must control all custom
actions in the main wxs file, and some custom actions need a FileKey to a
file in a module. I cannot distribute all cutom actions in different
modules, if I do so, how can I control the InstallSequence ? Using stupid
numbers?

LIMIT 3:
I defined a dialog which must be shown not only during installation but also

during uninstallation. But how to make it shown during uninstallation ? the
UILevel will be set to basic UI or no UI automatically by msiexec.exe. How
can I beg Windows NOT do that for me? I can use command "msiexec /qf /x
msifile", but how can I know my customer can do that each time they want to
uninstall the msi file ? Is there any way I can define UILevel of
uninstallation inside msi file ?

WiX is a very good toolset, but far from perfect ! I bet the developers of
WiX toolset have never built a powerful installer for customers. I will
never know the limit if I wasn't assigned the job to build a small and
simple installer.

I noticed that there are some extensions in WiX 3.0, but it is still far
from enough.

For LIMIT 1, I've built my own dll to detect running processes. But how to
break LIMIT 2 and LIMIT 3 ? Can you guys give me some ideas ?

Thanks in advance


-------------------------------------------------------------------------
This SF.net email is sponsored by: Microsoft
Defy all challenges. Microsoft(R) Visual Studio 2005.
http://clk.atdmt.com/MRT/go/vse0120000070mrt/direct/01/
_______________________________________________
WiX-users mailing list
WiX-***@lists.sourceforge.net
https://lists.sourceforge.net/lists/listinfo/wix-users


-------------------------------------------------------------------------
This SF.net email is sponsored by: Microsoft
Defy all challenges. Microsoft(R) Visual Studio 2005.
http://clk.atdmt.com/MRT/go/vse0120000070mrt/direct/01/

[Christopher Painter]

Dong-

I notice your Microsoft.com email address and as such I'm assuming you are a contractor working on a project for Microsoft. As such, I'm curious about a few things:

1) Do you have prior experience writing installs and deploying applications?

2) Do you have prior MSI experience?

3) If yes to either, using what tools?

4) Who made the decision to use WiX for your current installer?

5) Why was the choice made? ( Not Invented Here / Dogfood perhaps? Or maybe the product lead doesn't know anything about installers either so he figured he'd just go with whatever eveyone else is using. )

6) Do you agree with that choice?


As for your comments.... your are correct, WiX is far from feature complete and severly lags other tools IMHO based on12 years of writing installs. But, don't expect anyone here to admit that.

Problem #1 ... MSI doesn't support these things but I really wish it did. InstallShield / Wise / InstallAware / WiX shouldn't have to write their own custom `xxxLocator` patterns for obvious use cases like Process, Service, WebSite, XML XPath. When the vendors don't do it, developers shouldn't have to do it with CA's. This is a failure on Microsoft's part, not developers.

Problem #2 requires a lot of design thought into how to componentize / fragmentize products and then build them all together in various combinations to get the desired result. I have several years experience doing this with other toolsets and it's always fun.

Problem #3 is creating dialogchains with entry conditions that detect first install, maintenance and uninstall servicing and then linking your dialog into those dialog chains with the proper ControlEvent Conditions.



Justin Rockwood <***@cs.stanford.edu> wrote:
Hey, Dong, thanks for the laugh! :) While we appreciate feedback on the WiX
toolset, it's typically not a good idea to call it STUPID and then in the
same sentence ask for help. You're biting the hand that feeds you. Plus if
you think it's stupid then why would you trust the advice from the people
that created it? At any rate, good luck with your "powerful installer."
Since we don't really know how to build those (smile), you may want to take
any advice we give with a grain of salt.

Justin

-----Original Message-----
From: wix-users-***@lists.sourceforge.net
[mailto:wix-users-***@lists.sourceforge.net] On Behalf Of Dong Fang Xie
(Excell Data Corporation)
Sent: Tuesday, September 25, 2007 12:04 PM
To: wix-***@lists.sourceforge.net
Subject: [WiX-users] Some STUPID Limitations in WiX

I'm working on a small and simple installer using WiX toolset (the latest
stable version 2.0.3719.0). To my surprise, it is really very very tough !!
It almost drove me crazy. I really don't understand why there are so many
stupid limitations:

LIMIT 1:
Since FileSearch, DirectorySearch, RegistrySearch are WiX elements, Why
there is no ProcessSearch or TaskSearch ?! I need to know whether a
specific process is running before installation/uninstallation.

LIMIT 2:
If all files in a msi package are from different small projects, I can build
a module for each small project, and create a main wxs file to merge all
modules. It should be a good idea, but how can I use the files from
different modules ? There is no way for now. I must control all custom
actions in the main wxs file, and some custom actions need a FileKey to a
file in a module. I cannot distribute all cutom actions in different
modules, if I do so, how can I control the InstallSequence ? Using stupid
numbers?

LIMIT 3:
I defined a dialog which must be shown not only during installation but also
during uninstallation. But how to make it shown during uninstallation ? the
UILevel will be set to basic UI or no UI automatically by msiexec.exe. How
can I beg Windows NOT do that for me? I can use command "msiexec /qf /x
msifile", but how can I know my customer can do that each time they want to
uninstall the msi file ? Is there any way I can define UILevel of
uninstallation inside msi file ?

WiX is a very good toolset, but far from perfect ! I bet the developers of
WiX toolset have never built a powerful installer for customers. I will
never know the limit if I wasn't assigned the job to build a small and
simple installer.

I noticed that there are some extensions in WiX 3.0, but it is still far
from enough.

For LIMIT 1, I've built my own dll to detect running processes. But how to
break LIMIT 2 and LIMIT 3 ? Can you guys give me some ideas ?

Thanks in advance


-------------------------------------------------------------------------
This SF.net email is sponsored by: Microsoft
Defy all challenges. Microsoft(R) Visual Studio 2005.
http://clk.atdmt.com/MRT/go/vse0120000070mrt/direct/01/
_______________________________________________
WiX-users mailing list
WiX-***@lists.sourceforge.net
https://lists.sourceforge.net/lists/listinfo/wix-users


-------------------------------------------------------------------------
This SF.net email is sponsored by: Microsoft
Defy all challenges. Microsoft(R) Visual Studio 2005.
http://clk.atdmt.com/MRT/go/vse0120000070mrt/direct/01/
_______________________________________________
WiX-users mailing list
WiX-***@lists.sourceforge.net
https://lists.sourceforge.net/lists/listinfo/wix-users



---------------------------------
Got a little couch potato?
Check out fun summer activities for kids.

[Cristian Baiu]

Hello Peter,
Hello everybody,

Peter, you said:

"For #2. Use libraries instead of modules. My advice is to produce
modules only if you are shipping them for consumption in a setup you
have no control over. They have additional limitations when you get
into patching that make them hard to service. WiX supports msm's
because Windows installer supports them but I would only recommend
using them as a last resort :) Dont use them to share setup logic
within your own system. Take advantage of the linker to separate
things into smaller projects and pull it all together in the end."


Can you explain a little more what are the problems involving patches and MSMs ?
I am extremely worried because in our company we have more products
which share a big module. We decided to implement the installation the
shared part as an MSM created with WIX (which installs files, writes
registries, registers COM and permorms some extremly necessary custom
actions). These decision was made because the setups for our products
are done by different teams (not all of these teams using WIX), so we
didn't want to share this installation as library but rather MSM (we
decided one team creates the MSM and maintains it and other teams just
use it).
As I am part of the team which handles the MSM, I'm very woried to
hear that I will probably have problems to patch it, so I would like
to know what my problems could be in order to know how to avoid these
problems.

Many thanks.

[Peter Marcu]

If you need to get an msm from someone because they don't use WiX, that makes sense. If you're msi is the only one consuming those msm's you wont hit the major problem of servicing msm's which is, you don't know all of the various places it was consumed and therefore you don't know all the products to ship patches for.

If you are using WiX v3 and want to take advantage of the Patch building system, changes to msm's wont show up in your patches. I can give workarounds for that scenario if you have it so let me know. If you use patchwiz to generate you patches everything should work. The major benefit of the Patch system in WiX is the ability to filter only the changes you want into a patch. PatchWiz doesn't allow you to do this.

The only other major limitation is the one Dong pointed out which is that things in an MSM are not referencable from you WiX authoring. If you've broken things apart such that you don't need to reference stuff in the MSM then you should be ok here.

-----Original Message-----
From: wix-users-***@lists.sourceforge.net [mailto:wix-users-***@lists.sourceforge.net] On Behalf Of Cristian Baiu
Sent: Tuesday, September 25, 2007 11:20 PM
To: wix-***@lists.sourceforge.net
Subject: Re: [WiX-users] Some STUPID Limitations in WiX

Hello Peter,
Hello everybody,

Peter, you said:

"For #2. Use libraries instead of modules. My advice is to produce
modules only if you are shipping them for consumption in a setup you
have no control over. They have additional limitations when you get
into patching that make them hard to service. WiX supports msm's
because Windows installer supports them but I would only recommend
using them as a last resort :) Dont use them to share setup logic
within your own system. Take advantage of the linker to separate
things into smaller projects and pull it all together in the end."


Can you explain a little more what are the problems involving patches and MSMs ?
I am extremely worried because in our company we have more products
which share a big module. We decided to implement the installation the
shared part as an MSM created with WIX (which installs files, writes
registries, registers COM and permorms some extremly necessary custom
actions). These decision was made because the setups for our products
are done by different teams (not all of these teams using WIX), so we
didn't want to share this installation as library but rather MSM (we
decided one team creates the MSM and maintains it and other teams just
use it).
As I am part of the team which handles the MSM, I'm very woried to
hear that I will probably have problems to patch it, so I would like
to know what my problems could be in order to know how to avoid these
problems.

Many thanks.

-------------------------------------------------------------------------
This SF.net email is sponsored by: Microsoft
Defy all challenges. Microsoft(R) Visual Studio 2005.
http://clk.atdmt.com/MRT/go/vse0120000070mrt/direct/01/

[Cristian N. Baiu]

Hello Peter,

Actually the MSM is not intened to be delivered to unknown users. It
installs a component which is shared between company's products (it's a part
which ensures communication between all our company's products) So, must
probably we shall know the products to which we ship the patches. All
products must install it because some customers may buy two of the products,
others may buy other two product and so on. Unfortunatelly, as I said
before, not all these product which share the common component use WIX to
create their installers, so although I would like it, I cannot use the WIX
libraries.
My question regarding patching the msm is: if I create a patch for adressed
to only one of the products which patches a MSM component and the patch is
applied to a machine were two products containing the MSM's components are
installed then will the patch update the common component or not ?

Regarding the WIX patch building system I have tested for a while and I was
delighted with it (great work) - seemed to me much easier to use than the
patchwiz way and also the ability to filter what you need in the patch is
also great . Unfortunatelly I will not be able to use it as I need to take
advantage of patch optimization which is not yet supported with the WIX
system and from what I understand in your blog will not be available very
soon. I must deliver large Service Packs which I need to be as small as
possible so I need really bad the optimization.

Many thanks,
Cristian.

----- Original Message -----
From: "Peter Marcu" <***@microsoft.com>
To: "Cristian Baiu" <***@gmail.com>;
<wix-***@lists.sourceforge.net>
Sent: Wednesday, September 26, 2007 6:50 PM
Subject: RE: [WiX-users] Some STUPID Limitations in WiX


If you need to get an msm from someone because they don't use WiX, that
makes sense. If you're msi is the only one consuming those msm's you wont
hit the major problem of servicing msm's which is, you don't know all of the
various places it was consumed and therefore you don't know all the products
to ship patches for.

If you are using WiX v3 and want to take advantage of the Patch building
system, changes to msm's wont show up in your patches. I can give
workarounds for that scenario if you have it so let me know. If you use
patchwiz to generate you patches everything should work. The major benefit
of the Patch system in WiX is the ability to filter only the changes you
want into a patch. PatchWiz doesn't allow you to do this.

The only other major limitation is the one Dong pointed out which is that
things in an MSM are not referencable from you WiX authoring. If you've
broken things apart such that you don't need to reference stuff in the MSM
then you should be ok here.

-----Original Message-----
From: wix-users-***@lists.sourceforge.net
[mailto:wix-users-***@lists.sourceforge.net] On Behalf Of Cristian Baiu
Sent: Tuesday, September 25, 2007 11:20 PM
To: wix-***@lists.sourceforge.net
Subject: Re: [WiX-users] Some STUPID Limitations in WiX

Hello Peter,
Hello everybody,

Peter, you said:

"For #2. Use libraries instead of modules. My advice is to produce
modules only if you are shipping them for consumption in a setup you
have no control over. They have additional limitations when you get
into patching that make them hard to service. WiX supports msm's
because Windows installer supports them but I would only recommend
using them as a last resort :) Dont use them to share setup logic
within your own system. Take advantage of the linker to separate
things into smaller projects and pull it all together in the end."


Can you explain a little more what are the problems involving patches and
MSMs ?
I am extremely worried because in our company we have more products
which share a big module. We decided to implement the installation the
shared part as an MSM created with WIX (which installs files, writes
registries, registers COM and permorms some extremly necessary custom
actions). These decision was made because the setups for our products
are done by different teams (not all of these teams using WIX), so we
didn't want to share this installation as library but rather MSM (we
decided one team creates the MSM and maintains it and other teams just
use it).
As I am part of the team which handles the MSM, I'm very woried to
hear that I will probably have problems to patch it, so I would like
to know what my problems could be in order to know how to avoid these
problems.

Many thanks.

-------------------------------------------------------------------------
This SF.net email is sponsored by: Microsoft
Defy all challenges. Microsoft(R) Visual Studio 2005.
http://clk.atdmt.com/MRT/go/vse0120000070mrt/direct/01/

[Bob Arnson]

Post by Cristian N. Baiu
My question regarding patching the msm is: if I create a patch for adressed
to only one of the products which patches a MSM component and the patch is
applied to a machine were two products containing the MSM's components are
installed then will the patch update the common component or not ?

It will update the shared component but it won't update the other
product, so a repair operation can "undo" the patch. That's why merge
modules are falling way out of favor...

[DEÁK JAHN, Gábor]

On Wed, 26 Sep 2007 07:52:35 +1200, Steve Maillet wrote:

Steve,

Post by Steve Maillet
You'd lose that bet! Microsoft Office 2007 installation is built
with WIX.

It's not directly related to WiX but something rather strange happened to me the other day. On a computer where MS Office is not welcome, we had to install Outlook for three minutes, just for the time it takes for Thunderbird to pick up all previous correspondence and settings, then remove Outlook again for good. Granted, the computer was rather low on memory (128 MB, more has been added since but was unavailable at the time of the operation), so clearly not capable of running Office even if the owner wanted it, but we only wanted to install, not to use. Clearing every single checkbox but Outlook in a customized setup resulted in 45 minutes (not an exaggeration, measured) of installation. What's even stranger, uninstallation (removing about 10 MB worth of files) took the very same amount of time.

Bye,
G�bor

-------------------------------------------------------------------
DE�K JAHN, G�bor -- Budapest, Hungary
E-mail: ***@tramontana.co.hu

[Steve Maillet]

That seems a bit long, but if you measured it... Either way, as you say, it's not a WIX problem. The original post was betting that the creators of WIX (Microsoft employees mostly) had not used it to create complex installations. I was pointing out the error of that. Office-2007 is clearly a significant and complex install process. (Whether it *should* be that complex is an entirely different matter and not relevant to the context of the original thread).

Over the last 2 decades I've used just about everything available for setup and installation of software. Even at its current "unstable state" and lack of documentation Wix V3.0 beats them all hands down. The classic programmer model (compiler/linker, etc...) and Votive projects for support in VS for modularized projects alongside the application code is a simple and subtle difference from everything else. That subtle difference though brings benefits and advantages that simply cannot be dreamed of with other tools. Modularization and encapsulation etc... This allows developers to create installation wixlib libraries for their small pieces of a larger puzzle. It also allows unit testing of installs! Developers can create their wixlib and a separate MSI project to test it with to validate they got all the right pieces and parts installed correctly. But since the unit test MSI is actually installing the component in question it can also install a unit test application to test the component itself **AS it will be installed on the end user machine**. This is something that has a dramatic impact on the quality of code developed and released. (Probably not something that was on the design goals for WIX but a really great side benefit!)

-----Original Message-----
From: wix-users-***@lists.sourceforge.net [mailto:wix-users-***@lists.sourceforge.net] On Behalf Of DEÁK JAHN, Gábor
Sent: Monday, October 01, 2007 5:41 AM
To: WiX-users
Subject: [WiX-users] Some STUPID Limitations in WiX

On Wed, 26 Sep 2007 07:52:35 +1200, Steve Maillet wrote:

Steve,

Post by Steve Maillet
You'd lose that bet! Microsoft Office 2007 installation is built with
WIX.

It's not directly related to WiX but something rather strange happened to me the other day. On a computer where MS Office is not welcome, we had to install Outlook for three minutes, just for the time it takes for Thunderbird to pick up all previous correspondence and settings, then remove Outlook again for good. Granted, the computer was rather low on memory (128 MB, more has been added since but was unavailable at the time of the operation), so clearly not capable of running Office even if the owner wanted it, but we only wanted to install, not to use. Clearing every single checkbox but Outlook in a customized setup resulted in 45 minutes (not an exaggeration, measured) of installation. What's even stranger, uninstallation (removing about 10 MB worth of files) took the very same amount of time.

Bye,
Gábor

-------------------------------------------------------------------
DEÁK JAHN, Gábor -- Budapest, Hungary
E-mail: ***@tramontana.co.hu

[Roger Lipscombe]

Steve, would you care to explain some more about the following?

-----Original Message-----
It also allows unit testing of installs! Developers can create their
wixlib and a separate MSI project to test it with to validate they got
all the right pieces and parts installed correctly. But since the unit
test MSI is actually installing the component in question it can also
install a unit test application to test the component itself **AS it
will be installed on the end user machine**. This is something that has
a dramatic impact on the quality of code developed and released.
(Probably not something that was on the design goals for WIX but a
really great side benefit!)
--------------------------

I've only just started looking at WiX in anger, but this sounds awesome,
and I'm wondering if you felt able to write something about it, either
here or in a blog or something?

Cheers,
Roger.



-----------------------------------------
1E can save a company with 10,000 PCs over $165,000 and 1,381 tons of CO2 emissions per annum. Calculate what you can save with NightWatchman from 1E. Discover the benefits of System Center solutions for yourself - attend an exclusive 1E Enterprise Solutions Road Show. Visit our website at http://www.1e.com

DISCLAIMER: This is a PRIVATE message. If you are not the intended recipient, please delete without copying and kindly advise us by e-mail of the mistake in delivery. NOTE: Regardless of content, this e-mail shall not operate to bind 1E Ltd to any order or other contract unless pursuant to explicit written agreement or government initiative expressly permitting the use of e-mail for such purpose

[Steve Maillet]

Rats! I knew someone would ask that as soon as I clicked send! 8^)

It's something I discovered/realized we could do recently as we
transitioned our project into using WIX. (Which we did from frustration
with everything else and have been mostly pleased with the switch) I did
start to think about writing something up about it after clicking on
send as I realized it was something in the "radically different point of
view" category.

-----Original Message-----
From: wix-users-***@lists.sourceforge.net
[mailto:wix-users-***@lists.sourceforge.net] On Behalf Of Roger
Lipscombe
Sent: Monday, October 01, 2007 10:46 AM
To: WiX-users
Subject: Re: [WiX-users] Some STUPID Limitations in WiX

Steve, would you care to explain some more about the following?

-----Original Message-----
It also allows unit testing of installs! Developers can create their
wixlib and a separate MSI project to test it with to validate they got
all the right pieces and parts installed correctly. But since the unit
test MSI is actually installing the component in question it can also
install a unit test application to test the component itself **AS it
will be installed on the end user machine**. This is something that has
a dramatic impact on the quality of code developed and released.
(Probably not something that was on the design goals for WIX but a
really great side benefit!)
--------------------------

I've only just started looking at WiX in anger, but this sounds awesome,
and I'm wondering if you felt able to write something about it, either
here or in a blog or something?

Cheers,
Roger.



-----------------------------------------
1E can save a company with 10,000 PCs over $165,000 and 1,381 tons of
CO2 emissions per annum. Calculate what you can save with NightWatchman
from 1E. Discover the benefits of System Center solutions for yourself -
attend an exclusive 1E Enterprise Solutions Road Show. Visit our website
at http://www.1e.com

DISCLAIMER: This is a PRIVATE message. If you are not the intended
recipient, please delete without copying and kindly advise us by e-mail
of the mistake in delivery. NOTE: Regardless of content, this e-mail
shall not operate to bind 1E Ltd to any order or other contract unless
pursuant to explicit written agreement or government initiative
expressly permitting the use of e-mail for such purpose

------------------------------------------------------------------------
-
This SF.net email is sponsored by: Microsoft
Defy all challenges. Microsoft(R) Visual Studio 2005.
http://clk.atdmt.com/MRT/go/vse0120000070mrt/direct/01/

[Cristian Baiu]

Bob Arnson wrote:
It will update the shared component but it won't update the other product,
so a repair operation can "undo" the patch. That's why merge modules are
falling way out of favor...

Hello Bob,
Thanks for your clarification.
It seems I will have to adress all the products using the MSM with my patch.
Fortunatelly this would be possible because all the products using my
MSM are well-known to me
(my MSM is not world-wide released - it is used only by my company's
products). However, not all these
products are using WIX so I do not have wixpdbs from their releases => I do
not have wixmsts for all of them to send to pyro. However, all the
product codes and any other potentially
usefull informations are available to me.
More, my product for which I have wixpdbs is localized (I have multiple MSIs),
but the patches I shall deliver will not be localized, so I would like
to build a patch
using only one set of differences, no matter how many
language-dependent versions I have.
So far I don't know how to instruct pyro to address my patch to all
MSIs unless I make differences for
all of them and pass all these difference sets to pyro.
Can you please advice me if it's possible to target multiple MSIs with
only one set of differences and how ?
Regards,
Cristian

[Bob Arnson]

Post by Cristian Baiu
So far I don't know how to instruct pyro to address my patch to all
MSIs unless I make differences for
all of them and pass all these difference sets to pyro.
Can you please advice me if it's possible to target multiple MSIs with
only one set of differences and how ?

You'll need to use Torch's -ax switch to use admin images. I'm not sure
how well that works to create one patch that also targets products using
.wixpdbs.

[Peter Marcu]

You should be able to pass transforms generated from wixpdb's in combination with ones generated from admin images. You will need a transform passed to torch for each product you want to target because product code information is important and I assume each language you ship has a different product code.

-----Original Message-----
From: wix-users-***@lists.sourceforge.net [mailto:wix-users-***@lists.sourceforge.net] On Behalf Of Bob Arnson
Sent: Tuesday, October 02, 2007 9:07 AM
To: Cristian Baiu
Cc: wix-***@lists.sourceforge.net
Subject: Re: [WiX-users] Fw: Some STUPID Limitations in WiX

Post by Cristian Baiu
So far I don't know how to instruct pyro to address my patch to all
MSIs unless I make differences for
all of them and pass all these difference sets to pyro.
Can you please advice me if it's possible to target multiple MSIs with
only one set of differences and how ?

You'll need to use Torch's -ax switch to use admin images. I'm not sure
how well that works to create one patch that also targets products using
.wixpdbs.

--
sig://boB
http://joyofsetup.com/



-------------------------------------------------------------------------
This SF.net email is sponsored by: Microsoft
Defy all challenges. Microsoft(R) Visual Studio 2005.
http://clk.atdmt.com/MRT/go/vse0120000070mrt/direct/01/

[Peter Marcu]

I meant pyro when I said torch below.

-----Original Message-----
From: wix-users-***@lists.sourceforge.net [mailto:wix-users-***@lists.sourceforge.net] On Behalf Of Peter Marcu
Sent: Tuesday, October 02, 2007 10:15 AM
To: Bob Arnson; Cristian Baiu
Cc: wix-***@lists.sourceforge.net
Subject: Re: [WiX-users] Fw: Some STUPID Limitations in WiX

You should be able to pass transforms generated from wixpdb's in combination with ones generated from admin images. You will need a transform passed to torch for each product you want to target because product code information is important and I assume each language you ship has a different product code.

-----Original Message-----
From: wix-users-***@lists.sourceforge.net [mailto:wix-users-***@lists.sourceforge.net] On Behalf Of Bob Arnson
Sent: Tuesday, October 02, 2007 9:07 AM
To: Cristian Baiu
Cc: wix-***@lists.sourceforge.net
Subject: Re: [WiX-users] Fw: Some STUPID Limitations in WiX

Post by Cristian Baiu
So far I don't know how to instruct pyro to address my patch to all
MSIs unless I make differences for
all of them and pass all these difference sets to pyro.
Can you please advice me if it's possible to target multiple MSIs with
only one set of differences and how ?

You'll need to use Torch's -ax switch to use admin images. I'm not sure
how well that works to create one patch that also targets products using
.wixpdbs.

--
sig://boB
http://joyofsetup.com/



-------------------------------------------------------------------------
This SF.net email is sponsored by: Microsoft
Defy all challenges. Microsoft(R) Visual Studio 2005.
http://clk.atdmt.com/MRT/go/vse0120000070mrt/direct/01/
_______________________________________________
WiX-users mailing list
WiX-***@lists.sourceforge.net
https://lists.sourceforge.net/lists/listinfo/wix-users

-------------------------------------------------------------------------
This SF.net email is sponsored by: Microsoft
Defy all challenges. Microsoft(R) Visual Studio 2005.
http://clk.atdmt.com/MRT/go/vse0120000070mrt/direct/01/

[Cristian N. Baiu]

Thanks Bob, thanks Peter for your answers.
I will not have problems with the localizations. The only problem will be
the time to generate a patch, because my setup takes a very long time to
build - about 30 mins for each MSI and I have over 20 MSI's (12 languages *
2 - due to x86 and x64). Knowing that my patches (hot-fixes most of them)
will patch only non-localizable files (practically will update versioned DLL
files), I was hoping I could optimize the patch build process by building
only two upgrade MSIs (one for x86 and x64) and then pass by some other
means only the product codes for the other MSI's to pyro. I don't know if it
would be a "best practice" but it would sure suite me. Anyway, in lack of
alternatives, I will do all the differences.

Still, the biggest of my problems is the patching of the MSM which I was
talking earlier. I have done some testing, trying to patch a (versioned) dll
which is part of my MSM using pyro but had no success. The patch log wasn't
saying anything about my file. Then I have tried to build the patch removing
all the physical occurences of the file which I needed to patch (the MSM and
MSI target and upgrade versions being build at the testing time). I have
removed the DLL from my deployment folder - from where the MSM setup
resolves it, I have removed the MSM from the folder used by the MSI which
includes the MSM, I have removed the upgrade MSI's cabinet from the folder
where torch is using it's upgrade wixpdb input file. Then I have build the
patch and had no errors. This makes me think that neither torch, candle,
light or pyro are even trying to do something with that file. (The reason
for all of these was my hope to find out which of them needs to resolve the
file and then try to debug it and understand what I've done wrong).

Peter, you said in an earlier post that you could provide some workarounds
for patching MSMs. It seems I have reached the moment when I need very bad
to know them. Could you help me please ?

Also Bob said earlier: "It will update the shared component but it won't
update the other product, so a repair operation can "undo" the patch. That's
why merge modules are
falling way out of favor..." (refering to a patch for an MSM component which
targets only one of more products containing the MSM).
These are bad news. I do not know how installer performs the repair so my
question is : does the repair replace a newer version of the shared file
with an older one if the file is versioned correctly ?

Thanks for your answers. I hope I was not too boring with my long story.
Cristian.

----- Original Message -----
From: "Peter Marcu" <***@microsoft.com>
To: "Peter Marcu" <***@microsoft.com>; "Bob Arnson"
<***@joyofsetup.com>; "Cristian Baiu" <***@gmail.com>
Cc: <wix-***@lists.sourceforge.net>
Sent: Tuesday, October 02, 2007 8:24 PM
Subject: RE: [WiX-users] Fw: Some STUPID Limitations in WiX


I meant pyro when I said torch below.

-----Original Message-----
From: wix-users-***@lists.sourceforge.net
[mailto:wix-users-***@lists.sourceforge.net] On Behalf Of Peter Marcu
Sent: Tuesday, October 02, 2007 10:15 AM
To: Bob Arnson; Cristian Baiu
Cc: wix-***@lists.sourceforge.net
Subject: Re: [WiX-users] Fw: Some STUPID Limitations in WiX

You should be able to pass transforms generated from wixpdb's in combination
with ones generated from admin images. You will need a transform passed to
torch for each product you want to target because product code information
is important and I assume each language you ship has a different product
code.

-----Original Message-----
From: wix-users-***@lists.sourceforge.net
[mailto:wix-users-***@lists.sourceforge.net] On Behalf Of Bob Arnson
Sent: Tuesday, October 02, 2007 9:07 AM
To: Cristian Baiu
Cc: wix-***@lists.sourceforge.net
Subject: Re: [WiX-users] Fw: Some STUPID Limitations in WiX

Post by Cristian Baiu
So far I don't know how to instruct pyro to address my patch to all
MSIs unless I make differences for
all of them and pass all these difference sets to pyro.
Can you please advice me if it's possible to target multiple MSIs with
only one set of differences and how ?

You'll need to use Torch's -ax switch to use admin images. I'm not sure
how well that works to create one patch that also targets products using
.wixpdbs.

--
sig://boB
http://joyofsetup.com/



-------------------------------------------------------------------------
This SF.net email is sponsored by: Microsoft
Defy all challenges. Microsoft(R) Visual Studio 2005.
http://clk.atdmt.com/MRT/go/vse0120000070mrt/direct/01/
_______________________________________________
WiX-users mailing list
WiX-***@lists.sourceforge.net
https://lists.sourceforge.net/lists/listinfo/wix-users

-------------------------------------------------------------------------
This SF.net email is sponsored by: Microsoft
Defy all challenges. Microsoft(R) Visual Studio 2005.
http://clk.atdmt.com/MRT/go/vse0120000070mrt/direct/01/

[Peter Marcu]

The problem you are hitting is that the Wixpdb contains no information about msm's they are merged in after the fact.

Three options:

1. Instead of using the wixpdb, just use the admin image functionality I added in order to create transforms for the products that contain msm's.
2. Use Melt.exe to convert your msm into a componentgroup, then remove the msm from your authoring and add in the componentgroup.
3. Don't use MSM's. :)

To answer your repair question, it depends on the flags that are passed to msi during the repair, by default the newest version wins.

One way to solve the long build time is to consider a langpack model. Where all the files that aren't per language live together in a single msi. This would mean that if you are patching a language neutral component you only have to patch the core msi and not the langpacks.

-----Original Message-----
From: Cristian N. Baiu [mailto:***@gmail.com]
Sent: Tuesday, October 02, 2007 11:18 AM
To: Peter Marcu; ***@joyofsetup.com; Cristian Baiu
Cc: wix-***@lists.sourceforge.net
Subject: Fw: [WiX-users] Fw: Some STUPID Limitations in WiX

Thanks Bob, thanks Peter for your answers.
I will not have problems with the localizations. The only problem will be
the time to generate a patch, because my setup takes a very long time to
build - about 30 mins for each MSI and I have over 20 MSI's (12 languages *
2 - due to x86 and x64). Knowing that my patches (hot-fixes most of them)
will patch only non-localizable files (practically will update versioned DLL
files), I was hoping I could optimize the patch build process by building
only two upgrade MSIs (one for x86 and x64) and then pass by some other
means only the product codes for the other MSI's to pyro. I don't know if it
would be a "best practice" but it would sure suite me. Anyway, in lack of
alternatives, I will do all the differences.

Still, the biggest of my problems is the patching of the MSM which I was
talking earlier. I have done some testing, trying to patch a (versioned) dll
which is part of my MSM using pyro but had no success. The patch log wasn't
saying anything about my file. Then I have tried to build the patch removing
all the physical occurences of the file which I needed to patch (the MSM and
MSI target and upgrade versions being build at the testing time). I have
removed the DLL from my deployment folder - from where the MSM setup
resolves it, I have removed the MSM from the folder used by the MSI which
includes the MSM, I have removed the upgrade MSI's cabinet from the folder
where torch is using it's upgrade wixpdb input file. Then I have build the
patch and had no errors. This makes me think that neither torch, candle,
light or pyro are even trying to do something with that file. (The reason
for all of these was my hope to find out which of them needs to resolve the
file and then try to debug it and understand what I've done wrong).

Peter, you said in an earlier post that you could provide some workarounds
for patching MSMs. It seems I have reached the moment when I need very bad
to know them. Could you help me please ?

Also Bob said earlier: "It will update the shared component but it won't
update the other product, so a repair operation can "undo" the patch. That's
why merge modules are
falling way out of favor..." (refering to a patch for an MSM component which
targets only one of more products containing the MSM).
These are bad news. I do not know how installer performs the repair so my
question is : does the repair replace a newer version of the shared file
with an older one if the file is versioned correctly ?

Thanks for your answers. I hope I was not too boring with my long story.
Cristian.

----- Original Message -----
From: "Peter Marcu" <***@microsoft.com>
To: "Peter Marcu" <***@microsoft.com>; "Bob Arnson"
<***@joyofsetup.com>; "Cristian Baiu" <***@gmail.com>
Cc: <wix-***@lists.sourceforge.net>
Sent: Tuesday, October 02, 2007 8:24 PM
Subject: RE: [WiX-users] Fw: Some STUPID Limitations in WiX


I meant pyro when I said torch below.

-----Original Message-----
From: wix-users-***@lists.sourceforge.net
[mailto:wix-users-***@lists.sourceforge.net] On Behalf Of Peter Marcu
Sent: Tuesday, October 02, 2007 10:15 AM
To: Bob Arnson; Cristian Baiu
Cc: wix-***@lists.sourceforge.net
Subject: Re: [WiX-users] Fw: Some STUPID Limitations in WiX

You should be able to pass transforms generated from wixpdb's in combination
with ones generated from admin images. You will need a transform passed to
torch for each product you want to target because product code information
is important and I assume each language you ship has a different product
code.

-----Original Message-----
From: wix-users-***@lists.sourceforge.net
[mailto:wix-users-***@lists.sourceforge.net] On Behalf Of Bob Arnson
Sent: Tuesday, October 02, 2007 9:07 AM
To: Cristian Baiu
Cc: wix-***@lists.sourceforge.net
Subject: Re: [WiX-users] Fw: Some STUPID Limitations in WiX

Post by Cristian Baiu
So far I don't know how to instruct pyro to address my patch to all
MSIs unless I make differences for
all of them and pass all these difference sets to pyro.
Can you please advice me if it's possible to target multiple MSIs with
only one set of differences and how ?

You'll need to use Torch's -ax switch to use admin images. I'm not sure
how well that works to create one patch that also targets products using
.wixpdbs.

--
sig://boB
http://joyofsetup.com/



-------------------------------------------------------------------------
This SF.net email is sponsored by: Microsoft
Defy all challenges. Microsoft(R) Visual Studio 2005.
http://clk.atdmt.com/MRT/go/vse0120000070mrt/direct/01/
_______________________________________________
WiX-users mailing list
WiX-***@lists.sourceforge.net
https://lists.sourceforge.net/lists/listinfo/wix-users

-------------------------------------------------------------------------
This SF.net email is sponsored by: Microsoft
Defy all challenges. Microsoft(R) Visual Studio 2005.
http://clk.atdmt.com/MRT/go/vse0120000070mrt/direct/01/

[Cristian N. Baiu]

Hello Peter,

Thanks again for your answers. Melt is great for me.

However, from what I have tested so far, I got stuck with it because of a bug (I am using Wix 3.0.3307.0).
In the generated wxs, every "Source" attribute of the "File" element contents the modularization guid in double -
like: "SourceDir\File\MyFile.ext.MSM_GUID.MSM_GUID".
I have debuged my melt version (3.0.3307.0) and found the problem in Decompiler::FinalizeFileTable.
When the the output type is Module I have
file.Source = String.Concat("SourceDir", Path.DirectorySeparatorChar, "File", Path.DirectorySeparatorChar, file.Id, '.', this.modularizationGuid.Substring(1, 36).Replace('-', '_'));
But the file.Id already contains the modularization GUID, so it would not be necessary to append it again.

I will correct the problem and build my own melt, but I would also like to have this problem corrected if possible in a future WIX release, so that I wouldn't be forced to integrate and build it everytime I need to update my WIX version.

In addition, I must say I'm disappointed that melt hardcodes "SourceDir" in the file source path instead of resolving it with the path provided through the -x switch. Due to this, it cannot be used "as it is" in an automated build process. I hope this would also be fixed someday.

Thanks a lot,
Cristian.

[Peter Marcu]

I appreciate the feedback.

Can you log bugs on sourgeforge for both issues you mentioned. I'm looking at putting some significant time into fixing bugs in WiX over the next few months and its easiest for me to track all of them if they are all logged on sourceforge.

With bugs, you will also be able to track when the bug gets fixed.

From: Cristian N. Baiu [mailto:***@gmail.com]
Sent: Wednesday, October 03, 2007 8:19 PM
To: Peter Marcu
Cc: wix-***@lists.sourceforge.net
Subject: Fw: [WiX-users] Fw: Some STUPID Limitations in WiX

Hello Peter,

Thanks again for your answers. Melt is great for me.

However, from what I have tested so far, I got stuck with it because of a bug (I am using Wix 3.0.3307.0).
In the generated wxs, every "Source" attribute of the "File" element contents the modularization guid in double -
like: "SourceDir\File\MyFile.ext.MSM_GUID.MSM_GUID".
I have debuged my melt version (3.0.3307.0) and found the problem in Decompiler::FinalizeFileTable.
When the the output type is Module I have
file.Source = String.Concat("SourceDir", Path.DirectorySeparatorChar, "File", Path.DirectorySeparatorChar, file.Id, '.', this.modularizationGuid.Substring(1, 36).Replace('-', '_'));
But the file.Id already contains the modularization GUID, so it would not be necessary to append it again.

I will correct the problem and build my own melt, but I would also like to have this problem corrected if possible in a future WIX release, so that I wouldn't be forced to integrate and build it everytime I need to update my WIX version.

In addition, I must say I'm disappointed that melt hardcodes "SourceDir" in the file source path instead of resolving it with the path provided through the -x switch. Due to this, it cannot be used "as it is" in an automated build process. I hope this would also be fixed someday.

Thanks a lot,
Cristian.