Hehe!!!!
I suppose some of our international users might not understand the reference
especialling since I said dangling chad instead of hanging chad. In case you
don't know, it's a reference to problematic paper ballots used during elections.
Anyways, at the time I started using the expression for setups I was working
at a company called Hart InterCivic that was in the elections space. We
actually worked in a different space but it just fit.
Chad Petersen <[EMAIL PROTECTED]> wrote:
v\:* {behavior:url(#default#VML);} o\:* {behavior:url(#default#VML);}
w\:* {behavior:url(#default#VML);} .shape {behavior:url(#default#VML);}
st1\:*{behavior:url(#default#ieooui) } 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
-------------------------------------------------------------------------
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
