Files-In-Use checking picks up files that correctly handled by the uninstall

[wixbot]

Hi, The new WIX 3.10 feature that checks for files that are in use while uninstalling is a great new feature, one we wish to take full advantage of.

However, we have found an issue with the current implementation which means we can not use it :-(
[ The fact we can't switch it off currently is a whole other story, for which I've raised issue http://wixtoolset.org/issues/4916/ ]

For our product, we have a Windows service that needs to be running the for the life of the product/install. We create and start the service as part of the install, using the standard WIX function. This same functionality also handles the stopping and removal of our Windows service upon uninstall. This functionality is in one of four msi's that make up our product installation, all wrapped up by a standard burn bootstrapper exe.

The issue is that the files-in-use check flags up our Windows service exe file, which is off course running and in-use, durring the uninstall sequence. As far as I can workout, there is no way to tell the files-in-use check to ignore files that are going to be handled correctly by the installer during the uninstall.

At the very minimum, there needs to be a way of setting some sort of exclusion list for the files-in-use checking algorithm.
A more generic solution would understand that some product files are allowed to be in-use at the beginning of uninstall because the installer logic already deals with those files correctly - as in the case with Windows services.

Regards, Antony

Originally opened by antfurnwix

[wixbot]

WixStdBA is just showing what MSI sends for files-in-use messages. Do you have ServiceControl authored correctly? Do you get in-use messages in an .msi not in a bundle?

We'll open the feature for whitelisting.

Area changed from burn to extensions
Release changed from v3.10 to v4.x
Type changed from Bug to Feature

[wixbot]

Do you have ServiceControl authored correctly?
AFAIK we've done this correctly, this is how we've coded it in our msi package:

`

    <ServiceInstall Id="InstallMasterService"
                    Start="auto"
                    Name="IntegrationBusMasterService_$(var.VRMFdots)"
                    DisplayName="$(var.ProdServerName) MasterService"
                    Description="$(var.ProdServerName) MasterService"
                    ErrorControl="ignore"
                    Type="ownProcess">

      <util:ServiceConfig FirstFailureActionType="restart"
                        SecondFailureActionType="restart"
                        ThirdFailureActionType="restart"
                        RestartServiceDelayInSeconds="5"
                        ResetPeriodInDays="1" />
    </ServiceInstall>

    <ServiceControl Id="StartMasterService" Name="IntegrationBusMasterService_$(var.VRMFdots)" Start="install" Wait="no" />
    <ServiceControl Id="StopMasterService"  Name="IntegrationBusMasterService_$(var.VRMFdots)" Stop="both" Wait="yes" Remove="uninstall" />

  </Component>`

The service is stopped/removed and the exe file delete successfully by the uninstall process.

Thanks, Antony

Originally posted by antfurnwix

[dallmair]

Oh yes, I tripped into this as well this week and spent almost a full day reading docs and checking out samples. In the end, the solution is 🥁 to reorder the ServiceControl elements!

The following does not work, as reported by antfurnwix, i.e. one sees the dreaded Files-In-Use dialog:

        <ServiceControl Id="scStart" Name="$(ServiceName)" Start="install" Wait="no" />
        <ServiceControl Id="scStop" Name="$(ServiceName)" Stop="both" Remove="uninstall" />

Whereas it works fine after simply swapping the lines, i.e. MSI detects the situation correctly and does not show the Files-In-Use dialog:

        <ServiceControl Id="scStop" Name="$(ServiceName)" Stop="both" Remove="uninstall" />
        <ServiceControl Id="scStart" Name="$(ServiceName)" Start="install" Wait="no" />

It seems to me that MSI internally just checks the Stop value in the first row it finds for the respective service, and it does not check all rows.

As this also affects standard MSIs and is not related to the bootstrapper application at all, I think the label WixStdBA should be removed from this issue.

Can think of the following possible approaches to address it:

1. Emit the rows into the ServiceControl table in different order.
2. Emit a warning when this situation is detected.
3. Add a note to the docs.

Your call, @rseanhall and friends 😉

[dallmair]

With new information available -- time to take another look @robmen @barnson ?

[robmen]

Note: We'll triage it but if no one is willing to pick it up and do the work, it's likely to just go back 'up for grabs'.

[dallmair]

Makes sense. Especially with "up for grabs", some pointer or hint on how you'd want it to be addressed would be nice.

[barnson]

If it's really ordering of ServiceControl rows, then it's not WixStdBA. @dallmair, can you open a new issue?

[dallmair]

@barnson Fully agree that it's not WixStdBA, see my earlier comment:

As this also affects standard MSIs and is not related to the bootstrapper application at all, I think the label WixStdBA should be removed from this issue.

In fact, the original report did not even mention WixStdBA, the bug/behavior just surfaced there it seems. So the label is assigned incorrectly and should be removed. Not sure a new issue really helps?

[barnson]

@dallmair - are you interested in working on this issue? We think it would be straightforward to order ServiceControl rows in CreateIdtFileCommand and a runtime test could prove the behavior.

[dallmair]

Always up for a new challenge, but cannot promise any specific time commitment.

Hmm, CreateIdtFileCommand seems very low-level and late in the pipeline to me. Are you sure that is the right point to plug this in? How about a new step in BindDatabaseCommand.Execute() named -- let's say -- OrderServiceControlCommand that effectively does this (modulo validation, table existence check, etc.):

var table = Data.Tables["ServiceControl"];
var rows = table.Rows.ToList();
rows.Sort(new ServiceControlRowComparer());

table.Rows.Clear();
foreach (var row in rows)
{
    table.Rows.Add(row);
}

This just reorders the rows in the IR, and keeps all references intact (no duplication of table or row instances).

The foreach loop to add the rows back is not ideal and an AddRange would be better here, but Table.Rows is just an IList<Row> and there is no AddRange on that. As the ServiceControl table does not contain 100s or 1000s of rows it should be fine, though.

[barnson]

No time commitment needed; we're all volunteers.

Late in the pipeline is a goal, as without any kind of column to control ordering, there are no guarantees. That said, inside CreateWindowsInstallerDataFromIRCommand is probably a good spot, as that controls the order that row objects are created. Sorting could be before the symbols are converted or in a new "finalizer" method at the end of AddSectionToData. Do you agree?

[robmen]

FYI: Starting a PR with a test demonstrating the end goal can be incredibly useful. It can get everyone on the same page, and as the ball is already rolling towards an agreed-upon solution, it makes it a lot easier to help with the final bit of code.

[robmen]

PS: @dallmair thanks for being willing to look at this. This isn't a fix that would probably bubble up high on our list for a long time.