Suite Project on a 64-Bit Xeon Processor

[gridman]

I have the Premier version.

I have a Basic MSI project where I can build both 32-bit and 64-bit releases. To build the 32-bit release, I set the Template Summary property to Intel;1033. To build the 64-bit release, I set the property to x64;1033.

If I take those two releases and build a Suite Package installation, and then run it on my Xeon six-core processor, the Suite package will install to Program Files (x86) rather than Program Files, which is where I told it to go to in the installer. If I run the 64-bit installer by itself, outside of the Suite installer, it will install to Program Files like it should.

Is x64 not the proper setting for a Xeon processor?

[MichaelU]

Hi Gridman, you win the dubious prize of locating a case sensitivity bug in our product. As your reward, I can give you an issue tracking number (see below). On the bright side, there are two ways you can work around this particular problem.

Method 1: our code currently looks for X64 instead of x64. If it's easy to change the template summary of your .msi file to upper case, doing that and then rebuilding the suite make this work automatically. Don't do this - I had forgotten that Windows Installer doesn't like X64 in place of x64.

Method 2: if it's not safe for you to modify the .msi at this point in your cycle, you can make a slight manual modification to your .issuite project file. It's hard for me to recommend this as if the package ever is not for x64 platforms, you may encounter problems without any indication in the IDE why you are seeing them. That said, it's a trivial change:

