WiX installer installs silverlight web application. It can work under 32 or 64 bit app pool. But when installation completed I see that selected app pool always set to Enable 32-bit applications.It is even for 64-bit pools. It is not sutiable because it can change existing pool for previously installed 64 applications.
I do not change explicitely this parameter. What is the reason of problem may be?
The code sample added:
<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>
This had been designed in a very elegant way, in my opinion.
If you place the <iis:WebAppPool> element declaration to the <Component> marked as Win64="yes", the application pool will be created with Enable32bit flag set to false. Otherwise (that is, by default), it will be created with Enable32bit set to true.
I'm not sure how it will behave when you don't create the application pool with your installation, but reference the existing one instead. I would expect it not to change this flag at all. You can experiment with this to find out how it works exactly.
And a side note: I would avoid installing to the existing application pool or website. This is far more difficult to maintain - remember that you must leave the machine in its "pre-install" state after uninstallation. This means you'll have to maintain backup/restore the state of everything you change with custom actions... Brrr...
Related
I have IIS 7.5 and I have installed the Application Initialization Module for it. Now, I am trying to change the StartMode of an application pool, but do not see the StartMode option in the IIS Manager. I have looked under Basic and Advanced Settings. I am thinking that the next place to edit this value would be in the Machine.Config. So, I have found that file, but I am unsure where the update would be placed in there. I believe it should be set to AlwaysRunning.
Any help would be appreciated.
I found the Configuration Editor under the Management section of the IIS manager.
EDIT: startMode is in section system.applicationHost/applicationPools under applicationPoolDefaults. It can also be configured on a per-item basis in Application Pools - Advanced Settings.
In this entry http://developers.de/blogs/damir_dobric/archive/2009/10/11/iis-7-5-and-always-running-web-applications.aspx i found the answer.
To setup the pool set the attribute startMode to AlwaysRunning of the IIS config file C:\Windows\System32\inetsrv\config\applicationHost.config:
<applicationPools>
<add name="MyAppWorkerProcess" managedRuntimeVersion="v4.0" startMode="AlwaysRunning" />
</applicationPools>
And you need implements others things to reach that your App always running
If you like to have a UI, look at this link
https://blogs.msdn.microsoft.com/amol/2013/01/25/application-initialization-ui-for-iis-7-5/
and download the "ApplicationInitializationInstaller_x64.zip".
after install you find a new icon on the iis-manager (on the server-element).
I have a WiX installer that supports major upgrades. I found that in some specific test environments, the installer on upgrade would remove existing unchanged components.
These (IIS web app pool, IIS website, etc.) components are installed in this way, under TARGETDIR:
<Directory Id="TARGETDIR" Name="SourceDir">
<Component Id="myComponent" Guid="MY-GUID">
<iis:WebAppPool Id="ID" Name="MyWebAppPool" Identity="networkService" ManagedPipelineMode="classic" ManagedRuntimeVersion="v4.0"/>
</Component>
</Directory>
For the problem environments, the app pool is deleted on upgrade.
Upgrades are authored in this way:
<MajorUpgrade Schedule="afterInstallExecute" DowngradeErrorMessage="A later version of [ProductName] is already installed. Setup will now exit." AllowDowngrades ="no" />
In upgrade logs, I see these entries:
MSI (s) (58:20) [11:22:58:433]: Allowing uninstallation of shared
component: {MY-GUID}. Other clients
exist, but installed to a different location
In environments where the problem is not seen (ie. the components are not uninstalled on upgrade), I see these log entries:
MSI12cb8.LOG:9594:MSI (s) (10:EC) [09:36:37:068]: Disallowing
uninstallation of component: {MY-GUID}
since another client exists
The only explanation I've been able to come up with is that for the problem environments, TARGETDIR changes between the initial install and the upgrade. According to Rob, TARGETDIR is set to the largest drive. If the largest drive (drive with most free space available?) on a system changes between initial install and upgrade, the keypath of the components will change causing the components to be uninstalled on upgrade.
Questions
Does this explanation sound correct?
How can I fix this for upgrades to existing product installations? Is there a way to set TARGETDIR on upgrade to the same value used for initial install?
What's happening appears to be this: Your upgrade installs to some TARGETDIR that you seem to be saying you have little control over. At the end of that upgrade, RemoveExistingProducts uninstalls the old product, and that includes removing the app pool because the component is being uninstalled, presumably with a custom action (because there is no native support for app pools). Removing the component from the old location is fine because it's no longer needed there, but it looks like the custom action that removes the app pool is tied to that component removal and therefore deletes the app pool. In other words you have tied your app pool to the component sharing rules that now require you to do an in-place upgrade. Another way of looking at it is that in situations like these people add a "AND NOT UPGRADINGPRODUCTCODE" to the uninstall condition on the CA that removes the app pool so that it doesn't delete the app pool on an upgrade because it may just have been created in a new location, as in your case.
That's rather long winded, sorry, but the requirement for an in-place upgrade is usually met by having something on the system that you can search for (such a registry entry) and set the install folder to that location, disallowing any UI that can change it. You should also start getting control over your install folders (you make it sound like your install could go literally anywhere). The key word here is "default". TARGETDIR will default somewhere if you can't be botherd to set it.
For anyone else who stumbles upon a similar problem, I worked around it using a custom action. As #PhilDW pointed out, NOT UGPRADINGPRODUCTCODE will not work for the existing install. I couldn't figure out a way to stop the app pool deletion on upgrade. Instead, I added a custom action scheduled for after removal that adds the app pool back, if it was deleted.
<CustomAction Id="CreateAppPoolCustomAction.SetProperty" Return="check" Property="CreateAppPoolCustomAction" Value="AppPoolName=$(var.AppPoolName)" />
<CustomAction Id="CreateAppPoolCustomAction" BinaryKey="MyCustomActions.CA.dll" DllEntry="CreateAppPoolCustomAction" Execute="deferred" Return="check" Impersonate="no" />
<InstallExecuteSequence>
<Custom Action="CreateAppPoolCustomAction.SetProperty" Before="CreateAppPoolCustomAction" />
<Custom Action="CreateAppPoolCustomAction" After="RemoveExistingProducts">WIX_UPGRADE_DETECTED AND NOT (REMOVE="ALL")</Custom>
</InstallExecuteSequence>
The C# custom action in MyCustomActions.dll usesMicrosoft.Web.Administration.ServerManager to create the application pool, if it's missing.
I am trying to use Enterprise Web Library with Windows Azure. It appears that the web.config file for the EWL project works fine locally, but when I deploy to Azure the application cannot initialize. After logging in and viewing the site locally on Azure, it appears there are several web.config elements EWL requires that are locked on Azure. I've had to edit the following in order to have the application initialize on Azure:
Remove <serverRuntime uploadReadAheadSize="8388608" />.
Remove everything nested inside of the modules element.
The application seems to run fine on Azure after removing these parts.
The Web.config elements you removed are important to ensure that EWL works properly: uploadReadAheadSize fixes a problem with client certificate authentication, and using <clear/> in the <modules> section makes the behavior of EWL applications consistent across different servers by keeping the same set of modules in the pipeline regardless of what IIS features are installed on the machine.
There has to be a way to unlock these config sections in an Azure web role. Assuming they are locked in the web role's applicationHost.config file, maybe you can modify this file using a startup script as described in this answer: https://stackoverflow.com/a/10140024/35349.
I am not very familiar with Enterprise Library. If William’s suggestions do not help, please check your web.config to see if you’re missing any configuration sections. On your local machine, when you install Enterprise Library, it may modify machine.config to add certain configurations. But they may not exist in the cloud. So please search your local machine.config to see if there’re any Enterprise Library specific sections, and then add them to your web.config.
Best Regards,
Ming Xu.
I try to create installer, where web site is creates too.
I use the following code
....
<DirectoryRef Id="WEBFOLDER">
<Component Id="WebLibraries" Guid="77532F98-BF0B-4b9d-98AF-15618691A090" KeyPath="yes">
<iis:WebSite Id="DefaultWebSite" Description="Default Web Site" Directory="WEBFOLDER">
<iis:WebAddress Id="AllUnassigned" Port="80" />
</iis:WebSite>
</Component>
</DirectoryRef>
....
<Feature Id="WebSite" Level="1" Title="Web site">
<ComponentRef Id="WebLibraries" />
</Feature>
....
but when i try to install a created package on machine where iis is not installed, i have got this message even i don't check this feature:
cannot connect to internet information server
Can anybody help me with this trouble?
Thanks in advance.
You're installing your package on a machine where IIS is not installed. What would you expect? :)
To be serious, the WiX IIsExtension (the one which defines WebSite element) uses the API of IIS component to actually do its job. For WiX v3.0 it even requires IIS 6 compatibility to be turned ON in IIS 7 in order to work correctly.
Your component, which contains WebSite element, is not conditioned. this means it will always be installed. When it is installed, the IIsExtension tries to create a website defined in it (if we tell this story short).
So, I would recommend you to do the following (if you wish just skip the IIS part of your installer on target machines like that):
add a launch condition to check if the IIS component is installed (you can rely on IISMAJORVERSION property defined by IIsExtension itself)
condition your component (or feature) which is dependent on IIS with "NOT IISMAJORVERSION" condition
As a result, when IISMAJORVERSION property is not set (IIS is not installed), your component will not be scheduled for install and the IIS custom actions won't run.
P.S. The SKIPCONFIGUREIIS property I initially meant is "all-or-nothing" switch, and is not an appropriate tool for your case.
I have WIX installers for two windows services. Both are installed using the same credentials, but one works while the other fails with the error "Service "PCP Event Processor-3.9.9.0-wix' (MyServiceExeName) could not be installed. Verify that you have sufficient privileges to install system services.". I use a common wxi file for both projects with the credentials to use, so it's not an account name or domain name typo AFAICS. The only substantial differences between the two services being installed are:
The failing project has a .licx file for the 3rd party component.
the failing project is a WinExe project. The successful install is an Exe (Console style app)
As far as I can see, there is no real difference (obviously GUIDs are different) between the wxs files for the two installers. The failing component has WIX installer code like this:
<Component Id="cmpMainExe" Guid="{EXCISED-FOR-CUT-N-PASTERS}">
<File Id="filASJHDJSDJSHGDJH" Source="$(var.EventPollingService.TargetDir)\EventPollingService.exe" />
<ServiceInstall Name="$(var.SVCNAME)-$(var.ProductVersion)-$(var.BranchName)"
DisplayName="PCP $(var.SVCNAME)-$(var.ProductVersion)-$(var.BranchName)"
Type="ownProcess"
Interactive="no"
Start="auto"
Vital="yes"
ErrorControl="normal"
Description="Manages the state model of a user's session by handling incoming events from the dialler"
Account="$(var.ServiceAccountId)"
Password="$(var.ServiceAccountPwd)" />
<ServiceControl Id="StartWixServiceInstaller"
Name="$(var.SVCNAME)-$(var.ProductVersion)-$(var.BranchName)"
Start="install"
Wait="yes" />
<ServiceControl Id="StopWixServiceInstaller"
Name="$(var.SVCNAME)-$(var.ProductVersion)-$(var.BranchName)"
Stop="both" Wait="yes"
Remove="uninstall" />
</Component>
I'm using Wix 3.5 with Votive in VS 2010, and both projects are .NET 3.5 SP1 apps. I'm using Windows 7, with UAC turned off.
Any ideas?
Look at the two build MSI's in ORCA from Windows SDK and verify the ServiceInstall table entries look the same.
However, in my experience, this is not likely to be an installer issue. This is usually a red herring that points to an application problem such as missing dependencies or application exception. After you rule out the ServiceInstall entries and verify that the service account credentials are correct, the account is not disabled and the account has the authority to logon as a service then start profiling your application. This is easiest to do right when the installer is hung at the error window.
Two last thoughts:
If a program has dependencies on the winsxs or GAC it won't work as these don't get installed until Commit execution which is after trying to start the service
If you need to grant the user LogonAsService rights look at the User element in WiX.