问题
I have two features:
<Feature Id='BaseProductFeatures' Title='Feature 1' Level='1'>
<ComponentRef Id='WebAppVDirComponent'/>
<ComponentRef Id='someVDirComponent'/>
<ComponentRef Id='anotherWCFVDirComponent'/>
<ComponentGroupRef Id='group_IMPORTFOLDERFILES'/>
<ComponentGroupRef Id='group_WINSERVERFILES'/>
</Feature>
<Feature Id='SMSGWFeature' Title='Feature 2' Level='2'>
<ComponentGroupRef Id='group_SMSGWWEBAPPFILES'/>
</Feature>
Before the install, I change the INSTALLLEVEL to 2 using a Custom Action:
[CustomAction]
public static ActionResult ChangeInstallLevel(Session session) {
session["INSTALLLEVEL"] = "2";
return ActionResult.Success;
}
The value gets set, but Feature 2 (SMSGWFeature) does not get installed. Why is that? I don't see any of the Components in the ComponentGroupRef, group_SMSGWWEBAPPFILES, get installed in the directory I would expect to see them in. But the installer will work if I set the Level of Feature 2 (SMSGWFeature) to 1.
回答1:
Make sure that your custom action is executed before InstallValidate action in InstallExecuteSequence. Setting INSTALLLEVEL after InstallValidate doesn't affect anything.
Also, a verbose installation log greatly helps in determining if and why a feature or component is not installed. Simply search for InstallValidate in the log and check the feature and component states and install actions.
回答2:
Well, log files don't say anything and I set the INSTALLLEVEL before InstallValidate (I set it in the user interface before the install). As for overhead, it all happens quickly on this slow machine but then again its a custom action I'm using in the UI on a next button click. But I found out what the issue is and how to work around it.
With reference to this link, it is too late to change the INSTALLLEVEL from the UI because the INSTALLLEVEL is taken into account under the CostFinalize standard action, and the CostFinalize standard action gets executed before I have time to let the user pick his features and call my action. Cosmin, I don't think the INSTALLLEVEL matters before InstallValidate, it seems to be much sooner that it matters, in this case its before CostFinalize that it gets taken into account.
What I had to do was as follows...
I changed my second feature to allow it to be absent:
<Feature Id='BaseProductFeatures' Title='Feature 1' Level='1'>
<ComponentRef Id='WebAppVDirComponent'/>
<ComponentRef Id='someVDirComponent'/>
<ComponentRef Id='anotherWCFVDirComponent'/>
<ComponentGroupRef Id='group_IMPORTFOLDERFILES'/>
<ComponentGroupRef Id='group_WINSERVERFILES'/>
</Feature>
<Feature Id='SMSGWFeature' Title='Feature 2' Level='2' Absent='allow'>
<ComponentGroupRef Id='group_SMSGWWEBAPPFILES'/>
</Feature>
I changed my custom action to either enable or disable the feature:
foreach (FeatureInfo aFeature in session.Features) {
if (session["INSTALLSMSGATEWAYSERVICE"] == "" && aFeature.Name == "SMSGWFeature") {
aFeature.RequestState = Microsoft.Deployment.WindowsInstaller.InstallState.Absent;
}
else if (session["INSTALLSMSGATEWAYSERVICE"] == "1" && aFeature.Name == "SMSGWFeature") {
aFeature.RequestState = Microsoft.Deployment.WindowsInstaller.InstallState.Local;
}
}
来源:https://stackoverflow.com/questions/8451515/installlevel-doesnt-install-a-feature