• Close your project (back it up if it's complicated), and open it in your XML or text editor of choice.
  
• Locate the element in your .issuite that corresponds to your 64-bit package.
  
• Add an attribute to this element: Platform="x64"
  
• Save, then rebuild the Suite project.
  

Your prize: IOA-000065478 is tracking this issue. You can search for it in release notes to see when it has been addressed. In the meantime I hope one of the above workarounds satisfies your needs. Let me know if it doesn't.

[gridman]

MichaelU,

You are my hero. I've been cracking my skull trying to figure this one out.

Using X64 will work for me. I'll give it a test and get back to you.

Thanks again.

Rod

[gridman]

I need some more information.

For suggestion 1, I went back to the 32-bit/64-bit project, set the Template Summary to X64 and I get a build error, "Intel64 or AMD64 must be specified in the template of the Summary Stream". Well, I noticed it built anyway, so I ignored the error and ran the 64-bit build on a 64-bit Win 7 machine. Got a different error, "This installation package is not supported by this processor type."

I looked at Suggestion 2 and opened the Suite project in an XML editor. I could not find any elements. I have EXEs as packages in this Suite project. So, I am unclear on where to add the attribute you spoke of.

Can you give me more detailed information? Thanks.

[MichaelU]

Interesting. You still win the dubious prize of having uncovered the behavior I talked about earlier, but it turns out your scenario is not the one I though it was. If you are launching a setup.exe file from an exe package, the latter workaround doesn't apply, and the former won't matter - it was only required for the 64-bit msi package case.

So what exactly are you launching for both the working and failing scenarios? I misread your first post to suggest it was a msi package instead of an exe package (which happens to launch a msi package).

[gridman]

I have an IS 2012 project where I can build 32-bit and 64-bit releases, just by setting the Template Summary property and building the corresponding 32-bit or 64-bit Single Exe release. To build the 64-bit release, I set Template Summary to x64;1033, select the 64-bit Single Exe release and build it. When I install the 64-bit release on a Win 7 64-bit Xeon, it installs fine to the Program Files folder.

I then take the 32-bit Single Exe and 64-bit Single Exe releases, add them to a Suite project as packages, set the detection and eligibility conditions and all the other stuff, then build it. When I run the Suite installation on the Win 7 64-bit Xeon, it installs to Program Files (x86).

I have looked at the Suite installation log, but really don't see anything unusual except that it says it's going to install to Program Files (x86). That's the problem.

[MichaelU]

Are you certain the correct variant of your package is being installed? I've talked with some others and we can't come up with any explanation for the behavior as you describe it. The Program Files (x86) folder you see mentioned in the /debuglog is likely to be the InstallShield Installation Information folder, which is expected; InstallShield itself uses a 32-bit location to cache its setups.

It might be informative to turn on the MSI logging policy (or MSI 4+ logging property) and see exactly what is happening in the .msi files. Make sure the package you want is the one being installed, and see if or where the folders go wrong. Possibly tweak their names to make it obvious if it is not already.

[gridman]

I have both 32-bit and 64-bit versions of the app. In the 32-bit version of the app, it has the text "32-bit" in the title bar. In the 64-bit version of the app, it has the text "64-bit" in the title bar.

Therefore, when I run the Suite installation on 64-bit, I know the 64-bit version of the app has been installed because I just run the app and see it says "64-bit" in the title bar.

I'm just trying to figure out what's going on here. Trying different angles. If you look up Support Incident #SIOA-000185678, you will find I have an open ticket with David. When you read it, you will see that he ran my 64-bit installer on a 64-bit test machine and it installed to Program Files. He then ran my Suite installer on his test machine, and it also installed to Program Files. So, he can't reproduce my problem.

However, when I run the Suite installer on my 64-bit Xeon Win 7 machine, it installs the 64-bit app to Program Files (x86). That's why I asked you if x64;1033 was correct for a Xeon processor.

When David couldn't reproduce my problem, I thought I would try the InstallShield 2012 forum and see if anyone else had something similar. But, I appear to be the only one.

This machine is a 5 month old Dell T7500 six-core Xeon Workstation with 12 GB running Win 7 64-bit. Since I have mainly used it for testing, there isn't a lot of junk on it. Yes, I have Visual Studio 2008, SQL Server 2008 and some other tools, but that's about it.

There has to be something in the configuration of this machine. That doesn't make me happy because I bought it to test 64-bit installations and do some development later on.

I turned MSI logging on. The log I spoke about is an MSI log. I probably didn't make that clear.

[gridman]

Here's more info.

In answer to the question is my 64-bit app really a 64-bit app? Well, I built it in Visual Studio 2008 and selected the 64-bit build configuration. Also, if I run the 64-bit app on XP Pro 32-bit, it says, "This is not a valid Win32 application". From what I've seen, that's the usual error when trying to run a 64-bit app on 32-bit Windows.

I have to say I am surprised that when I run the Suite installation, and it installs the 64-bit app to Program Files (x86), and the app still runs.

[MichaelU]

Xeon and x64 shouldn't be a problem these days. A few years ago there may have been some Xeon Itanium chips floating around (I sure hope not), but as long as we're talking the non-Itanium variety, x64 should be what you're looking for. In fact, if it were Itanium, it would require Intel or Intel64 and disallow x64.

Unlike a lot of the redirects on 64-bit systems, the program files folders ones are fairly soft and non-restrictive. It's a good policy to put things in the right place, but in direct contrast with the system folder, it isn't likely to cause problems if they're not.

Perhaps you could create a sample project, and post its (suite) setup.exe /debuglog, msi log, and even setup.xml (look in the interm folder). That way we can be certain we're debugging the same scenario that you're using.

[gridman]

Michael, here are the files you requested.

There is the InstallShield.log for the bootstrapper. There is also the msi installation log, MSI60B66.LOG.

I could only find Setup_UI.xml in the temporary folder. Is that what you are looling for?

[JohnCresswell]

Thank you for uploading the files. The problem appears to stem from two custom actions that you have in the UI sequence of your MSIs. These actions are used to control INSTALLDIR for the 32 and 64 bit installers (essentially changing ProgramFilesFolder to ProgramFiles64Folder where appropriate). The problem occurs as the MSIs are being run with the /qn switch which prevent these custom actions from running and so INSTALLDIR is left at the default value set. The result being your 64 bit files are installed to the 32 bit Program Files folder.

There are a couple of possible workarounds for this:

- Use the suite command line functionality to pass the value of INSTALLDIR that is required for the 64 bit MSI.
- Have the custom actions be in both UI and Execute sequence and mark them to run only once.

Also, in general we would recommend using MSI packages if the underlying install is a .msi file. So rather than using the setup.exe you would instead just use the msi files. This allows us to peak under the hood a little better so we can set up detect and eligibility conditions for you and also we can hook the progress from the MSI so it can be seen from the suites progress bar. If you have any question or concerns about doing this please let me know and I will happily try to help further.

[gridman]

Thanks for the reply, John. I will change and use MSI files in the Suite package installer.

At one time, I did have the custom actions in both the UI and Execute sequences. However, there was a problem the ones I stuck in the Execute sequence. Don't recall what it was. Possibly where I put it in the sequence.

I will try out both suggestions.

Thanks to the InstallShield staff for the help.

[gridman]

John, I was using the following command line with Setup.exe in the Suite package installation:

/s /v/qn

I was not aware that using the quiet option would cause those custom actions to not run. Can you explain that to me so I know in the future?

[JohnCresswell]

The /qn parameter that you pass to the MSI causes it to run with no UI. As your custom actions are only in the UI sequence they are never encountered and so never run. If you add the custom actions to both sequences but mark them to run only once this should resolve the problem you are seeing.

[gridman]

OK. The part I was missing was because the custom actions were in the UI sequence only. So, what you say makes sense.

I am putting the custom actions in both sequences and also changing from using SETUP.EXEs to MSIs in the packages.

Thanks.