[wix-users] Need Advise on Upgrade

Wed Jan 26 10:09:37 PST 2022

Regarding DLL\EXE file versions, my understanding is the full version is
used to decide whether to replace an existing file. The restriction where
the 4th version component is ignored applies only to an MSI's
ProductVersion. I was assuming the file version of DLL\EXE would be
increased in the newer version of MSIs as well.

The PROGRAMS_ROOT directory must be defined somewhere otherwise the project
won't link. If it is not present in the project source, then it must come
from some wixlib, perhaps included in the Nuget packages? Check project
dependencies and command line args to light.exe for clues.

--
Edwin G. Castro

On Wed, Jan 26, 2022 at 9:56 AM Ven H <venh.123 at gmail.com> wrote:

> Thank you once again Edwin. I did some more troubleshooting. I had the
> following findings. Not sure if this is correct or not.
>
> I tried with RemoveExistingProducts After=InstallFinalize and then it
> seemed like having all files post upgrade. However, I saw that the binaries
> were not actually updated. I did some more digging. Then I saw that the
> version of the DLLs/EXE files installed by the bootstrapper were higher
> than the ones installed by the individual MSIs. This is probably because of
> the fact that the bootstrapper was built by Bamboo and hence it seems to
> have updated DLL/EXE versions also in addition to the MSI versions, whereas
> the individual MSI is built by me from Visual Studio from Bitbucket master
> branch, wherein the assembly versions were still 0.1.0 or something like
> that. The client didn't inform me about this.
>
> With that said, I need one more confirmation. If the bootstrapper installs
> a DLL with version 3.0.0.100 and then I upgrade the same DLL with version
> 3.0.0.300, will it work? I think MSI doesn't consider the 4th part of
> numbering, correct?
>
> I think the version of the individual DLLs or EXEs seems to be the culprit
> here. I am going to discuss that with my client. The existing bootstrapper
> and MSI code are a little complicated, since they have built a WiX
> framework and packaged it as Nuget and are using it in their WiX projects.
> Hence I am not at liberty to change anything in the framework and
> troubleshooting / understanding is becoming very difficult and
> unfortunately, there is no documentation about this.
>
> However, I have one more question. I have a directory structure like below
> in the main file.
>
>  <DirectoryRef Id="PROGRAMS_ROOT">
>       <Directory Id="AGENT" Name="Agent">
>         <Directory Id="SERVICEPATH" Name="Service" >
>         </Directory>
>       </Directory>
>   </DirectoryRef>
>
> In the above structure, the PROGRAMS_ROOT seems to be pointing to the
> Program Files folder (64 bit). Not sure where this is defined.
>
> Although the Agent folder is the direct child of this, it is getting
> installed to C:\Program Files\ORG\Agent, if I don't specify any value for
> the PROGRAMS_ROOT argument.  Not sure where this ORG folder name is coming
> from. Any ideas? Please help.
>
>
>
>
> On Tue, Jan 25, 2022 at 11:20 PM Edwin Castro <egcastr at gmail.com> wrote:
>
>> You may need to share your authoring and verbose logs. The behavior
>> you're describing doesn't make sense. Can you create a minimal repro
>> without intellectual property and company confidential information you can
>> share?
>>
>> --
>> Edwin G. Castro
>>
>>
>> On Tue, Jan 25, 2022 at 4:57 AM Ven H <venh.123 at gmail.com> wrote:
>>
>>> Thank you very much Edwin. I believe I checked the properties and I
>>> haven't missed anything. There is one more strange behavior on this
>>> upgrade. Some files are getting installed properly as part of the upgrade
>>> while some are not. There are no errors in the logs. Not sure about the
>>> reason for this behavior. Has anyone faced this issue?
>>>
>>> Also, there is a top level directory called PROGRAMS_ROOT which points
>>> to C:\Program Files directory. However, it is creating another directory
>>> with the org name. I am unable to trace where it is defined. I searched the
>>> whole wix markup, but couldn't locate it.
>>>
>>>
>>> On Sat, Jan 22, 2022 at 1:36 AM Edwin Castro <egcastr at gmail.com> wrote:
>>>
>>>> It occurs to me that all other things being equal...
>>>>
>>>> The bundle could be setting public properties that are not set when you
>>>> install the unbundled MSI. You may need to check those to make sure
>>>> everything is actually equal between both methods.
>>>>
>>>> --
>>>> Edwin G. Castro
>>>>
>>>>
>>>> On Fri, Jan 21, 2022 at 12:02 PM Edwin Castro <egcastr at gmail.com>
>>>> wrote:
>>>>
>>>>> That depends on whether you are doing a major upgrade and when you
>>>>> schedule RemoveExistingProducts. Assuming your new unbundled MSI is really,
>>>>> just like the bundled one but with a newer ProductVersion and different
>>>>> ProductCode, then I'd expect the same behavior regardless of whether the
>>>>> msi was bundled or not.
>>>>>
>>>>> --
>>>>> Edwin G. Castro
>>>>>
>>>>>
>>>>> On Fri, Jan 21, 2022 at 11:47 AM Ven H <venh.123 at gmail.com> wrote:
>>>>>
>>>>>> Thanks a lot Edwin for the explanation. However, what I observed was
>>>>>> when I was installing/upgrading the new unbundled MSIs, some files were
>>>>>> missing after installing/upgrading with the new unbundled MSIs. Do I need
>>>>>> to increment the versions of the files (in case of dlls / exes) or change
>>>>>> their binaries every time I want to upgrade, to ensure all files get
>>>>>> installed?
>>>>>>
>>>>>>
>>>>>> On Sat, Jan 22, 2022 at 12:35 AM Edwin Castro <egcastr at gmail.com>
>>>>>> wrote:
>>>>>>
>>>>>>> Your new unbundled MSIs should upgrade the MSIs bundled in your
>>>>>>> bootstrapper. I expect that to work normally. Your old bootstrapper will
>>>>>>> still be "installed" and you'll need to tell it to uninstall itself to
>>>>>>> unregister itself. When you do that it will uninstall any bundled MSIs that
>>>>>>> are still installed so you'll want to be careful.
>>>>>>>
>>>>>>> Suppose you have a bundle B that includes MSIs A and C. If you
>>>>>>> upgrade MSI A to MSI A1 but do not also upgrade C to a newer version, then
>>>>>>> B will be installed/registered and C will be installed but MSI A will no
>>>>>>> longer be installed as A1 removed A during upgrade. If you uninstall bundle
>>>>>>> B now, then it will leave MSI A1 installed but will uninstall MSI C. To
>>>>>>> avoid that you'd need to also upgrade MSI C to a newer version. And no
>>>>>>> matter how you go about it, something will need to uninstall bundle B after
>>>>>>> you've upgraded all the new separate MSI.
>>>>>>>
>>>>>>> --
>>>>>>> Edwin G. Castro
>>>>>>>
>>>>>>>
>>>>>>> On Fri, Jan 21, 2022 at 10:20 AM Ven H via wix-users <
>>>>>>> wix-users at lists.wixtoolset.org> wrote:
>>>>>>>
>>>>>>>> Thanks Jim. The bootstrapper will have its own Upgrade and also the
>>>>>>>> MSIs
>>>>>>>> within them will have their own upgrade code. So, when I try to
>>>>>>>> upgrade the
>>>>>>>> Bootstrapper using the individual MSIs, technically it should be
>>>>>>>> treated as
>>>>>>>> an Upgrade itself, right?
>>>>>>>>
>>>>>>>>
>>>>>>>>
>>>>>>>> On Fri, Jan 21, 2022 at 8:23 PM Coryat, Jim via wix-users <
>>>>>>>> wix-users at lists.wixtoolset.org> wrote:
>>>>>>>>
>>>>>>>> > My experience is that you want to target the Upgrade code since
>>>>>>>> that
>>>>>>>> > should be consistent between versions. Also, I have seen the
>>>>>>>> bootstrapper
>>>>>>>> > have a separate ARP entry than that of the actual msi files
>>>>>>>> within the
>>>>>>>> > bootstrapper which made it very confusing.  The msi files would
>>>>>>>> have that
>>>>>>>> > upgrade code within them which would make them a valid target for
>>>>>>>> a
>>>>>>>> > isolated installer (as long as it contained that upgrade code).
>>>>>>>> We ended
>>>>>>>> > up replacing the bootstrapper with a pure Wix installer that does
>>>>>>>> not rely
>>>>>>>> > on .NET so we can make the .NET framework a component of the
>>>>>>>> install
>>>>>>>> > instead of a prerequisite which necessitated the use of the
>>>>>>>> bootstrapper.
>>>>>>>> > Hope this helps.
>>>>>>>> >
>>>>>>>> > Again, nothing beats creating a test environment and
>>>>>>>> experimenting. 😊
>>>>>>>> >
>>>>>>>> > -----Original Message-----
>>>>>>>> > From: wix-users <wix-users-bounces at lists.wixtoolset.org> On
>>>>>>>> Behalf Of Ven
>>>>>>>> > H via wix-users
>>>>>>>> > Sent: Friday, January 21, 2022 6:38 AM
>>>>>>>> > To: WiX Toolset Users Mailing List <
>>>>>>>> wix-users at lists.wixtoolset.org>
>>>>>>>> > Cc: Ven H <venh.123 at gmail.com>
>>>>>>>> > Subject: [wix-users] Need Advise on Upgrade
>>>>>>>> >
>>>>>>>> > IMPORTANT NOTICE - This message sourced from an external mail
>>>>>>>> server
>>>>>>>> > outside of the Company.
>>>>>>>> >
>>>>>>>> > We have existing Bootstrapper installers (exe) which bundle
>>>>>>>> Prerequisites
>>>>>>>> > and custom MSIs. These MSIs handle a lot of functionality like
>>>>>>>> Files,
>>>>>>>> > Windows Service Management, IIS Management, Database management
>>>>>>>> etc. Now,
>>>>>>>> > we are planning to break these Bootstrapper installers and
>>>>>>>> separate out
>>>>>>>> > functionality. But there are many customers who have these
>>>>>>>> bootstrappers
>>>>>>>> > installed. Now, when we try to upgrade their system with the
>>>>>>>> separate MSIs,
>>>>>>>> > will it work?
>>>>>>>> >
>>>>>>>> > Bootstrapper has it's own Product & Upgrade code and so also the
>>>>>>>> MSIs.
>>>>>>>> > Also, for majority of the components, the Guid is auto generated.
>>>>>>>> So, on
>>>>>>>> > systems which are installed with the bootstrapper, can I upgrade
>>>>>>>> them with
>>>>>>>> > the separate MSIs? I tried once and observed that the files
>>>>>>>> installed by
>>>>>>>> > bootstrapper seem to be getting removed. Please advise.
>>>>>>>> >
>>>>>>>> >
>>>>>>>> ____________________________________________________________________
>>>>>>>> > WiX Toolset Users Mailing List provided by FireGiant
>>>>>>>> >
>>>>>>>> https://nam04.safelinks.protection.outlook.com/?url=http%3A%2F%2Fwww.firegiant.com%2F&data=04%7C01%7CJim.Coryat%40softprocorp.com%7C34a75fe7cbb24c208c8608d9dcd290a2%7C8a807b9b02da47f3a903791a42a2285c%7C0%7C0%7C637783619619343905%7CUnknown%7CTWFpbGZsb3d8eyJWIjoiMC4wLjAwMDAiLCJQIjoiV2luMzIiLCJBTiI6Ik1haWwiLCJXVCI6Mn0%3D%7C3000&sdata=23aTLZYYVUB4iE2LIfyvobki%2BLIeEteSgmlphgHSXs8%3D&reserved=0
>>>>>>>> > ________________________________
>>>>>>>> >  NOTICE: The information contained in this message is proprietary
>>>>>>>> and/or
>>>>>>>> > confidential and may be privileged. If you are not the intended
>>>>>>>> recipient
>>>>>>>> > of this communication, you are hereby notified to: (i) delete the
>>>>>>>> message
>>>>>>>> > and all copies; (ii) do not disclose, distribute or use the
>>>>>>>> message in any
>>>>>>>> > manner; and (iii) notify the sender immediately.
>>>>>>>> >
>>>>>>>> >
>>>>>>>> >
>>>>>>>> >
>>>>>>>> ____________________________________________________________________
>>>>>>>> > WiX Toolset Users Mailing List provided by FireGiant
>>>>>>>> > http://www.firegiant.com/
>>>>>>>>
>>>>>>>> ____________________________________________________________________
>>>>>>>> WiX Toolset Users Mailing List provided by FireGiant
>>>>>>>> http://www.firegiant.com/
>>>>>>>
>>>>>>>