32 & 64 Bit Installs Combined

[Superfreak3]

Hi all,

We have an application that will come in both 32 and 64 bit flavors. My question is, using IS 2010, should I create two distinct install packages or can I combine them into one package and condition using VersionNT64 for example?

If one can combine the packages will simply marking a component .dll as 64 bit result in it being registered properly on that architecture?

With our current install (non IS created) we dump some 64 bit files conditionally based on VersionNT64 then register them via Custom Action calling the 64 bit RegAsm. Is this how it has to be done in IS or will it handle the combined package.

Any info or points to it is greatly appreciated.

Thanks!!

[DebbieL]

If you want to be able to install to a 64-bit location, or if you want to mark a DLL component as 64-bit, the Template Summary property of your .msi package has to be something like x64 or Intel64. Once you do that, though, the installation will not run at all on a 32-bit system. This is discussed a bit in the following help topic:
Targeting 64-Bit Operating Systems

I think you'll probably want to check out the following thread:
http://community.flexerasoftware.com/showthread.php?t=189714

It contains some instructions on one way of tackling this sort of project.

I hope that helps.

[Superfreak3]

Currently what we do with our installations that are primarily targeted for 32 bit OSs is that we install some 64 bit components with the VersionNT64 condition. Then, if they need registering we call the 64bit RegAsm.

I'm thinking this may be the way I have to go with InstallShield as well if there really isn't a clear distinction between 32/64 bit as it pertains to our application. In other words, since we don't really have a 64 bit app, but some 64 bit components, we won't be able to mark these components as such because...

If you build a release that has at least one 64-bit component and the Template Summary property is set to a 64-bit value, the result is a 64-bit package.

Or is this just saying that if the template summary property is set to 64 bit, then the result will be a 64 bit package?

Is setting the component to 64 bit really the same or does it do the same thing as adding the VersionNT64 component condition?

Also, if everything else is basically 32 bit and we are able to mark a particular component as 64 bit without the template property set the same way, can we extract com information from the 64 bit components or will that only occur if the template sum. prop. is set to 64 bit?

To sum this all up, we're going to have a few Server app components that are going to be 64 bit. I would like to mark these as such and extract COM info if possible. Otherwise I would just use the VersionNT64 condition on these and call RegAsm via Custom Action on install (and unregister on Remove=ALL).

What are the possibilities?

[DebbieL]

COM extraction will match the architecture of the server being extracted. However, placing it in a 32-bit component will result in it being installed to a 32-bit location on a 64-bit machine even if it is 64-bit information.

With calling Regasm.exe--since it sounds like the file is not installed in a redirected 64-bit location--you should be able to explicitly call the 64-bit one without either disabling redirection or being a 64-bit package (setting the Template Summary property to a 64-bit option). Note the terminology change, though: calling Regasm.exe (like calling /regserver) is self-registration instead of extraction because it goes directly onto the machine at that point.

It seems possible that you may be able to do what you describe with self-registration. VersionNT64 would indeed be the primary property on which to base the condition.

[Superfreak3]

Thanks for the info.

I spoke with one of our developers this morning and we are going to have a distinct 32 and 64 bit server application so I guess I don't have to about this much here.

We do have some Client app pieces that I'll have to deal with in this fashion though.

I thought, from info provided in this thread, that I read that I can create a 32 and 64 bit installation from one package/template. Would that be the way to go for our server app or would it be easier to just create distinct templates one set as 32 and the other as 64 bit?

[DebbieL]

Sorry, I think I'm a little confused on what you are asking.

If you are asking whether you can create a single installation project that will allow you to create a 32-bit installation for 32-bit systems, and will also allow you to create a 64-bit installation for 64-bit systems, yes, you can do that. I think that most people prefer to do that instead of trying to create totally separate installation projects and maintaining both of them. The community forum thread that I referenced earlier has a nice detailed description on this approach.

Does that help?

[Superfreak3]

Yep, that is the answer I was looking for. I'll read through the doc again.

I was just wondering what the template summary property would be set to if using a combined template to generate the two installs, but I guess I'll see from looking.

Thanks for all of the info!!

[DebbieL]

Ah, you can set the Template Summary setting in the General Information view to some default value. Then you can override this in the Releases view; the setting is at the product configuration level, and by default it is blank (that is, the value that's configured in the General Info view is used in the .msi package at build time). Thus, you'd basically be creating separate 32-bit and 64-bit product configurations in the Releases view, and configuring the Template Summary setting for each product configuration as needed.

[Superfreak3]

OK, lets see if I have this straight.

I need to build installations for 32 and 64 bit so I can build from same template by.

Creating Features Server and Server_x64 plus a third feature Common (this is the one where questions come in).

I get it that the Server features will be identical based on component target architecture. Now what I would like to do is have a Common feature as mentioned that would include otheir pieces common to both but not necessarily reliant to 32/64 bit.

Would I just add this feature when configuring the release for both configurations? Based on what template summary is set while configuring, the Common feature would be installed to Program Files or Program Files (x86) accordingly?

I would think my configurations would look like this...

Server
Common
32 bit template summary

Server_x64
Common
64 bit template summary.

Will this work? Or, do I have the basics down?

Thanks for the help.

[DebbieL]

I'm not sure if there are enough details here to know for certain if that'll work. What do you mean when you say, "Based on what template summary is set while configuring, the Common feature would be installed to Program Files or Program Files (x86) accordingly?" Where do you want the Common feature to be installed on 32-bit systems, and where should it be installed on 64-bit systems? For the 64-bit package, is it OK if some of your files are installed to Program Files (x86), but some are installed to Program Files (which is the 64-bit location on 64-bit systems)?

[Superfreak3]

I thought I read somewhere that when you configure a release to build, you can set the template summary property accordingly. The the template summary of the .ism used to create the releases (one template with the identical features -- Sever and Server_x64 -- and the Common feature) is kind of like a default and can be set at release build time if numerous configurations are needed.

What I was thinking would happen is that when configuring the release I would get two installations that would install...

Server and Common installed to Program Files (x86)
Server_x64 and Common installed to Program Files on 64 bit systems.

All this based on how the template summary property was set for the release configuration.

Am I misunderstanding?

Thanks for the help so far if I haven't thanked previously!!

[DebbieL]

I think it may be a little more complicated than that. It may also depend on what you are using for INSTALLDIR and for your component destinations.

To verify this, I just created a quick test project. I set the template summary to x64, created one 64-bit component with one file, and created one 32-bit component with another file. I left default values for INSTALLDIR (so it contained [ProgramFilesFolder]) and the component destinations. When I ran the installation on a 64-bit system, both files were installed to Program Files (x86). When I changed INSTALLDIR to [ProgramFiles64Folder] in my project, both files were installed to Program Files on the 64-bit system.

How are you setting INSTALLDIR and the component destinations in your project?

[Superfreak3]

I'm not setting them at the moment because I haven't really started building the installs yet. I'm on a fact finding mission I guess you could say. I will be starting to construct the acutal installs the week after next.

I thought that if the template summary property was set to 64 bit, the installations would then dump to Program Files on a 64 bit system and (x86) if the summary prop was set to 32 bit.

In addition, I thought you could set a summary property when configuring a release so I could build both from one .ism.

It sounds like I'm misunderstanding, but I thought that is what it mentioned in the link provided earlier in this thread. I'll have another look at that.