Ok, I just tested that. I need to put the CopyFile-Tag into a separate 
Component with a neveroverwrite="yes" attribute. Then the file gets updated as 
long as there were no changes made to the file. If I change the file and start 
an update after that, the file does not get touched by the installer. Nice. 
That should solve my problem.

Thx again

-----Ursprüngliche Nachricht-----
Von: Christian Hausknecht [mailto:chauskne...@beracom.de] 
Gesendet: Freitag, 28. September 2012 11:26
An: General discussion for Windows Installer XML toolset.
Betreff: Re: [WiX-users] [Spam-Wahrscheinlichkeit=37]Re: Major Upgrades, Burn 
and determining, which actions to do

Hi Neil,

@1.) Ah... I think I never tested to change the file and then run the update 
installer... I will figure that out! Would be nice, if that is the trick :-) 
Yes, I need to copy files. We have formular templates that the user can change. 
We always ship our default templates as a backup, but we do not want to 
override the customized templates. But if you are right, that would perfectly 
fit our needs I think!

@2.) I just got the confirmation that our scripts behave exactly like that (so 
they are idempotent like Rob said it) - one thing less to bother with...

-----Ursprüngliche Nachricht-----
Von: Neil Sleightholm [mailto:n...@x2systems.com]
Gesendet: Freitag, 28. September 2012 10:04
An: General discussion for Windows Installer XML toolset.
Betreff: Re: [WiX-users] [Spam-Wahrscheinlichkeit=37]Re: Major Upgrades, Burn 
and determining, which actions to do

1. I think that if the file is changed after a copy then it is not removed. Do 
you need to copy the file? If not you could mark it permanent.

2. We use idempotent scripts for SQL so that there is a single SQL script that 
can update from any version to the latest.

Neil



>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


------------------------------------------------------------------------------
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



------------------------------------------------------------------------------
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

Reply via email to