I take exception to your 'dangling chad' remark. Why can't it be a
"dangling chris"? Just this once?
________________________________
From: [EMAIL PROTECTED]
[mailto:[EMAIL PROTECTED] On Behalf Of
Christopher Painter
Sent: Tuesday, May 20, 2008 8:51 AM
To: Ene Stelian-Bogdan; Rob Mensching; wix-users@lists.sourceforge.net
Subject: Re: [WiX-users] Integrate WiX in our process
I'd like to address a couple things about InstallShield. In IS2009
(currently Beta) there is improved support for dynamic linking and
upgrading/patching support. Things like table primary key identifiers
and component guids should be much better behaved. Even then, I would
really hesitate to use the feature for reasons I explain below.
Also you don't have to use the clunky</disagree> GUI to author installs
with InstallShield. There is an automation interface. It's COM based
and it makes sense to a VB6/Script user but from a C#/Interop
perspective, it is somewhat clunky.
However, I have a bigger philosophical problem with this type of
`dynamic` pattern regardless of how it's implemented. How do you
really know that what's been handed to you truly represents the
developers intent?
I do build and install automation and all the time I see what I call
the `dangling chad` phenom - `deciphering developer (voter) intent`.
Either some file is missing or some file is new. The question is,
should it really be missing ( or is it a build failure? ) or should it
really be new ( or was it an accident? ). It's impossible to know for
100% certain without asking the developer. Is less then 100% good
enough? I guess it depends.
So what I do is write some build automation that uses an Administrative
Install to extract the build and then compare it to the sources.
Missing files cause a build break and extra files cause a build break.
When a build breaks, we find out why and fix it. This could mean fixing
a broken project that's missing a file, fixing a project project that
outputs too many files or updating the installer to reflect the new
state.
Now `updating to reflect the new state` could be a manual process or
you could write some automation to do it. Which route you go depends
on the level of pain of doing it manual ... the ROI if you will.
Either way, in my book, you can't do either until you first decipher
intent.
Regards,
Christopher Painter
http://blog.deploymentengineering.com
Ene Stelian-Bogdan <[EMAIL PROTECTED]> wrote:
Hi Rob, thanks for your answer
The few shared files are in components defined manually, so it's
not a
problem. When it comes to the thousand of (unshared) files,
manually
defining components is not an option - there's no way to do it
in code,
one must use Installshield's clunky GUI. This setup works pretty
well,
except when it comes to patching.
Indeed, NSIS's interaction with MSI is not that good, this is
why we are
looking for solutions of harmonizing patching with the main
installer.
Regarding your personal philosophy, I don't think there's really
a
choice when using MSI. How am I supposed to know what files are
to be
modified on the user's system, in a future patch ? How can I
correctly
define components without an intimate knowledge of the
relationship
between files ? I can only go the paranoid path of one component
/ file,
and at the same time, flush any performance down the drain -
most of our
files are small include headers in the KB range.
Upon further consideration, maybe MSI is not that well suited
for us,
and what I should do is move the main product to an xcopy setup,
and do
away with these pesky components altogether :)
--
Stelian ENE
Installer Engineer, DevTech
Freescale Semiconductor Romania
Work: +40 21 305 2064
Mobile: +40 728 052 499
This e-mail, and any associated attachments have been classified
as:
[X] Public
[ ] Freescale Semiconductor Internal Use Only
[ ] Freescale Semiconductor Confidential Proprietary
-----Original Message-----
From: Rob Mensching [mailto:[EMAIL PROTECTED]
Sent: Monday, May 19, 2008 9:10 PM
To: Ene Stelian-Bogdan; wix-users@lists.sourceforge.net
Subject: RE: Integrate WiX in our process
The "Dynamic linking" feature where Component Ids change with
every
build makes it impossible to patch. In fact, I think the only
option
available to you using that methodology for creating MSI
packages is
major upgrade. Also, I assume you don't have any shared files in
the
"big zip file" because those would not be reference counted
correctly.
It's interesting you use NSIS for the patches. Does the
interaction
between NSIS patches plus MSI repair/uninstall work out well?
I'm not up on the intimate details of patching but there are new
features in the WiX toolset that enable you to create patches
that
target subsets of your setup authoring. That enables you to
build
independent patches for different areas of your installation.
However,
when you need to patch the same file more than once, the patch
ordering
definitely becomes an issue. I'm not sure this advanced
functionality
is available unless you use the WiX toolset to create the MSI (I
think a
lot of information comes from the .wixpdb), but it *may* be
possible
using admin images.
Ultimately, I believe that you are correct that maintaining
Component
Guids is going to be the hardest problem to tackle when creating
your
patch system. I know Bob had to tackle this exact problem in his
day
job so he may have suggestions of things to try or avoid. I also
know
that tallow/heat in their current form will not help you because
they
don't correctly assign Guids. I haven't tried paraffin but on my
initial readings it looked like it was trying to do the right
thing...
but I don't know if it works in this sort of scenario.
Note, these issues for Component Guid are a recognized pain
point in the
Windows Installer. I'm still working on a way to solve the
problem of
automatic Guid generation.
Finally, the "philosophy" that each developer should maintain
their
portion of setup is my personal philosophy. The WiX toolset has
features to enable such distributed setup development but that
doesn't
mean you have to use them.
-----Original Message-----
From: [EMAIL PROTECTED]
[mailto:[EMAIL PROTECTED] On Behalf Of
Ene
Stelian-Bogdan
Sent: Monday, May 19, 2008 09:41
To: wix-users@lists.sourceforge.net
Subject: [WiX-users] Integrate WiX in our process
Hello,
Here's the way our process currently looks like:
- We build and ship the main product installer as an MSI,
Installshield
based project. I am talking about a 900MB product, comprising of
about
15.000 files and 2300 folders, so we use Installshield's
"Dynamic
linking" feature extensively. (Basically, you point to a folder,
and
components will be generated on the fly at build time, one
component per
directory; the ComponentIDs will of course change on every
rebuild)
Needless to say, we don't subscribe to the MSI/WiX philosophy of
having
developers maintain the installer components; I receive one big
zip
file, and must deliver an installer. While I have nothing
against
changing this state of facts, I don't think it will change soon.
- When new chips are introduced, we must deliver a "Service
pack" that
will offer compiling/debugging support for it. The patch will
generally
add new files to the installation, and sometimes update existing
files,
always in a backwards-compatible manner. Since customers will
download
only the patch offering support for the device they are working
with,
these patches can be applied more or less in any order.
Currently, these
patches are built using the NullSoft installer.
As a first step, I'd like to get rid of NullSoft, and replace it
with
WiX; on the long run, a full transition to WiX could be an
interesting
option.
I don't understand how I can use MSI's own patching support: it
seems to
impose a linear evolution of the product, with a well defined
sequence
of applying patches - and by all means, do correct me if I'm
wrong.
My first impulse is to integrate something like tallow/paraffin
in the
patch build system, and generate service packs as standalone
installers
with 1 component/file (performance of patches is not really
critical,
they are quite small). Coupled with Installshield's dynamic
linking,
this is bound to break the component rules in a systematic
manner. Also,
there's the open issue of uninstalling these patches when the
main
product is uninstalled.
Can you provide some pointers on the best way to proceed ?
Thank you !
--
Stelian ENE
Installer Engineer, DevTech
Freescale Semiconductor
Work: +40 21 305 2064
Mobile: +40 728 052 499
This e-mail, and any associated attachments have been classified
as:
[X] Public
[ ] Freescale Semiconductor Internal Use Only [ ] Freescale
Semiconductor Confidential Proprietary
------------------------------------------------------------------------
-
This SF.net email is sponsored by: Microsoft Defy all
challenges.
Microsoft(R) Visual Studio 2008.
http://clk.atdmt.com/MRT/go/vse0120000070mrt/direct/01/
_______________________________________________
WiX-users mailing list
WiX-users@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 2008.
http://clk.atdmt.com/MRT/go/vse0120000070mrt/direct/01/
_______________________________________________
WiX-users mailing list
WiX-users@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 2008.
http://clk.atdmt.com/MRT/go/vse0120000070mrt/direct/01/
_______________________________________________
WiX-users mailing list
WiX-users@lists.sourceforge.net
https://lists.sourceforge.net/lists/listinfo/wix-users
