3 replies to this topic

[Doug Paida]

Has anyone run into the following problem using isolated components?   I have a DLL that comes in two versions - one ANSI and one Unicode.  I have 2 components defined in the Component table in order to deliver the correct one based on the target operating system (I use the Version9X condition for the ANSI component, and the VersionNT condition for the Unicode component).    I noticed that the ANSI version of the file was installed when I ran the install on a Windows 2000 PC.  When I checked the log file, I noticed under the section where it does the FileCopy actions that Windows Installer attempted to copy both files, instead of just the Unicode one (the Unicode one failed because the NeverOverwrite attribute is set on the component, so just the ANSI one was actually copied).   When I repeated this process on a PC that did not support isolated components, the log file indicated that the installer only attempted to copy the ANSI file (the correct version).   Does anyone know why the component condition would have been ignored in the first scenario?   In general, what would cause Windows Installer not to evaluate the condition on a component?   Thank you for your help.

[Doug Paida]

Here is some additional information.  The following lines appear in the log file during InstallValidate for the two components I mention in my first posting:

MSI © (47:C3): Component: Global_VC_ATLANSI.7EBEDD68_AA66_11D2_B980_006097C4DE24; Installed: Absent;   Request: Local;   Action: Null

MSI © (47:C3): Component: Global_VC_ATLUnicode.7EBEDD68_AA66_11D2_B980_006097C4DE24; Installed: Absent;   Request: Local;   Action: Null

It appears as though Windows Installer is saying that no action is to be taken on either of these components, which would seem to indicate they would be left in the "Absent" state.  However, as I said, later on a FileCopy is attempted on both of these.   Does this seem inconsistent?

[hteichert]

I think you missunderstood the concept of isolated components. Isolated component means that different versions of a DLL are installed on the same PC and every App uses it's own version of this DLL (or the shared one, if no "own" is installed). This concept only works on Win98 SE, Win ME, Win2K and Win XP.
You are trying to install one version of a DLL on an ANSI version of Windows (9x and ME) and another version on the Unicode versions of Windows (NT, 2K, XP). That simply works with a condition on the components (Version9X for ANSI; VersionNT for Unicode) - and it works without problems. But it's important to set the "Reevaluate Condition" to Yes because after an update of the OS (from 98 to 2K for example) the ANSI version has to be removed and replaced by the Unicode version.

But:
You don't install an own component. You are using the ATL.MSM to install atl.dll. First of all, this MSM has a lot of problems (see ATL Merge Module Fails to Register). But more important: as far as I know ATL.DLL is under the SFP mechanism of Win 2K - it can only be updated by OS updates (Service Packs) on Win 2K.

If you really want ATL.DLL to be installed as isolated component especially for your App you cannot use MS's ATL.MSM. You have to build your own components.
But don't ask me if it works with ATL .......

[Doug Paida]

Thanks for your reply.  I think there may be some confusion, though.  I wasn't using isolated components in order to deliver the two separate versions of the DLL.   This was something we had in place well before the latest version of our application, which now happens to have a dependency on ATL.  I just saw support of isolated components as the common thread among the machines on which the incorrect version of the file was being delivered.   Plus, what I then saw in the log files I compiled seemed to confirm this suspicion.   I still think there is a problem somewhere, because it does work (as you said) by placing the conditions on the components - but only on OS's where the component is not being isolated.

I did see the bug alerts on ATL.MSM, and we are definitely using the latest version (VS6 SP5), in which these have supposedly been fixed.