[wix-users] Issues with Component with Auto Generated GUID
Ven H
venh.123 at gmail.com
Mon Mar 26 04:17:46 PDT 2018
Hi Harold,
I am a little familiar with Custom Action. But I am not sure on how to
backup a file during upgrade and restore it after upgrade. I am not sure if
this will require custom code and if so, what should go inside it and if
not, how to get it done in a declarative way.
Regards,
Venkatesh
On Mon, Mar 26, 2018 at 4:32 PM, harald goci <harald.goci at panagenda.com>
wrote:
> Hi Venkatesh,
> I am confused about the details you are asking for ...
> On 2018-03-20 you asked a very detailed question about custom actions.
> Therefore I expected that you are familiar with the concept of custom
> actions.
>
> BR,
> Harald Goci
> Senior Software Engineer
>
> Email: harald.goci at panagenda.com - Web: www.panagenda.com
> Phone: +43 1 890 12 89-44 - Fax: +43 1 890 12 89-15
>
> (Embedded image moved to file: pic06334.jpg)
>
> panagenda GmbH - Schreyvogelgasse 3/10 - 1010 Vienna - Austria
> Registered Office: Vienna - HG Wien - FN 293516t - VAT-ID: ATU63362738
> Executive Directors: Florian Vogler (CEO & CTO), Felix Vogler (CFO & COO)
>
> (Embedded image moved to file: pic26500.jpg)
>
> The information in this E-Mail is confidential and privileged. It is
> intended solely for the addressee. Access to this E-Mail by anyone else is
> unauthorized. If you are not the intended recipient, any disclosure,
> copying, distribution or any action taken in reliance on it is prohibited
> and will be unlawful. If you receive this message in error, please notify
> the sender immediately and delete all copies of this message.
>
>
>
>
> From: Ven H <venh.123 at gmail.com>
> To: harald goci <harald.goci at panagenda.com>
> Cc: WiX Toolset Users Mailing List
> <wix-users at lists.wixtoolset.org>, Christopher Painter
> <chrpai at iswix.com>, wix-users
> <wix-users-bounces at lists.wixtoolset.org>
> Date: 26.03.2018 12:34
> Subject: Re: [wix-users] Issues with Component with Auto Generated
> GUID
>
>
>
> No Harold. I am not sure of how to do it. Also, as I mentioned earlier, I
> am not sure if it will be advisable for multiple files and even if not, I
> am not sure how to do it. Can you please provide some more details?
>
> Regards,
> Venkatesh
>
> On Mon, Mar 26, 2018 at 3:41 PM, harald goci <harald.goci at panagenda.com>
> wrote:
> Hi Venkatesh,
> have you considered to write a custom action that saves the content
> of the
> config file to a different file which is not known by the uninstall?
>
> BR,
> Harald Goci
> Senior Software Engineer
>
> Email: harald.goci at panagenda.com - Web: www.panagenda.com
> Phone: +43 1 890 12 89-44 - Fax: +43 1 890 12 89-15
>
> (Embedded image moved to file: pic00041.jpg)
>
> panagenda GmbH - Schreyvogelgasse 3/10 - 1010 Vienna - Austria
> Registered Office: Vienna - HG Wien - FN 293516t - VAT-ID:
> ATU63362738
> Executive Directors: Florian Vogler (CEO & CTO), Felix Vogler (CFO &
> COO)
>
> (Embedded image moved to file: pic18467.jpg)
>
> The information in this E-Mail is confidential and privileged. It is
> intended solely for the addressee. Access to this E-Mail by anyone
> else is
> unauthorized. If you are not the intended recipient, any disclosure,
> copying, distribution or any action taken in reliance on it is
> prohibited
> and will be unlawful. If you receive this message in error, please
> notify
> the sender immediately and delete all copies of this message.
>
>
>
>
> From: Ven H via wix-users <wix-users at lists.wixtoolset.org>
> To: Christopher Painter <chrpai at iswix.com>
> Cc: Ven H <venh.123 at gmail.com>, WiX Toolset Users Mailing List
> <wix-users at lists.wixtoolset.org>
> Date: 26.03.2018 11:59
> Subject: Re: [wix-users] Issues with Component with Auto
> Generated GUID
> Sent by: "wix-users" <wix-users-bounces at lists.wixtoolset.org>
>
>
>
> Thank you all. Appreciate the time and efforts you all have taken to
> provide your valuable inputs. Unfortunately, the situation is what it
> is
> right now. It may not be possible to change it right away. But, the
> client
> is already in the process of rewriting the whole stuff. But as per
> the
> current situation, they have made some mistakes like having more than
> 1
> file in a single component. Also, the Component Guid is assigned a
> new guid
> using c# utility. So, their component IDs change with every build.
> After
> deploying their MSI at their end customer, the end customer has
> changed one
> of the files in the target. So, now the expectation is this file
> should not
> be overwritten, but other files which are part of the same component
> should
> get replaced during the major upgrade. I have tried various
> combinations of
> Schedule attribute values, but they work only if the Component ID
> remains
> the same between install and upgrade. If not, in some cases, the
> folder
> containing the files gets removed during the upgrade and gets
> recreated
> only when the upgrade installer is run the 2nd time. I am not sure
> why this
> is happening. Given this requirement, I am trying to understand if
> anyone
> has come across a similar situation in the past and if so, how you
> handled
> it. Also, even though, I have mentioned 1 component with 4 files, in
> the
> actual case, there are many components and files. Hence backing up
> through
> custom action and restoring them will be very difficult.
>
> Regards,
> Venkatesh
>
> On Fri, Mar 23, 2018 at 11:18 PM, Christopher Painter <
> chrpai at iswix.com>
> wrote:
>
> > I've come to realize configuration really needs to be two files.
> It's
> > impossible for the installer to be correct otherwise.
> >
> >
> > MSI versioning rules just weren't made for XML/JSON/Other complex
> files.
> > You can...
> >
> >
> > 1) Overwrite the file and lose user data
> >
> > 2) Not overwrite the file and lose some new data provided by the
> newer
> > version.
> >
> >
> > Either way you run the risk of being wrong regardless of how good
> you are
> > with MSI gymnastics. The only way, IMO, to solve the problem is
> to
> split
> > the data into two files. One that the installer can safely always
> > overwrite as to not being wrong #2 style and to never overwrite the
> user
> > data so that you are never wrong #1 style.
> >
> >
> > Otherwise get really good at gymnastics as you come up with ways of
> > harvesting the user data, replacing the file and overwriting the
> data.
> > And if any of this goes wrong it's the installers fault.
> >
> >
> > I'm a very high volume setup developer. I take on dozens of
> customers a
> > year, Between them and my day job, I probably write around 100
> installs a
> > year. Sometimes a customer will come back to me a few years later
> for an
> > enhancement and I'm a little ashamed to say I don't always remember
> them.
> > But my patterns are consistent and I can pick it right back up and
> make
> > them happy. I've been doing this tempo for 10+ years now.
> Edwin's
> > rant is right on the money: The only way to keep up this pace and
> maintain
> > happy customers/users is to design the application to fit the box.
> It
> > is better to do configuration in a general purpose programming
> language
> and
> > I offer that as a service also if they don't have time to do it
> > themselves. They will understand a C# configuration utility far
> more
> > then they will some custom installer logic.
> >
> >
> > I used to fight that notion and be willing to do all kinds of
> tricks in
> > the installer because I was only working on a half dozen installers
> a
> > year. That just doesn't scale though.
> >
> >
> > Good luck!
> >
> >
> > Chris
> >
> >
> > ------------------------------
> > *From:* Edwin Castro <egcastr at gmail.com>
> > *Sent:* Friday, March 23, 2018 12:23 PM
> > *To:* WiX Toolset Users Mailing List
> > *Cc:* Christopher Painter; Ven H
> > *Subject:* Re: [wix-users] Issues with Component with Auto
> Generated GUID
> >
> > Component GUID auto generation should be stable, meaning the same
> GUID
> > should be generated, if the keypath is "stable". Without stability,
> then
> > auto generation wouldn't work properly in upgrades.
> >
> > You are in a bad place. The decision on whether the non-keypath
> resources
> > are installed or not depends on whether the keypath resource has a
> newer
> > version and will get installed. *All* decisions are made based on
> the
> > keypath. The only way to avoid overwriting the config is to not
> update
> the
> > keypath (presumably the exe) which kind of defeats the upgrade...
> >
> > Chris provided one possible way to avoid this kind of problem in
> the
> > future. His suggestion is accepted as best practice by setup
> experts.
> >
> > On how dig yourself out of your current predicament... You'll need
> to get
> > creative.
> >
> > First, I'd advocate for best practices and work toward changing the
> > application so that the installer installs (and manages) a
> "template"
> > config and the application is responsible for creating an instance
> of the
> > config (in %ProgramData% since %ProgramFiles% is supposed to be
> read-only)
> > that which can be modified by sysadmins. The application will also
> need
> to
> > be responsible for migrating data. In other words, if a schema
> change
> > occurs between version 1 and version 3 of the config, then the
> application
> > will need to have a mechanism for applying those changes (diff)
> without
> > loosing user settings.
> >
> > Second, (this is where creativity comes into play) you'll need to
> > transition the current installation into one where resources appear
> in
> the
> > correct components. You might still decide to keep the exe and the
> template
> > config in the same component since the schema of the template
> config,
> > presumably, doesn't change without a change to the exe. Perhaps you
> decide
> > that having exe and config in separate components makes more sense.
> In
> any
> > case, if you decide to change the current 4-file component in
> anyway,
> then
> > you'll need to ensure the new components have different GUIDs *AND*
> you
> > *MUST* use a MarjorUpgrade scheduled afterInstallInitialize. That
> means
> the
> > new component for the original keypath *must* have a different GUID
> which
> > will probably need to be hard-coded as opposed to auto-generated
> since
> the
> > auto-generation would likely still produce the same GUID. The
> specifics
> > here will depend on your strategy and you're strategy will depend
> on how
> > you are able to change the application *and* installer.
> >
> > If your efforts to improve (correct really) the application design
> fails,
> > then your only option left might be to write custom actions to
> > 1. backup current config
> > 2. allow installer to overwrite current config
> > 3. migrate user data from backup config to real config
> >
> > Of course, you'll need to take rollback in to account (that means
> some
> > combination of install rollback, uninstall rollback, repair
> rollback,
> > upgrade rollback) as well and how all of these custom actions need
> to be
> > conditioned appropriately to make sure they run at the appropriate
> times.
> >
> > Note, the code for migrating user data gets written (slightly
> differently)
> > regardless of whether the application does this or whether the
> installer
> > does this. The execution environment for MSI installers is limited
> so you
> > really don't want this code in the installer simply because the
> developers
> > were ignorant of the need for that functionality in the application
> itself.
> >
> > <rant audience="universe">
> > Setup development really *must* be a conversation with application
> > development. Generally speaking application developers (or product
> owners)
> > do not have enough understanding of setup concerns to make good
> decisions
> > on their own. In my opinion, it is the responsibility of setup
> developers
> > to educate and guide application developers (and product owners) in
> the
> > same way that QA professionals have a responsibility to educate and
> guide
> > application developers (and product owners) in how to bake in
> testability
> > and quality rather than trying to bolt it on after the fact.
> > </rant>
> >
> > --
> > Edwin G. Castro
> >
> >
> > On Fri, Mar 23, 2018 at 9:54 AM, Ven H via wix-users <
> > wix-users at lists.wixtoolset.org> wrote:
> >
> > Thanks a lot for the details, Chris. But unfortunately, this is the
> current
> > state of affairs. So, it would be really great, if you could please
> let
> me
> > know if there is any way to achieve what I am looking for.
> >
> > Regards,
> > Venkatesh
> >
> > On Fri, Mar 23, 2018 at 7:31 PM, Christopher Painter <
> chrpai at iswix.com>
> > wrote:
> >
> > > Having multiple files in a single component isn't an automatic
> component
> > > rule violation. However grouping an .exe and .exe.config in one
> > component
> > > may or may not give you the desired file overwriting behavior as
> the
> > > decision will be based on the keyfile which presumably is
> the .exe
> file.
> > >
> > > https://msdn.microsoft.com/en-us/library/windows/desktop/
> >
> > Develop Windows desktop apps – Windows app development
> > <https://msdn.microsoft.com/en-us/library/windows/desktop/>
> > msdn.microsoft.com
> > Find resources to develop for the Windows desktop such as APIs and
> samples.
> >
> >
> >
> > > aa370561(v=vs.85).aspx
> > >
> > > For config files, I prefer to have one file that is "owned' by
> the
> > > installer (stock can always overwrite and will never contain user
> data )
> > > and one file created by the application that contains the user
> data.
> > The
> > > installer can't harm what it doesn't know about. If you are
> coding in
> > > .NET, the framework has a pattern to easily support this. The
> main
> > > config file can reference the custom (override) config file and
> > seamlessly
> > > apply the settings if they are found.
> > >
> > > https://msdn.microsoft.com/en-us/library/aa903313(v=vs.71).aspx
> > >
> > > appsettings at file attribute
> > >
> > > https://docs.microsoft.com/en-us/dotnet/framework/data/
> >
> > <https://docs.microsoft.com/en-us/dotnet/framework/data/>
> > Data and Modeling in the .NET Framework | Microsoft Docs
> > <https://docs.microsoft.com/en-us/dotnet/framework/data/>
> > docs.microsoft.com
> > Note. The feedback system for this content will be changing soon.
> Old
> > comments will not be carried over. If content within a comment
> thread is
> > important to you ...
> >
> >
> >
> > > adonet/connection-strings-and-configuration-files
> > >
> > > connectionstring at configsource attribute
> > >
> > >
> > > -----Original Message-----
> > > From: wix-users [mailto:wix-users-bounces at lists.wixtoolset.org]
> On
> > Behalf
> > > Of Ven H via wix-users
> > > Sent: Friday, March 23, 2018 6:40 AM
> > > To: WiX Toolset Users Mailing List <
> wix-users at lists.wixtoolset.org>
> > > Cc: Ven H <venh.123 at gmail.com>
> > > Subject: [wix-users] Issues with Component with Auto Generated
> GUID
> > >
> > > I have an MSI which has a component with 4 files (agreed that
> this
> > > violates component rules. But my client was unaware of the best
> practices
> > > and had implemented it in that way some time ago). They have also
> > > configured auto generated ID (*) for the Component GUID (again
> this may
> > not
> > > be the best thing to do, but they have done it).
> > >
> > > Of the 4 files, one will be a config file. So, once it is
> installed at
> > > their end customer, their end customer can manually modify this
> config
> to
> > > suit to their environment. Now we are working on an Upgrade. In
> this,
> > they
> > > don't want to touch the already installed config file at the
> target
> even
> > > though it is modified in the MSI, but other modified files should
> get
> > > updated / overwritten.
> > >
> > > So, I suggested them to include a MajorUpgrade element with
> > > Schedule="afterInstallExecute". But even with this, the config
> file
> also
> > > seems to be getting overwritten with the installation of the
> upgrade
> MSI,
> > > probably because the Component GUID is auto generated (*) all the
> time.
> > In
> > > fact, I tried it out in a sample and could observe that if the
> component
> > > GUID is different, no files are getting installed during upgrade,
> > although
> > > this is strange.
> > >
> > > If I keep the Component GUID constant, then I believe it will
> work as
> > > expected. But, is it possible to achieve this requirement with an
> auto
> > > generated Component GUID everytime? Please suggest if there is a
> good
> > > solution / workaround.
> > >
> > >
> ____________________________________________________________________
> > > WiX Toolset Users Mailing List provided by FireGiant
> > > http://www.firegiant.com/
> >
> > WiX Support | WiX Experts and Resources from FireGiant
> > <http://www.firegiant.com/>
> > www.firegiant.com
> > WiX Support | Installation, Development, Deployment | WiX Experts
> and
> > Resources from FireGiant
> >
> >
> >
> > >
> >
> >
> ____________________________________________________________________
> > WiX Toolset Users Mailing List provided by FireGiant
> > http://www.firegiant.com/
> >
> > WiX Support | WiX Experts and Resources from FireGiant
> > <http://www.firegiant.com/>
> > www.firegiant.com
> > WiX Support | Installation, Development, Deployment | WiX Experts
> and
> > Resources from FireGiant
> >
> >
> >
> >
> >
>
> ____________________________________________________________________
> WiX Toolset Users Mailing List provided by FireGiant
> http://www.firegiant.com/
>
>
More information about the wix-users
mailing list