Superfreak3 asked a question.
32 & 64 Bit Installs Combined
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!!
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.
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?
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.
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?
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?
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!!
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.
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!!