[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