This website uses cookies. By clicking Accept, you consent to the use of cookies. Click Here to learn more about how we use cookies.
Turn on suggestions
Auto-suggest helps you quickly narrow down your search results by suggesting possible matches as you type.
- Revenera Community
- :
- InstallShield
- :
- InstallShield Forum
- :
- XML Files (Unversioned Files)
Subscribe
- Mark Topic as New
- Mark Topic as Read
- Float this Topic for Current User
- Subscribe
- Mute
- Printer Friendly Page
- Mark as New
- Subscribe
- Mute
- Permalink
- Report Inappropriate Content
Jan 05, 2010
06:59 AM
XML Files (Unversioned Files)
Scenario:
Basic MSI, 1 feature.......simple start.
Lots of XML Files (1000+) that would have todays creation and modified date (touched) built into 'this' brand new MSI under 1 component (called myxml).
myxml component has a key file of README.TXT with todays creation and modified date.
Build MSI and deploy.
1 month down the line the developer updates 3 XML files.
So I build another full build MSI, using the old MSI for validation and build an update.exe file
Deploy update.exe
All the above should work as the 'versioning rules' would see that the 3 developer updated files have modifed dates and therefore overwrite those previously installed.
In the 'real' world at the customers site 1 week after the update.exe has been released but before the customer has installed it, they go and edit by chance 1 of the 3 files and add an extra space at the bottom of the file and save it.
This 1 installed XML file now has a modifed date that is later (by 1 week) than my update.exe and therfore the update does not overwrite the file. (classes it as user data).
Am I correct so far in my logic?
If I am, then I need to force an overwrite of those 3 files.
Options are from my understanding:
Companion files
or
Always overwrite (Basically update the version in the file table of those 3 files) so it look as if the files are now versioned and this should force an overwrite.
Scenario continues:
Another month down the line, 5 XML files have changed, only 1 of those where a XML file that was changed in the prior update.
This is scaled down........I ship almost 20,000 unversioned files of various types.
My questions are:
How should I be treating unversioned XML files that could be updated by a user (they shouldn't be changing them but they do) to ensure patching, minor updates etc always work?
How do I ensure my updates are small (Out of the 1000 XML files only 5 where changed, therfore I only need those 5 in the update)?
Would I be better of creating a dummy.dll and making that they key file for myxml component and updating the version number in the dll when any of my XML files are updates?
If I have 10 components each with different types of unversioned files, create 10 dummy.dll's, do I add the dll as a sepapte component and make it a companion file or should I be adding the dummy.dll to it's component group as the key?
If I was to version an XML file in the file table, lets say today I start at 1.0.0.1 (in the first update this should overwrite the original file), for the 2nd change could I just update the file table again and make the file version 1.0.0.2?
Best Practices are important to me, so where possible I'd like to follow them.
Open to constructive ideas!!
Neil
Basic MSI, 1 feature.......simple start.
Lots of XML Files (1000+) that would have todays creation and modified date (touched) built into 'this' brand new MSI under 1 component (called myxml).
myxml component has a key file of README.TXT with todays creation and modified date.
Build MSI and deploy.
1 month down the line the developer updates 3 XML files.
So I build another full build MSI, using the old MSI for validation and build an update.exe file
Deploy update.exe
All the above should work as the 'versioning rules' would see that the 3 developer updated files have modifed dates and therefore overwrite those previously installed.
In the 'real' world at the customers site 1 week after the update.exe has been released but before the customer has installed it, they go and edit by chance 1 of the 3 files and add an extra space at the bottom of the file and save it.
This 1 installed XML file now has a modifed date that is later (by 1 week) than my update.exe and therfore the update does not overwrite the file. (classes it as user data).
Am I correct so far in my logic?
If I am, then I need to force an overwrite of those 3 files.
Options are from my understanding:
Companion files
or
Always overwrite (Basically update the version in the file table of those 3 files) so it look as if the files are now versioned and this should force an overwrite.
Scenario continues:
Another month down the line, 5 XML files have changed, only 1 of those where a XML file that was changed in the prior update.
This is scaled down........I ship almost 20,000 unversioned files of various types.
My questions are:
How should I be treating unversioned XML files that could be updated by a user (they shouldn't be changing them but they do) to ensure patching, minor updates etc always work?
How do I ensure my updates are small (Out of the 1000 XML files only 5 where changed, therfore I only need those 5 in the update)?
Would I be better of creating a dummy.dll and making that they key file for myxml component and updating the version number in the dll when any of my XML files are updates?
If I have 10 components each with different types of unversioned files, create 10 dummy.dll's, do I add the dll as a sepapte component and make it a companion file or should I be adding the dummy.dll to it's component group as the key?
If I was to version an XML file in the file table, lets say today I start at 1.0.0.1 (in the first update this should overwrite the original file), for the 2nd change could I just update the file table again and make the file version 1.0.0.2?
Best Practices are important to me, so where possible I'd like to follow them.
Open to constructive ideas!!
Neil
(1) Reply
- Mark as New
- Subscribe
- Mute
- Permalink
- Report Inappropriate Content
Jan 06, 2010
12:31 AM
Anyone give a clue?
