[wix-users] IIS App Pool Settings not retained during Major Upgrade

[Ronny Eriksson]

I do not know why it changes but what I would say is that it is good if you need to do important changes like changing the .NET version on the AppPool since the application might not work without it.
I see what you mean that you might not wait to change the small changes like the IdleTimeout.
Maybe you should just put in a condition to say that you don't what the AppPool to be created/changed if your application already is installed.
That way the custom changes will stay and if there is any special changes you NEED to get in in a upgrade then put in it and just prompt in the installation that it might have overwritten the AppPool and you need to check custom changes.

From my experience as a technical consultant working with customers IT department for 15-20 years, lost count by now... 😊, is that IT wants control over their things and the changes they done in most cases.
So eider letting them know that the AppPool has changed during the update/upgrade, and that they will have to check it, or not changing it during updates/upgrades, and manually doing the change after the update/upgrade, is the best practice.

It's not always the best way to do EVERYTHING in the installation package, sometimes is letting the one that does the install know what to do or what to check for is the better way.

Ronny Eriksson 

-----Original Message-----
From: wix-users <wix-users-bounces at lists.wixtoolset.org> On Behalf Of Ven H via wix-users
Sent: Thursday, 27 September 2018 19:02
To: Edwin Castro <egcastr at gmail.com>
Cc: Ven H <venh.123 at gmail.com>; WiX Toolset Users Mailing List <wix-users at lists.wixtoolset.org>
Subject: Re: [wix-users] IIS App Pool Settings not retained during Major Upgrade

Thanks a lot for your prompt reply, Edwin. That was just for a sample. I am not using any Custom Action. What I meant was, if I set a value during install and then manually change them after install and then run upgrade, the manually set values get replaced.


On Thu, Sep 27, 2018 at 10:15 PM Edwin Castro <egcastr at gmail.com> wrote:

> Do you get the same behavior if you change Schedule to 
> afterInstallInitialize?
>
> Does your IdleTimeout and ManagedRuntimeVersion modification custom 
> actions run during upgrades?
>
> The first thing I'd try to figure out is whether 
> RemoveExistingProducts is changing something after your modification custom actions run.
>
> ... wait ...
>
> I just looked at your iis:WebAppPool and it has IdleTimeout="0" and 
> ManagedRuntimeVersion="v4.0". I assumed you were modifying those in 
> custom actions because iis:WebAppPool didn't let you configure them. 
> Why not just use IdleTimeout="5" (or whatever value is appropriate for 
> 5 minutes) and ManagedRuntimeVersion="v2.0"?
>
> --
> Edwin G. Castro
>
>
> On Thu, Sep 27, 2018 at 9:13 AM Ven H via wix-users < 
> wix-users at lists.wixtoolset.org> wrote:
>
>> I have the following App Pool element in my wxs file.
>>
>> <iis:WebAppPool Id="MyDefaultPool" Name="My Default Pool"
>> ManagedPipelineMode="Classic" IdleTimeout="0" MaxWorkerProcesses="1"
>> ManagedRuntimeVersion="v4.0"  PrivateMemory="1800000" />
>>
>> This creates the app pool as expected when the MSI is installed. 
>> After that, I manually modify some settings like IdleTimeout to 5 
>> minutes and ManagedRuntimeVersion to v2.0.
>>
>> I have a MajorUpgrade element with Schedule="afterInstallExecute". 
>> After I run a major upgrade with the same wxs file with the same 
>> settings for web app pool as given above, my manual changes get 
>> replaced. Is there a way to retain the manually made changes? Please help.
>>
>> ____________________________________________________________________
>> WiX Toolset Users Mailing List provided by FireGiant 
>> http://www.firegiant.com/
>>
>

____________________________________________________________________
WiX Toolset Users Mailing List provided by FireGiant http://www.firegiant.com/