[wix-users] Issues with Component with Auto Generated GUID
Jamie Ooms
jamie at 2imagine.com
Mon Mar 26 05:25:41 PDT 2018
-----Original Message-----
From: wix-users <wix-users-bounces at lists.wixtoolset.org> On Behalf Of harald goci via wix-users
Sent: maandag 26 maart 2018 13:29
To: Ven H <venh.123 at gmail.com>
Cc: harald goci <harald.goci at panagenda.com>; wix-users <wix-users-bounces at lists.wixtoolset.org>; WiX Toolset Users Mailing List <wix-users at lists.wixtoolset.org>
Subject: Re: [wix-users] Issues with Component with Auto Generated GUID
Well then, ...
Have a look at these:
https://www.firegiant.com/wix/tutorial/events-and-actions/
http://wixtoolset.org/documentation/manual/v3/customactions/
I think you can realize what you want (backup/restore) with the standard custom action "Quiet execution":
http://wixtoolset.org/documentation/manual/v3/customactions/qtexec.html
With it you can execute any command line command the computer is capable of.
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: pic10805.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: pic00148.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: Christopher Painter <chrpai at iswix.com>, WiX Toolset Users
Mailing List <wix-users at lists.wixtoolset.org>, wix-users
<wix-users-bounces at lists.wixtoolset.org>
Date: 26.03.2018 13:18
Subject: Re: [wix-users] Issues with Component with Auto Generated GUID
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/
____________________________________________________________________
WiX Toolset Users Mailing List provided by FireGiant http://www.firegiant.com/
More information about the wix-users
mailing list