[wix-users] Issues with Component with Auto Generated GUID

Mon Mar 26 03:33:32 PDT 2018

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