Hey Chris,
I would say that dynamically linking files can be an issue but there are
some products out there that need to do this. The biggest thing I can see is
not what files should be included. In our product deployment cycles we would
run binary delta compares to ensure release integrity, know exactly what got
changed from development and to make sure that nothing like "weed.gif" was
going out the door (that was actually caught once!).
Our product was over 10,000 files in size. This spawned the WIXML project
that I have posted on codeplex. As part of my disclaimer I did not yet get
to managing the components as development has been paused for over a year.
However, the speed increase over InstallShield was substantial as we were
deploying COM+ as well. We got passed the component match up the hard way
which was to do full uninstalls and reinstalls of products that used this
feature. Overall though, the full build from development drop to package
ready to ship took 5 minutes. This installed over 300 COM+ objects, 15
vdirs, 2 services, 10 COM servers and everything else that was needed along
with dynamically managing XML, Web.config, INI and text files through an
answerfile.
The theory in place for the future of that project would be to use last
version .wxs files with component GUIDs to pass on the correct GUIDs to the
new version build. Always simple in theory and that is about as far as it
has gone. Once that was in place it would actually allow for automation of
patch and upgrade creation while building the current release. I thought
that would be a great feature to have there as well.
--
Brian Rogers
"Intelligence removes complexity." - BR
http://www.codeplex.com/wixml/
On 9/11/07, Christopher Painter <[EMAIL PROTECTED]> wrote:
>
> Richard <[EMAIL PROTECTED]> wrote:
>
> >> A semi easier solution is to write something that calls "heat dir" each
> time
> >> to generate a .wxs you include in your build. Should take about a day
> of
> >> dev/testing.
>
> >Ah, much better, thank you.
>
> Funny, InstallShield has had this functionality for years... it's called
> dynamic file linking. And I'm sure if I was to call it by this name many
> people in this list would jump to say `Don't Use It`. And yet it's the same
> thing as calling heat at build time.
>
> I don't use dynamic file linking because it causes some very serious
> problems. Some obvious and some not so obvious. I cover many of them (
> and how things could be made better by tools vendors ) at:
>
>
> http://blog.deploymentengineering.com/2007/06/dealing-with-very-large-number-of-files.html
>
> The first problem is enforcing component rules. It gets very difficult to
> decide which files should be key files, making sure that their
> ComponentID's are consistent. A second problem is performance... it's a
> really slow build process that has to dynamically author an install and
> check previous packages to sync ComponentID's ( InstallShield does this
> ).
>
> My real problem is that I don't try to guess developer intent. That is
> what happens when new files show up and files disappear. Just because
> some file shows up doesn't mean it should be deployed.... maybe someone
> had a compiler setting wrong ( like a CopyLocal=True when it shouldn't have
> been ) or they did something stupid like check a file in that they
> shouldn't have. And what happens when a file disappears... it's very
> difficult to author a punctured component story and have that keyfile go
> away during a minor upgrade. Then of course there is the basic failure
> mode problem.... if a file goes missing that should not have, well we are
> dynamic so it won't throw a build error.
>
> I'm sorry but this is a story that needs to be looked at much deeper then
> say zip it up and use a CA or use dynamic file linking/heat to
> autogenerate. MSI doesn't make setup easy in this area.
>
>
> ------------------------------
> Looking for a deal? Find great prices on flights and
> hotels<http://us.rd.yahoo.com/evt=47094/*http://farechase.yahoo.com/;_ylc=X3oDMTFicDJoNDllBF9TAzk3NDA3NTg5BHBvcwMxMwRzZWMDZ3JvdXBzBHNsawNlbWFpbC1uY20->with
> Yahoo! FareChase.
>
>
> -------------------------------------------------------------------------
> 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-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 2005.
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
