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

Fri Mar 23 10:48:15 PDT 2018

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<mailto: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<mailto: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/_themes/docs.theme/master/en-us/_themes/images/microsoft-header.png]<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<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<mailto:wix-users at lists.wixtoolset.org>>
> Cc: Ven H <venh.123 at gmail.com<mailto: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