Project Type: Basic MSI Our installer deploys a DLL file on initial install and everything looks good and works fine. During a major upgrade, the previous installation gets uninstalled (per the major upgrade settings) and the new one gets installed. The new installation looks complete except there is one missing DLL. Here's what I've looked at thus far (to no avail): [LIST=1] The DLL is included and the version has not changed between packages Looked at the MSI log file (I see nothing obvious, some log entries shown below) Compared the MSI log data with a similar DLL that is not problematic, nothing notably different Checked PendingFileRenameOperations and rebooted the machine Component "Destination" has not changed Component Code has not changed RemoveFile table has no entry for this DLL There are no Script CustomActions that manage files There are three references to this DLL in the registry and they are all managed by the MSI engine during assembly publishing There are about 20 references to this DLL in the log. Here are the last references to it (very near the bottom of the log file): [CODE]MSI (s) (78:14) [14:41:02:591]: Executing op: AssemblyPublish(Feature=FeatureA,Component={1E1C2982-B23F-459A-8E53-E9DF27900B80},AssemblyType=3,AppCtx=C:\Program Files (x86)\Product\Bin\FileName.dll,AssemblyName=FileName,Version="1.0.2634.25925",PublicKeyToken="B7CA6C66E8031842",Culture="neutral",FileVersion="1.0.2634.25925",ProcessorArchitecture="MSIL",) MsiPublishAssemblies: Application Context:C:|Program Files (x86)|Product|Bin|FileName.dll, Assembly Name:FileName,Version="1.0.2634.25925",PublicKeyToken="B7CA6C66E8031842",Culture="neutral",FileVersion="1.0.2634.25925",ProcessorArchitecture="MSIL" MSI (s) (78:14) [14:41:02:591]: Note: 1: 1402 2: UNKNOWN\Installer\Assemblies\C:|Program Files (x86)|Product|Bin|FileName.dll 3: 2 [/CODE] What else might account for the DLL not being installed during the upgrade? ... View more

Project Type: InstallScript In the IDE we can create/edit registry string values. I can use [TARGETDIR] to get the full path to the installation folder. Is there an equivalent for getting the Product Version (as found on the General Information pane) or am I stuck only creating/updating the version in the registry via InstallScript functions? ... View more

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? ... View more

Project Type: InstallScript, 2012 Premiere I'm working on a prototype installer that will be running on two different types of machines and the installer needs to behave very differently on each machine type. One is a server-oriented environment and the other is a workstation-oriented environment. The workstation is nothing more than a subset of the server environment. Here is a feature tree that we would like to use: Desktop Software +- Feature 1 +- Feature 2 Web Software +- Feature 3 +- Feature 4 "Desktop Software" is a parent feature and "Feature 1" is a child. "Feature 1" should be hidden and deselected for workstation installs unless a particular condition occurs. I cannot figure out how to hide a child feature. If I use the identical script logic and move this feature up (making it a sibling of "Desktop Software") the hiding functionality (FeatureSetData) works as expected. Is this just how InstallShield works or is there some way to dynamically hide a child feature at run-time? ... View more

Project Type: InstallScript Our product needs to have files deployed into two separate folders that will not have any parent/child relation. One of them I'm happy to use TARGETDIR. How would I go about setting the destination for the other set of features/components? For example: Feature1/Component1 - TARGETDIR, C:\Program Files\My Company\My Product Feature2/Component2 - WWWDIR, C:\inetpub\wwwroot\MyWebSite How would I go about doing this in the script code? I can manage the UI elements easily enough. ... View more

Our product needs to deliver a web site that contains a very high number of files (over 11,000 without the help files, which adds another 20,000+ files, generated). We currently use an InstallScript MSI project but we're moving toward a Basic MSI for the future. The only reasonable way I could find so far of delivering the web content is through a Dynamic File Link which necessitates that each and every build is a major upgrade, not to mention the key file problems. If any of the web content gets removed or renamed from one build to the next, the minor upgrade scenario goes out the window. This is far from ideal, on many levels. We are running new builds every other day and the major upgrade takes a substantial amount of time to deploy. Can anyone give me any ideas for how we could approach redesigning how we deliver the web content from one build to the next in such a way that we could deliver it as a minor upgrade? I'm open to almost any ideas. ... View more