VersionNT64 Condition on Vista 32 Bit...???

[Superfreak3]

I'm once again totally stumped with this one.

We have some files with the same name but dependent on 64 bit or not. So, under our Feature we have conditions (VersionNT64) and NOT (VersionNT64). The files under these conditions that do not share common names install properly based on the target architecture (myfile.dll and myfile_x64.dll for example). Those that do share common names (Company.AutoDAC.Interop.dll for example (on is 32 bit component, the other 64 bit)) seem to always be getting the file under the (VersionNT64) condition even though the OS is Vista 32 bit.

And, to confuse matters more, this appears to be the only platform where this problem occurs.

Does anyone know where I can even begin to look. I should add that all 64 bit files are marked 64-bit components on their details page. Currently this is also being applied as a patch, but again, works under all other OS/architecture combinations -- so I'm told.

I am totally baffled with this one (as is usually the case).

Please help!!

[Superfreak3]

It appears as though its the naming. If we change the name of the 64 bit files to include something like _x64 in the name all is placed as desired.

So it appears that if you two files named the same to be installed conditionally to the same location, the condition is either ignored or not resolved properly.

I would think that would be a Windows Installer bug??

The files also have the same version as well, but I don't know why that would be coming into play in our scenario.

We haven't tried leaving the files with the same name and maybe install the 64 bit files to an x64 folder.

[RobertDickau]

What kind of build is this? If files are uncompressed and both files go to the same destination, the fact that source directories mirror the target directory structure would cause one of the files to overwrite the other at build time. There should be a build warning if this is what's happening.

You can use the component setting "Source Location" to avoid this. (And even if it's not your issue, it's a good idea to set in case a user performs an admin installation to create an uncompressed install image...)

[Superfreak3]

The installation is compressed to an .msi.

The source locations for the file are different.

What we are going to try now is to dump the 64-bit stuff to an alternate location, something like... OurCurrentDirectory_x64.

Will this remedy the problem do you think?

[RobertDickau]

Probably the best way to be sure is to create an MSI log file at run time, and see how conditions are resolving on the different systems. Apart from overwritten-file issues, I'm not sure why changing the target would change what gets installed...

[Superfreak3]

I guess I'll check the log, but still don't understand what might be happening. I'm pulling the source files from two distinct locations to be installed to the same target location conditionally. You're saying the overwrite might occur at install build time?

If that is the case, how can I prevent this from happening? Again, I'm creating an .msi which I'm assuming is compressed as there are no external .cabs, etc.

[RobertDickau]

For an uncompressed build, the overwrite can happen at build time. Say you have two files called sample.dll, one for 32-bit and one for 64-bit systems, with the appropriate one of them to be installed to a system's INSTALLDIR. An uncompressed build would have a source directory Program Files\Sample Co\, and since the build structure mirrors the target structure, the build process would copy one of the sample.dll's to that directory, then copy the other to the same directory, overwriting the first. That's where the Source Location property comes in.

For a compressed build, though, it shouldn't matter, except in the admin-install caution I mentioned.

P.S. The "Installing Files of the Same Name" help topic gives a similar example.

[Superfreak3]

Thanks for all the info.

Changing the destination location for the 64 bit files seemed to solve our problem.