Hey Rob, thanks for your answer.
@1.) Yes, I did so and sadly the copied content gets removed :-( So I assume I will write a CA that handles the copying and take the responsibility for the files away from WiX. @2.) Yes, that sounds like a good idea - as I do not know the scripts very well yet I will evaluate that issue. Greetings, Chris -----Ursprüngliche Nachricht----- Von: Rob Mensching [mailto:r...@robmensching.com] Gesendet: Freitag, 28. September 2012 04:58 An: General discussion for Windows Installer XML toolset. Betreff: [Spam-Wahrscheinlichkeit=37]Re: [WiX-users] Major Upgrades, Burn and determining, which actions to do 1. IIRC, (I try to avoid CopyFile so I could be mistaken) uninstalling an MSI does not remove the copied content. You could create a quick MSI to verify. 2. I highly recommend making your scripts idempotent. Thus, you can always run them and if they've already been applied, they do nothing. Makes life much easier. On Thu, Sep 27, 2012 at 1:29 AM, Christian Hausknecht < chauskne...@beracom.de> wrote: > Hello folks, > > as I did not get any answers to my last question, I try to be more > precise today. > > I want to make an Installer with burn, that installs quite a big > application. So there are different things to do, like just install > some files, copy some files around, initiating a database and so on. > Now I need to plan an update strategy before I actually start working > on implementing the installer. As far as I know today, a major upgrade > always deletes all elements which are related with the given > Upgradecode. So that is in fact sometimes a problem. I have some > formular templates which are copied to a different location after > installation (with copyfile-Tag). So are those formular copies also > uninstalled during a major upgrade? If so, is there a way to prevent > them from being uninstalled? As customers can change the copies the > update should not delete their work... only the new default formulars should > be shipped... > > Another thing that gets me stuck is executing a script for database > modification. Assuming I have a version 1.0.0 and some further > versions like 1.0.1, 1.0.2, and so on. My plan is to build a full > installer and an update installer for each version. But of course the > update installer should be running on every customer machine that has > a version prior to the current one. But how can I tell burn not to > execute all database scripts but only those needed based upon the > current version? For example a client has the version 1.0.1 (no matter > if he fully installed at that version or made already an update from > 1.0.0). Now the current version is 1.0.2. If he launches the current > update installer, it should only execute the db-update-script that is > needed in order to transform 1.0.1 db to a 1.0.2 db. But of course the > db-script for transforming a 1.0.0 to a 1.0.1 is also bundled within > the installer, as other customers might still stay at the 1.0.0. I > definitely do not want to ship x different update installers for x > existing program version that must be executed in a special sequence... so > how can I achieve that goal? > > I hope you can help me with that issue :) > > Greetings, > > Mit freundlichen Grüßen > > Christian Hausknecht > Entwicklung > > BeraCom > Beratung und Software-Entwicklung GmbH & Co. KG Weidestr. 134, 22083 > Hamburg > T: +49 (0)40 547 241 - DW > F: +49 (0)40 547 241 - 60 > M: chauskne...@beracom.de<mailto:chauskne...@beracom.de> > http://www.beracom.de > > ============================================= > Kommanditgesellschaft: Sitz Hamburg, RG Hamburg, HRA 90932 Persönlich > haftende Gesellschafterin: BeraCom Beratung und Software-Entwicklung > GmbH Sitz Hamburg, RG Hamburg, HRB 64844 > Geschäftsführer: Arno Schaefer, Britta Kahlfuss Diese E-Mail ist > vertraulich und exklusiv für den/die Adressaten bestimmt. > Weiterleitung oder Kopieren, auch auszugsweise, darf nur mit > ausdrücklicher schriftlicher Einwilligung des Absenders erfolgen. In > jedem Fall ist sicherzustellen, dass keinerlei inhaltliche > Veränderungen erfolgen. Der Absender ist von der Richtigkeit dieser > Mail zum Zeitpunkt ihrer Erstellung überzeugt. Er und/oder sein > Unternehmen übernimmt jedoch keine Haftung für ihre Richtigkeit. > > > ---------------------------------------------------------------------- > -------- Everyone hates slow websites. So do we. > Make your web apps faster with AppDynamics Download AppDynamics Lite > for free today: > http://ad.doubleclick.net/clk;258768047;13503038;j? > http://info.appdynamics.com/FreeJavaPerformanceDownload.html > _______________________________________________ > WiX-users mailing list > WiX-users@lists.sourceforge.net > https://lists.sourceforge.net/lists/listinfo/wix-users > -- virtually, Rob Mensching http://RobMensching.com LLC ------------------------------------------------------------------------------ Got visibility? Most devs has no idea what their production app looks like. Find out how fast your code is with AppDynamics Lite. http://ad.doubleclick.net/clk;262219671;13503038;y? http://info.appdynamics.com/FreeJavaPerformanceDownload.html _______________________________________________ WiX-users mailing list WiX-users@lists.sourceforge.net https://lists.sourceforge.net/lists/listinfo/wix-users ------------------------------------------------------------------------------ Got visibility? Most devs has no idea what their production app looks like. Find out how fast your code is with AppDynamics Lite. http://ad.doubleclick.net/clk;262219671;13503038;y? http://info.appdynamics.com/FreeJavaPerformanceDownload.html _______________________________________________ WiX-users mailing list WiX-users@lists.sourceforge.net https://lists.sourceforge.net/lists/listinfo/wix-users
