WiX: установщик всегда изменяет AppPool, чтобы включить 32-битное приложение

Установщик WiX устанавливает веб-приложение Silverlight. Он может работать в 32- или 64-битном пуле приложений. Но когда установка завершена, я вижу, что для выбранного пула приложений всегда установлено значение «Включить 32-разрядные приложения». Это даже для 64-разрядных пулов. Это не подходит, поскольку может изменить существующий пул для ранее установленных 64 приложений. Я не меняю явно этот параметр. В чем может быть причина проблемы?

Образец кода добавил:

<Component Id="WebAppVDirComponent"
    Guid="C7A4B0E8-2389-4A2A-B285-96960BEE1C52" KeyPath="yes">
    <Condition><![CDATA[RBGROUP_HOSTING = "iis"]]></Condition>
        <iis:WebVirtualDir Id="VDir"
                Alias="[WEB_APP_NAME]"
                Directory="INSTALLDIR"
                WebSite="TheWebSite" >
        <iis:MimeMap Id="SilverlightMimeType" Extension=".xap" Type="application/x-silverlight-app" />
        <iis:WebApplication Id="WorkWebApplication"
                Name="[WEB_APP_NAME]" WebAppPool="TheAppPool"/>
        </iis:WebVirtualDir>
        <iis:WebAppPool Id="TheAppPool" Name="[APP_POOL_NAME]" ></iis:WebAppPool>           
        <CreateFolder/>
</Component>

web-applications iis pool wix
person ZedZip    schedule 27.07.2012    source источник

Ответы (1)


arrow_upward
18
arrow_downward

На мой взгляд, это было сделано очень элегантно.

Если вы поместите объявление элемента <iis:WebAppPool> в элемент <Component>, помеченный как Win64="yes", пул приложений будет создан с флагом Enable32bit, установленным на false. В противном случае (то есть по умолчанию) он будет создан с Enable32bit, установленным на true.

Я не уверен, как он будет себя вести, если вы не создадите пул приложений с вашей установкой, а вместо этого сошлетесь на существующий. Я бы ожидал, что он вообще не изменит этот флаг. Вы можете поэкспериментировать с этим, чтобы узнать, как именно это работает.

И примечание: я бы не стал устанавливать в существующий пул приложений или на веб-сайт. Это гораздо сложнее поддерживать — помните, что после удаления вы должны оставить машину в состоянии «до установки». Это означает, что вам придется поддерживать резервное копирование/восстановление состояния всего, что вы меняете с помощью настраиваемых действий... Бррр...

person Yan Sklyarenko    schedule 27.07.2012
comment
Спасибо, Ян. Хм.... да, это интересно... Я добавил код, который использую. - person ZedZip; 27.07.2012
comment
Таким образом, добавленный вами код создаст пул приложений с Enable32bit, для которого установлено значение «true». Возможно, вы захотите добавить еще один компонент с противоположным условием, то есть с использованием атрибута VersionNT64 и Win64, для которого задано значение yes, и добавить к нему все то же самое. - person Yan Sklyarenko; 28.07.2012
comment
Да, когда я создаю новый пул, проблем нет. Но проблема в том, что пользователь выбирает существующий (64-битный), а затем этот пул меняется на 32-битный. Я использую пользовательские функции .NET для выбора пула. - person ZedZip; 29.07.2012
comment
Как вы справляетесь с ошибкой, когда вас просят изменить ваш каталог на 64-битный каталог, поскольку мне нужно привязать компонент к каталогу, чтобы что-то работало. - person Shawn Mclean; 18.02.2014
comment
Я думаю, что эта ошибка, о которой вы упоминаете, возникает, когда есть аналог 32-битного каталога, верно? Я лично не видел, если честно, но подозреваю, что если каталог находится под wwwroot, то ошибки не будет... - person Yan Sklyarenko; 20.02.2014
comment
Для будущих читателей: мне удалось заставить его работать с (эта подсказка) Win64=yes в компоненте (xml-тег), который обертывает iis: WebAppPool xml .... НО ТАКЖЕ ..... мне пришлось добавить Платформа = x64 в пакете (xml-тег). Я помещу xml ниже. Не уверен, что это будет опубликовано в качестве комментария. ‹Package InstallerVersion=200 Compressed=yes InstallScope=perMachine Platform=x64 /› и ‹Component Id=MyAppPool.Component Guid= KeyPath=yes Win64=yes› ‹iis:WebAppPool (бла-бла-бла) ‹/Component› - person granadaCoder; 02.02.2017