cancel
Showing results for 
Show  only  | Search instead for 
Did you mean: 
vrungel
Level 3

Standalone Builder setup questions

I've installed the IS2010 Standalone Builder on one machine using the downloaded setup.exe and now I want to simply copy the IS2010 Standalone executables to another build machine without running the original setup.exe. After I ran the original downloaded setup.exe, I was able to execute iscmdbld.exe on command line which gave me the usage information. However, when I copied the entire IS2010 Standalone installation folder to another build machine, I was not able to execute iscmdbld.exe (no usage information given on command line).

The instructions say that I can copy IS2010 Standalone to another machine, but will have to manually register the merge modules. The required modules are listed on this webpage: http://kb.flexerasoftware.com/selfservice/microsites/search.do?cmd=displayKC&docType=kc&externalId=installshield16helplibsp1-StandAloneBuildhtm&sliceId=&docTypeID=DT_MACROVISIONHELPNET_1_1&dialogID=106597227&stateId=0%200%20106595261. When I installed the IS2010 Standalone Builder using the downloaded setup.exe, I did not find the listed required merge modules (ATL.msm, etc.) in the Modules folder. In fact I only found one file installed in the Modules\i386 folder: InstallShieldTrialware.msm. However, iscmdbld.exe still seemed to work. If these required modules were in fact installed by the setup.exe as the instructions imply, where were they installed? Now, when it comes to the copying of IS2010 Standalone to another build machine, what exactly is the process to getting it to work? I tried to copy all msm files found in the full IS2010 Premier installation, but that didn't help.

Any insight is appreciated.
Labels (1)
0 Kudos
(7) Replies
DebbieL
Level 17

Sorry about the confusion. The Standalone Build installation does not actually transfer the .msm files as .msm files to the build machine. The installation installs the technology that is made available through the required merge modules.

In other words, the Standalone Build installation does not need to install atl.msm. It needs to install and register a file that happens to be called atl.dll, which is included in the ATL 3 merge module.

If you want to try to set up the Standalone Build on a machine without actually running the Standalone Build installation, you need to somehow get these merge modules' technologies on the machine. You can't really "run" a merge module to install and register it files. So, you'd need to find alternate ways of installing the technologies. For example, if Microsoft provides an .exe installation for MSXML 4, you could run that installation on the build machine to get the MSXML 4 files on the machine. Or perhaps you could create a Basic MSI installation that includes all of the required merge modules, and then run that installation before copying over the Standalone Build files.

Most users seem to prefer running the Standalone Build installation, instead of trying to copy all of the files and set up the rest of the requirements. It's much easier.
0 Kudos
vrungel
Level 3

Debbie thanks for your reply! So just to confirm, if run the downloaded setup.exe on the build machine to install IS2010 Standalone Build or manually copy the executables from another machine and then install the required merge modules, the end result will be the same? If that's the case then I don't see any advantage of not using the setup.exe to install IS2010 Standalone.

Also even though I have IS2010 Premier installed on one machine, I never use the GUI and do all builds on command line. Would IS2010 Standalone Build actually provide the same functionality in command line building as IS2010 Premier?

Thanks in advance.
0 Kudos
DebbieL
Level 17

Yes, the results should be the same. Running the Standalone Build's .exe file is recommended, since that is so much easier.

If all that you are doing is setting up a build machine to build releases, the Standalone Build is probably all that you need. I can't think of any differences between building releases with the Standalone Build vs. building them with IntallShield.
0 Kudos
vrungel
Level 3

Debbie, again, thanks for the your response! One last argument we had in favor of copying the IS2010 Standalone executables to other build machines rather than running the setup.exe, was its potential interaction with other versions of InstallShield present on these machines.

From your explanation above and according to documentation I gather that the Standalone version is supposed to be a safe way to set up an IS2010 build environment without causing any disruption and interaction with other builds and versions of InstallShield already present on build machines. Is my understanding correct?

Thanks much!
0 Kudos
DebbieL
Level 17

Yes, different major versions of the Standalone Build can coexist with each other on the same machine. They are all installed to different locations by default. Thus, for example, you can have InstallShield 2011, 2010, and 2009 Standalone Build versions all on the same machine.

Note this from the InstallShield 2010 release notes:
If you want to open an InstallShield 2010 project in InstallShield 2010 SP1, you must allow InstallShield to upgrade your project to InstallShield 2010 SP1. InstallShield 2010 SP1 includes support for tables that were not available in InstallShield 2010 projects, and these tables need to be added during the upgrade. Note that it is not possible to open InstallShield 2010 SP1 projects in earlier versions of InstallShield (including InstallShield 2010 without SP1). Therefore, if multiple users need to open and modify your InstallShield projects, ensure that all of you apply the SP1 patch at the same time.

If you open an InstallShield 2010 project in InstallShield 2010 SP1, InstallShield 2010 SP1 displays a message box that asks you if you want to convert the project to the new version. If you reply that you do want to convert it, InstallShield creates a backup copy of the project before converting it.


Also note that the InstallShield 2010 Standalone Build and the InstallShield 2010 SP1 Standalone Build cannot coexist on the same machine. I'm not sure if you have any combination of InstallShield 2010 and InstallShield 2010 SP1 projects. If you do, you might want to upgrade all of them to InstallShield 2010 SP1, and then use that going forward.
0 Kudos
vrungel
Level 3

DebbieL wrote:
Yes, different major versions of the Standalone Build can coexist with each other on the same machine. They are all installed to different locations by default. Thus, for example, you can have InstallShield 2011, 2010, and 2009 Standalone Build versions all on the same machine.

Also note that the InstallShield 2010 Standalone Build and the InstallShield 2010 SP1 Standalone Build cannot coexist on the same machine. I'm not sure if you have any combination of InstallShield 2010 and InstallShield 2010 SP1 projects. If you do, you might want to upgrade all of them to InstallShield 2010 SP1, and then use that going forward.


I got your point on the coexistence of multiple IS2010 versions though I don't foresee this happening in our environment as there's no need to have multiple instances of the same InstallShield version installed on a single system. We're only now starting to look into InstallShield Standalone Build and all our existing InstallShield installations are full versions (Premier, etc). Any issues with installing IS 2010 Standalone along with other full versions, i.e. ISX, IS12?
0 Kudos
DebbieL
Level 17

Yes, the InstallShield 2010 Standalone Build can coexist with earlier full versions.
0 Kudos