"daveboyd" <daveboyd@discussions.microsoft.com> wrote in message
news:1DF30EA3-135F-4964-910D-30487ABA296C@microsoft.com...
> Phil,
>
> I am doing a post build process on the MSI file with Orca. Could this be
> the source of the problem? I don't have the details at hand, but they
> were
> conveyed to me via some earlier dicussion group help (about January or
> February).
>
> daveboyd
>
>
>
> "Phil Wilson" wrote:
>
>> Well repair is normal in some circumstances, but it doesn't completely
>> explain what you're seeing, although it's involved somewhere. Repair will
>> restore deleted files but it will not replace user-modified files. My
>> tests
>> with a setup and repair do not cause a modified text file to be replaced.
>> So
>> something else is going on. If the user removed a file, then a repair
>> would
>> kick in, snd this would restore missing files and run install custom
>> actions
>> again. If you have an install custom action that initializes the file,
>> that
>> would explain what you're seeing.
>> --
>> Phil Wilson
>> [Microsoft MVP-Windows Installer]
>> "daveboyd" <daveboyd@discussions.microsoft.com> wrote in message
>> news:A0A44D76-D12C-4B82-9769-704DCA8E498F@microsoft.com...
>> > Yes, I want to have some distributed files in my application that are
>> > not
>> > "repaired".
>> >
>> > Just to be clear, the "normal repair situation", seems to be invoked
>> > whenever the user changes a distributed file (installed by the MSI
>> > file)
>> > and
>> > then invokes the program. Instead of simply starting the program the
>> > "repair" is invoked and the users changes are lost by the installer
>> > replacing
>> > it with the original file and only then the program is started.
>> >
>> > This is extremely confusing to the user who has followed directions to
>> > edit
>> > and set the configuration file to his/her specific share.
>> >
>> > I naively assumed there is a setting in the VS installation build area
>> > to
>> > not do this "repair" behavior for specific files which I asked about in
>> > my
>> > original post. Sorry that was unclear.
>> >
>> > While this is interesting and admirable behavior for files that are
>> > critical
>> > for the application to run correctly, how do I distribute a
>> > configuration
>> > file that can be changed by the user without invoking this dictatorial
>> > big
>> > brother?
>> >
>> > Thanks,
>> >
>> > Dave Boyd
>> >
>> > "Phil Wilson" wrote:
>> >
>> >> I don't exactly understand what you mean - are you saying that the
>> >> user
>> >> installs the app from the MSI file, and then changes some files, after
>> >> which
>> >> the files get restored from the MSI file, replacing the changed files?
>> >> If
>> >> so, this is normal repair situation.
>> >> --
>> >> Phil Wilson
>> >> [Microsoft MVP-Windows Installer]
>> >> Definitive Guide to Windows Installer
>> >> http://apress.com/book/bookDisplay.html?bID=280
>> >>
>> >> "daveboyd" <daveboyd@discussions.microsoft.com> wrote in message
>> >> news:5D985200-9EF7-4BF9-9D88-D39A5CE3BB1F@microsoft.com...
>> >> > In vs 2003 the installer subproject builds an MSI file that includes
>> >> > several
>> >> > configuration files. These files have a setting that causes the
>> >> > installer
>> >> > to
>> >> > rebuild the files from the original distribution whenever the user
>> >> > changes
>> >> > them. What setting is required to get the installer to ignore
>> >> > changes
>> >> > to
>> >> > these user configuration files after installation?
>> >> >
>> >> > Thanks!
>> >>
>> >>
>> >>
>>
>>
>>