How to do command line builds?

[dhoffer]

How are you suppose to do command line builds with Dev 8?

They have a StandAloneBuild setup but it has no documentation. It doesn't seem to work (without Dev8) because it knows nothing about my Dev 8 app settings like where my merge modules are? What about my lanugage packs...will it find these?

When I use the normal IsCmdBld.exe...it seems to use Dev7 settings, such as .NET redistributables.

How is this suppose to work?

[Art Middlekauff]

1. The documentation for the Standalone Build is included in the help library that is installed with the product. From the IDE, bring up the help library, and look for the topic "Standalone Build".

2. The Standalone Build does not look at any registry entries. If you install it on a machine with the Developer 8 IDE, the Standalone Build will not use the merge module search path that you set in Tools | Options. Instead, the Standalone Build uses the command-line argument -o <merge module search path> to set the merge module path.

3. The language packs are necessary to create your project from the IDE. However, the language packs do not need to be installed on the machine that has the Standalone Build.

4. IsCmdBld.exe is the normal command-line build that works the same way as found in previous versions of Developer. IsSaBld.exe is tne command-line build that is installed by the Standalone Build.

For more details on all the above comments, see the help library.

[dhoffer]

Thank you very much for this information.

So then, what are the relative benefits of using each of the methods (command line builds)? I.e. which build method do you recomend users using?

-dh

[Art Middlekauff]

So then, what are the relative benefits of using each of the methods (command line builds)? I.e. which build method do you recomend users using?

If you have a regularly-scheduled automated build (such as a nightly build) then the Standalone Build offers several benefits:

- It is quick and easy to install to your build machine. You can use the MSI provided with Developer 8, or alternatively, you can just xcopy the files over. Similarly, it is easy to remove from your build machine.

- It keeps your build machine "clean". The Standalone Build does not require any registry entries. It does not install any files to common locations such as system32.

- It provides control from the command-line. Since the merge module search path is set on the command-line, you can have each project use a different merge module path if desired.

- It can be installed side-by-side with other versions. Future versions of the Standalone Build will all be able to coexist on the same machine (even across service packs). So one build machine could build different projects using different versions of Developer.

- It has a generous license agreement. If you have a license to InstallShield Developer, then you may install, reproduce, and use the Standalone Build on up to ten (10) computers residing on your premises.

If, on the other hand, you don't have a build machine, and you always build from the same machine on which you use the IDE, you may be content with the traditional IsCmdBld.exe option.

[RobertS]

The standalone build utility looks very good, but why can't I install it on < Win2K? Our build machines are still running WinNT.

Bob.

[Art Middlekauff]

The Standalone Build has three requirements that are not met by Windows NT4:

1. Windows Installer must be present.

2. The Standalone Build uses shlwapi.dll version 4.71 or later. The official mechanism from Microsoft to get this DLL on NT4 is through IE4.

3. See later post on this thread.

You can easily bypass the launch condition on the Standalone Build MSI by doing an administrative install and then using xcopy to copy the files to your build machine.

[dhoffer]

...the StandaloneBuild looks good but seems a bit rough in places. For example the dotNet path in the ini file does not work. It must be a subdirectory of the SA install. In addition, the structure of the dotNet redist is different than in Dev8. Plus several DLL files needed (when using dll custom actions) during builds are not in the correct location (but this was true in Dev7 also).

[Art Middlekauff]

Thank you for your feedback.


Originally posted by dhoffer
For example the dotNet path in the ini file does not work. It must be a subdirectory of the SA install.

The DotNetPath option in the INI file (-t on the command-line) is used to specify the location of the .NET framework installed on the build machine, not the location of the .NET framework redist. This setting is necessary so the build can locate the version of RegAsm.exe (etc.) that you want the build to use. This path does not need to be a subdirectory of the SA install.


In addition, the structure of the dotNet redist is different than in Dev8.

This is by design to compact the SA build as much as possible. In many cases the entire SA build can be located in a single directory on your build machine. So the English .NET redist should be placed in the SA build folder. The .NET redist for other languages are placed in subfolders by language ID.


Plus several DLL files needed (when using dll custom actions) during builds are not in the correct location (but this was true in Dev7 also).

I would like to investigate this further. Can you provide any additional details?

[dhoffer]

I will try, but I cannot be certain of all of them.

For sure...one file that it wanted was isLookup.dll and it had to be placed in a System subfolder, as this folder did not yet exist.

One other file might have been dllWrap.dll but I am not sure. I had very similar problems with Dev7 regarding this issue.

Regarding the DotNetRedist issue. I do not really understand your point about compactness. It is very noble of you to have all of StandaloneBuild in one folder, with no other dependancies, however I do not see why subfolders in here would be a problem, i.e. it is just as easy to copy, etc. It is rather a pain to get all the redist in the proper place once in Dev7 (since you don't provide them all), and it would be nice to be able to just copy this folder over to SA.

In addition it would be nice to just be able to specify the root of the redist & merge module folders. It is a real pain to have to specify each language folder.

[Art Middlekauff]

Thank you for the extra information. DLLWrap.dll should have been included in the Standalone Build. The bug # for this is 1-BCB5V. Fortunately, the simple workaround is to copy the file to the build machine.

Regarding IsLookup.dll, I am not sure what is looking for that file. Please send me a private message if you would like to help me track down the problem.

[Art Middlekauff]

Update: To use the Standalone Build on NT4, you also need these files:

ATL.dll (v. 3.0)
msvcrt.dll (v. 6.0)
mfc42.dll (v. 6.0)

You can copy these files manually to the Standalone Build folder.

See my eariler post on this thread for other info on NT4.

[daleqq]

My problem with IsSaBld.exe is that I ALWAYS get an ERRORLEVEL of 0, even if the build fails.

I've also found out that IsCmdBld.exe (from ISD 7.04) always returns an ERRORLEVEL of 0 if the -x (abort on first error) switch is used.

I tried not using the -x switch with IsSaBld.exe, but to no avail.

I'm using the evaluation version of ISD8.

Can someone please tell me I'm doing something wrong?:)

Thanks,
Dale