[wix-users] Installation damaged by Windows update

[Helge Kruse]

I managed to discover what is missing after the Windows update. The
MSI installation package includes a Windows Script Component. The .WSC
file remains in place but the registration is removed from the
registry. The registry content is:

[HKEY_CLASSES_ROOT\CLSID\{2CC0D042-48FB-49E4-8282-33378FC9939B}]
@="FileDistributor"

[HKEY_CLASSES_ROOT\CLSID\{2CC0D042-48FB-49E4-8282-33378FC9939B}\InprocServer32]
@="C:\\WINDOWS\\system32\\scrobj.dll"
"ThreadingModel"="Apartment"

[HKEY_CLASSES_ROOT\CLSID\{2CC0D042-48FB-49E4-8282-33378FC9939B}\ProgID]
@="FileDistributor.WSC.1.07.05"

[HKEY_CLASSES_ROOT\CLSID\{2CC0D042-48FB-49E4-8282-33378FC9939B}\ScriptletURL]
@="file:///C:\\Program
Files\\ACME\\ProductManagement\\FileDistributor\\FileDistributor.wsc"

[HKEY_CLASSES_ROOT\CLSID\{2CC0D042-48FB-49E4-8282-33378FC9939B}\VersionIndependentProgID]
@="FileDistributor.WSC"

[HKEY_CLASSES_ROOT\FileDistributor.WSC]
@="FileDistributor"

[HKEY_CLASSES_ROOT\FileDistributor.WSC\CLSID]
@="{2CC0D042-48FB-49E4-8282-33378FC9939B}"

[HKEY_CLASSES_ROOT\FileDistributor.WSC.1.07.05]
@="FileDistributor"

[HKEY_CLASSES_ROOT\FileDistributor.WSC.1.07.05\CLSID]
@="{2CC0D042-48FB-49E4-8282-33378FC9939B}"

--- end of registry file ---

It is sufficient to merge the .REG file with the content shown above
the get a fixed installation. The corresponding WiX source file is
here:

<?xml version="1.0" encoding="utf-8"?>
<?define Files=$(env.BUILD_DIR)\ACME\ProductManagement\FileDistributor\Bin ?>

<Wix xmlns="http://schemas.microsoft.com/wix/2006/wi">
    <Fragment>
        <DirectoryRef Id="INSTALLFOLDER">
            <Directory Id="dirAA861FA303A866510F2EC3CF6CEB37EC" Name="Bin" />
        </DirectoryRef>
    </Fragment>
    <Fragment>
        <ComponentGroup Id="FileDistributorImport">
            <Component Id="cmp2A74C0C3EAF7154C5C6D1D2F0950CCFD"
Directory="INSTALLFOLDER"
Guid="{2A941B8C-94CA-4222-A20A-6CA857FBBEDD}" KeyPath="yes">
                <Class Id="{2CC0D042-48FB-49E4-8282-33378FC9939B}"
Context="InprocServer32" Description="FileDistributor"
ThreadingModel="apartment"
ForeignServer="[SystemFolder]scrobj.dll">
                    <ProgId Id="FileDistributor.WSC.1.07.05" />
                </Class>
<File Id="filCC015C7F59538A50D6D42818BAC4260A"
Source="$(var.Files)\FileDistributor.wsc" />
<RegistryValue Root="HKCR" Type="string" Action="write"
Key="CLSID\{2CC0D042-48FB-49E4-8282-33378FC9939B}\ScriptletURL"
Value="file:///[#filCC015C7F59538A50D6D42818BAC4260A]" />
<RegistryValue Root="HKCR" Type="string" Action="write"
Key="CLSID\{2CC0D042-48FB-49E4-8282-33378FC9939B}\VersionIndependentProgID"
Value="FileDistributor.WSC" />
<RegistryValue Root="HKCR" Type="string" Action="write"
Key="FileDistributor.WSC" Value="FileDistributor" />
<RegistryValue Root="HKCR" Type="string" Action="write"
Key="FileDistributor.WSC\CLSID"
Value="{2CC0D042-48FB-49E4-8282-33378FC9939B}" />
            </Component>
        </ComponentGroup>
    </Fragment>
</Wix>

The WSC files was first registered and the change in the registry
saved in a REG file. The WiX fragment was generated from the REG file.

The ComponentGroup is referenced in the single Feature in the Product
in the source file. All other component (groups) in the same (single!)
feature remain intact.

What might be wrong with that fragment?

Best regards,
Helge

Am Di., 25. Dez. 2018 um 19:42 Uhr schrieb Christopher Painter
<chrpai at iswix.com>:
>
>
> There are a number of system/registry snapshotting tools that will compare the state of the system before and after running an install.   You have to filter for white noise as windows  has a lot of moving parts but with an expert eye you can almost always identify what the relevant change was.
>
> ________________________________
> From: wix-users <wix-users-bounces at lists.wixtoolset.org> on behalf of Helge Kruse via wix-users <wix-users at lists.wixtoolset.org>
> Sent: Tuesday, December 25, 2018 3:02 AM
> To: WiX Users
> Cc: Helge Kruse
> Subject: [wix-users] Installation damaged by Windows update
>
> Hi,
>
> I have a bundle with two MSI packages, one for 32 and one for 64 bit.
> Each MSI package contains a COM component implemented with a WSC script
> hosted by scrobj.dll as interface. The WSC component calls a .NET
> implementation.
>
> The .NET components are compiled for ANY CPU. So they are executable for
> 32 and 64 bit. Therefore both MSI packages contain the same files. But
> the COM registration requires two different MSI. As the result the
> components can be used from any Windows Scripting Host script,
> independent of the current active CPU mode.
>
> The installer works, updates are working since years. But there is a
> problem with Windows updates. After installation of the Windows updates,
> the COM instantiation doesn't work anymore. A "repair" installation
> fixes the problem. As long as I use the COM components in house, this is
> nasty. But when passing the components to customers it's a shame.
>
> How can a identify what's damaged by the Windows installer, i.e. what is
> actually repaired by the repair operation? I hope I get an idea from the
> information for a change of the installer.
>
> Well, I compared the files in the install location as well as the
> registry content I am aware of before and after Windows update. I didn't
> found any difference.
>
> Best Regards,
> Helge
>
> ____________________________________________________________________
> WiX Toolset Users Mailing List provided by FireGiant http://www.firegiant.com/



-- 
PGP Fingerprint: EDCE F8C8 B727 6CC5 7006  05C1 BD3F EADC 8922 1F61