Folder shared with util:FileShare no longer needs to be shared, but upgrading shouldn't remove any existing share

[dahanc]

Hi, my WiX3-based installer created a folder and shared it, something like:

<Component Id="MyFolder_Share" Guid="GUID-HERE" Directory="MyFolder_Dir">
    <CreateFolder>
        <!-- DACL:
            Flags: Auto inherited
            ACE: Allow; This folder, subfolder, and files; SYNCHRONIZE, READ_CONTROL, DELETE, FILE_WRITE_ATTRIBUTES, FILE_READ_ATTRIBUTES,
                 FILE_EXECUTE, FILE_WRITE_EA, FILE_READ_EA, FILE_APPEND_DATA, FILE_WRITE_DATA, FILE_READ_DATA
                 for BUILTIN\Users
            ACE: Allow; This folder, subfolder, and files, inherited; FILE_ALL_ACCESS
                 for SYSTEM
            ACE: Allow; This folder, subfolder, and files, inherited; FILE_ALL_ACCESS
                 for BUILTIN\Administrators
        -->
        <PermissionEx Sddl="D:AI(A;OICI;0x1301bf;;;BU)(A;OICIID;FA;;;SY)(A;OICIID;FA;;;BA)" />
    </CreateFolder>
    <util:FileShare Id="MyFolder" Name="MyFolder" Description="Shared folder">
        <util:FileSharePermission User="MyFolderPermission"
                                  GenericAll="yes"/>
    </util:FileShare>
    <util:User Id="MyFolderPermission" Name="Everyone" CreateUser="no"/>
</Component>

Now, in the next version of my app, I no longer need to share the folder (i.e., a new install of my app on a system that doesn't already have my app should not share the folder). However, if the folder was shared from the previous version, upgrading should not remove the share. I'm doing an MSI major upgrade. What I tried was just removing the util:FileShare and util:User elements, which works for the new install scenario. However, during an upgrade, when the FolderRemove operation is run on MyFolder, it un-shares the folder. How can I accomplish what I'm trying to do?

[chrpai]

Have you tried in the next build marking that component as permanent and then in the next next build removing the component?

[dahanc]

Do you mean marking the component as permanent, while keeping the FileShare element, then after that, removing the FileShare element? (I don't think I want to remove the component itself, because I still need the folder to be created; I just don't need it to be shared anymore) Doesn't that mean a user will have to install the upgrades in sequence, and can't skip one? E.g., maybe it'd work for upgrading current (Permanent no, with FileShare) -> new (Permanent yes, with FileShare) -> new+1 (Permanent ?, no FileShare), but I'm back to the same problem if the user goes from current -> new+1.

It seems like the cause of my problem is that in my existing installer, that component isn't already marked as Permanent, so when the major upgrade uninstalls it, util:FileShare un-shares the directory. I can't retroactively change my existing installer, so I'm looking for a workaround.

[chrpai]

Yes, it gets sticky when a problem is already in prod. How many machines are we tallking about? There are ways of changing an MSI and reinstalling / recaching it to work around issues like this.

Another thought is to keep this component around forever and create a new component without the fileshare. Then use a CompLocator search to set a property saying the original component was found and use a mutually exclusive condition so that MSIs upgrading where the original was found continue to install the original component but MSIs installing or upgrading where the original component was not found install the new component.

I think the heart of the problem is wanting to keep it around but also not create it. That's probably some variant of a component rules violation in that components are supposed to be backwards compatible with previous versions of itself. Hence why to make a new component.

[robmen]

You could try scheduling your major upgrade late (afterInstallExecute or afterInstallFinalize) and remove the FileShare from the Component.

As long as you follow the Component Rules for the other Components properly (except the one where you removed the FileShare), the end result should be that the file share is "leaked" (left behind unreferenced counted). That happens to be what you want in this case.

And, then, take this as a lesson to test your upgrade scenarios before shipping. 😄