Help Me Understand FeatureCompareSizeRequired Behavior

[kaneohe]

Project Type: InstallScript

We are trying to develop an InstallScript-based project that can run on both a workstation and a server. The feature tree of the workstation is nothing more than a subset of the server. As such, when we go into workstation mode, we want to hide and disable several features. We are calling FeatureSetData() to successfully hide and disable the server-only features but I'm not entirely convinced this is everything that is required. We have some components going into TARGETDIR and other components going into TARGETWWW. The TARGETWWW components are all supposed to be disabled on the workstation. I have verified that none of the TARGETWWW components are in the workstation-applicable feature tree because they've been hidden and disabled with the FeatureSetData() calls (sample shown, there are more in our project).

FeatureSetData( MEDIA, "WebSoftware\\Feature1", FEATURE_FIELD_SELECTED, FALSE, szData );
FeatureSetData( MEDIA, "WebSoftware", FEATURE_FIELD_SELECTED, FALSE, szData );
FeatureSetData( MEDIA, "WebSoftware", FEATURE_FIELD_VISIBLE, FALSE, szData );

These FeatureSetData() calls are initiated prior to showing the Welcome dialog on the workstation install. If we then choose "Complete Installation" we get an error dialog while doing the FeatureCompareSizeRequired() unless we explicitly call the following FeatureSetTarget(). When we choose "Custom Installation" the workstation installation always works as expected. The "if" condition is commented out so the installer will run correctly on workstation installs. The server installation always works as expected.

//	if ( nInstallMode = MODE_SERVER ) then
		FeatureSetTarget( MEDIA, "", szWWWPath );
//	endif;

The hidden and disabled features are not script-created. They are created in the IDE. We have zero script-created features in our project.

This seems very counter-intuitive to call FeatureSetTarget() for components that have already been forcibly disabled and hidden from the end-user. This also seems like it could severely skew the results since our workstation installation requires only about 100MB of space while our server installation requires nearly 1GB.

Is there something that we're missing or is this the expected behavior? If this is expected how do we ensure that the TARGETWWW components are not being included in the overall disk space availability checks on workstations?

[kaneohe]

After a lengthy session of "trial by fire" with FeatureCompareSizeRequired() I've discovered the following conditions must be met for this function to succeed:

1. Every component must have a valid Destination (, etc.) set.
2. The Destination must be set even if the component belongs only to a Feature that has been forcibly disabled by FeatureSetData() prior to FeatureCompareSizeRequired().
3. The Destination, say , must include a drive letter. "\Some\Path" does not work, regardless of the source location of setup.exe (desktop, network), despite being a valid Windows path.
4. The Destination does not need to exist at the time FeatureCompareSizeRequired() is called.

We were using IISROOTFOLDER as the base path to some of the server-only components but InstallShield provides a default IISROOTFOLDER path of "\" if IIS is not installed. ExistsDir() returns success when it is given "\" as the input path. Using IISROOTFOLDER works great on our server installation as IIS is already validated by other means but on the workstation installation IIS is expected to not be installed (but is fine if it is installed). The default value provided by InstallShield actually gets in the way more than it helps when IIS is not installed (though I understand why it is set to "\").

Conclusion
The "not enough space" error message returned from FeatureCompareSizeRequired() is vague and misleading: worthless. The documentation on this function is vague and virtually worthless as anything more than an API reference.

One painful day doing battle with InstallShield has finally come to a close...