You may have other problems to deal with also. At places I've worked, the doco
people have been really horrible. The first typical problem ( which you are
already describing ) is that they have no concept of integration, design by
contract or abstraction. Not only will their build output tree look
completly different from build to build, but sometimes their main web page
will be a different name. Makes it practically impossible to create shortcuts
for them in the start menu.... even if you are doing dynamic linking because
how do you decide which file should have the short cut?
The worst problem I've seen though is the `chicken and the egg` paradox.
The writers would always be lagging the development of the product and as we
neared release and code freeze they wouldn't be done until after the product
was done and they would be begging for additional builds after code freeze.
At one place it was so bad that I finally decided to take all of the
documentation out of the install and have it just get dropped on the CD DISK1
image so that the main install's bootstrapper could just install it as a
seperate package.
Has anyone else seen these problems from their doco team and if so, how did
you handle it?
David Stindl <[EMAIL PROTECTED]> wrote:
Yes you are right, guys... Dynamical file linking is normally very
dangerous operation, from logic reasons... But there are situations,
when it is really useful.. In my case we have any static-html
documentation of our web application and i need to include it as it
comes from our documentation team. Because our installation makers &
developers knows principally nothing about documentations structure,
they need take it as it is - as product of third party... Of course,
such installation needs more testing issues etc... Thanks a lot for
your opinions...
Regards
David
2007/9/11, Christopher Painter :
> I know the feeling. I have it baked into my build automation to run a unit
> test that compares the available files to an administrative install. If any
> files are new in the build area but missing in the installer, a build error
> is thrown. From there we find out who put the files there and make them
> answer if it's a valid file to be deployed or not. Either the file gets
> yanked from the build output or it gets added to the installer and then a
> rebuild is performed. It was painful at first performing this
> reconciliation but now developers are educated enough to know to request
> files be added to the install.
>
> The last time I used dynamic file linking was for a `fake msi` that acted as
> a bootstrapper. One of the things the bootstrapper did was a MSOffice LSI
> style caching which used features/components/files to install the package
> source but not register it as a real installed product. Some of the
> packages that were redist were 3rd party uncompressed installs so dynamic
> linking helped there.
>
> Brian Rogers wrote:
> 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!).
>
>
> ________________________________
> Fussy? Opinionated? Impossible to please? Perfect. Join Yahoo!'s user panel
> and lay it on us.
>
>
> -------------------------------------------------------------------------
> 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
>
>
---------------------------------
Tonight's top picks. What will you watch tonight? Preview the hottest shows on
Yahoo! TV. -------------------------------------------------------------------------
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
