Reputation: 43
I faced with the problem in my WIX installer: how can I stop specific IIS application pool during repair, change or update? Description: Deliver and deploy Web Application, run repair. Dialog appears that says that w3wp process locks files. In addition, because of requirements I cannot just hide that message and I cannot change Web Application.
What I tried to do:
Please, help me overcome this issue.
Upvotes: 1
Views: 1356
Reputation: 46
If you have .Net core IIS application this solution might be for you.
I tried the solution you mentioned with IIS service as ServiceControl and MSIRESTARTMANAGERCONTROL but none of it worked. I tried Christopher Painter solution but I didn't want FilesInUse window popping up. More on that in second solution.
I've spend a lot of time to figure out how to stop an IIS app pool but this was a wrong approach. I should have checked how to stop IIS app (especially ASP .net core IIS app). .Net framework IIS applications do not lock files - wix installer can do whatever it wants with them (especially remove them) so the FilesInUse window does not show up. ASP .Net core IIS service does lock files and the FilesInUse will pop up. To unlock them you have to either stop IIS app pool (requires elevated rights which is very complicated, will come back to it later) or creating a file named "app_offline.htm" in the .net core webservice directory - this stops the service and unlocks the files.
"app_offline.htm" solution - I just created a custom action that creates a file in a specific directory before InstallValidate and another one that removes that file before RemoveFolders. Here is more info about "app_offline.htm" file: https://learn.microsoft.com/en-us/aspnet/core/host-and-deploy/app-offline?view=aspnetcore-8.0
Second solution is to stop the iis app pool with custom action with elevated rights. Basically you cannot run an elevated command before InstallValidate step (during or just after this step the FilesInUse window pops up). Either you will have immediate action which cannot be elevated (Indicates that the custom action will run during normal processing time with user privileges.) or you will have deferred custom action ( Indicates that the custom action runs in-script (possibly with elevated privileges).) + impersonate: 'no' (elevated rights) which... cannot be run before InstallInitialize which is after InstallValidate. https://wixtoolset.org/docs/v3/xsd/wix/customaction/ What you can do is run the action with user rights but make sure the user has elevated rights. You can check it on the validation step before the installation begins. This kind of sucks because the user might have to run cmd with admin rights and then invoke msi from there. Another option is to create a wix bootstrapper (.exe) that will run the msi that is probably inside the exe. I didn't check that solution since it didn't make sense for me, but you should be able to find more about this solution easily. And the last option - you can create self elevated msi (by restarting msi with elevated rights using custom action). http://lists.wixtoolset.org/pipermail/wix-users-wixtoolset.org/2016-September/003259.html but it is not advised and it has it's own problems. For both self elevated msi and bootstrapper if you/users of the installer use any parameters for the msi - you will have to forward them when restarting application or inside the bootstrapper. For me this was the last resort. I tried the self elevated msi and it was working, but then I found out the first solution (after a lot of searching already) and this is a much cleaner option.
Upvotes: 0
Reputation: 43
First of all, please accept my great thanks!
As I understand, there are just two options to overcome the issue:
I guess to use options 2 due to the requirements. BUT, as I think, the best solution would be to say that after InstallValidate validator should just ignore some kind of processes filtering them by the name.
Upvotes: 0
Reputation: 55581
You can use quiet execute custom action to shell out to appcmd to stop an app pool. You are right though, you wouldn't always be elevated prior to InstallValidate.
https://technet.microsoft.com/en-us/library/cc732742(v=ws.10).aspx
I suspect this is probably a false alarm and will resolve itself later in the installer. I would look at the various was to suppress this dialog. Maybe this would help:
WiX: Avoid showing files-in-use dialog and just prompt for reboot at end of install
Upvotes: 1