View Full Version : Command Line build creates MSI with most everything missing...

06-13-2006, 07:31 PM
Hello all,
Long time no post.

I've upgraded 2 projects to IS 12 and both work fine within the IDE and build fine. But at the command line, using IsCmdBld.exe, one of the projects goes through the motion of building, showing no errors or warnings, gets to the line where it is building the File table then the next line comes up saying there are no errors or warnings and then ends with a path to the log file. Looking at the Release folder there is only the MSI (no other included files such as the Setup.exe, Setup.ini, etc.) and the MSI is very small. Looking at the MSI, most of the tables are blank with only a few filled out and probably incompletely. The MSI does have the correct output name and the Summary Stream matches the properties from the project. So it would seem that IsCmdBld sees the correct project and can read part of it but beyond that is this mystery of nothing relevant being built.

Besides trying different settings and moving the IsCmdBld parameters around I have also created a new project with a different name, a stripped down version of the other project and still am not able to get a regular build from the command line on that project. However one of the other projects I have which is a Debug version builds fine on the command line. Here is the command line I am using and below that is the legend:

"C:\Program Files\Macrovision\IS12\System\IsCmdBld.exe" -p "D:\ARIESInstall\Aries20061.ism" -r "R20061" -c COMP -a "ARIES"

The name of the software is ARIES so the project file is Aries20061.ism. The Product Configuration is "ARIES" and the Release is "R20061". I’m compressing the release thus the –c COMP. Other things to know, the release is building for a CD-ROM, Windows NT family, include the MSI engine and .NET 20 redistributable.

So is there just some bit switch I need to throw?
Thanks for any help,
Bill Snodgrass

06-14-2006, 03:35 AM

I'm just thinking aloud here with no hard evidence to back my thoughts up but does the command line build produce a log file that you can compare to the one produced by the IDE build? Maybe it might reveal a critical difference?

06-14-2006, 10:47 AM
Please try building with the -v parameter to get a verbose build log and see what kind of information you get from there.

I imagine it's hiccuping trying to find some file or something of that nature.

06-14-2006, 10:52 AM
And if you've already set up your compression and other desired settings with the release and configuration you defined in the Release Wizard, perhaps you can leave off the -c switch when building?

06-14-2006, 03:23 PM
Thanks for the responses.

Last night before I went home I started updating the Debug version that had worked from the command line and added in some missing files as well as merge modules and such and after doing this work lo and behold that project exhibited the same problem. So that has me thinking, as Bryan points out, that the command line build is not able to find some merge module or perhaps is failing on some file I added.

To answer Hamilton's thought, the next line in a good build log would say "File table successfully built" which would make me think that the problem is something within the File table. Also looking at the blank MSI, the File table is populated with the FileSize, Attributes and Sequence but no File, Component_ or FileName.

I will add the -v parameter and see what happens. I'll also try to your suggestion Robert and leave off the -C COMP parameter.

Thanks all for your help and I'll let you know what I find.

06-14-2006, 10:25 PM
Ok, well was able to get the command line build to work. Thanks to Bryan's post using the -v (did not know that existed so that was cool) gave me a wee bit more information. The log now just included some entries about finding .NET dependencies and properties for the next file in the list and then ended as if there was no problem.

This started me thinking that there might be a problem setting the .NET Scan at Build to "Dependencies and Properties". (I note in my original post that I did not mention that these are mostly Visual Studio 2005 files.) I had previously set that property as shown and there were no warnings listed during the IDE build. So I changed the .NET Scan at Build to "None" for all of the files and viola, it worked. Next I added back the original setting for a number of the files each time verifying that it worked until it finally failed. Seems that one of my files causes the .NET scan to fail then causing the command line build to end.

For the affected file, I changed the property to scan for just "Properties" not "Dependencies" and that worked as well. So my guess is that during the .NET scan of that file there is some dependency that is needed that it can not find and ends the command line build. I know that there are no other dependencies that the file needs so I don't think it is problem leaving the setting as is but I'm curious as to what the .NET scan thinks it needs.

In any case, thanks for all your feedback.

06-15-2006, 05:19 PM
Perhaps if you could attach your verbose build log we could take a look and see exactly what it's hiccuping on. With InstallShield 12, we implemented a few things that I believe may be helpful in resolving this; however, I think it's important to first take a look at what it's failing to include.

06-15-2006, 05:25 PM
Of course the problem is that it does not actually say that there is an error but I will attach the log.

06-15-2006, 05:39 PM
Please try downloading and installing the MSI from this Microsoft update:

You may need to remove the existing installation of MSXML 3.0 on your system prior to attempting to install this version of MSXML 3.

Please post on here if this works for you.


09-18-2006, 10:17 AM
FYI, there is now a hotfix available for this. I had the exact same problems it did the trick for me.


09-18-2006, 11:16 AM
Thanks for letting me know. I never did get around to installing MSXML 3 to help troubleshoot this. Glad InstallShield was able to find this bug and fix it.

09-19-2006, 11:00 AM
FYI, there is now a hotfix available for this. I had the exact same problems it did the trick for me.

It seems I spoke too quickly unfortunately... Standalone build works on my development machine and in a VMWare session, but not on the build machine - even with the hotfix and all the latest MSXML installed. The build just stops without any errors.

If anyone could shed some light on this I'd be very interested...

09-19-2006, 03:19 PM
Trying adding the -v parameter to your build and attach your log. I'd be interested to see what is going on there...

09-20-2006, 02:23 AM
Here you go. On the second try I disabled .NET Scan on ALL my components, same result. If there is any way I could help debug this I'd be happy to try.

09-20-2006, 03:34 PM
Looking at this, it could be related to bringing in some form of dependency but it's hard to tell. Usually, you'd get something about building file table when it starts doing dependency stuff.

You might do a double-double check to make sure all your dependent files are installed where necessary and you have .NET 2.0 installed on the system (or whatever version you may need).

09-21-2006, 04:43 AM
Now I've tried the following:

1. Cleaned up build machine and disabled virus scanner - no change
2. Installed IS12 proper (including hotfix) and built with IsCmdBuild.exe - no change
3. Built from IS12 IDE - crash:

Exception ACCESS_VIOLATION (0xc0000005)
at address 0x7818069c trying to read address 0x00000000.

File : C:\Program Files\Macrovision\IS12\System\isdev.exe
Version :
Exception : c0000005
Address : 7818069c
Access Type : read
Access Address : 00000000

Registers : EAX=00000000 CS=001b EIP=7818069c EFLGS=00010202
: EBX=0bbd0dbc SS=0023 ESP=0012c6f4 EBP=0bbd0dbc
: ECX=00000000 DS=0023 ESI=0767643c FS=003b
: EDX=02b70003 ES=0023 EDI=00000000 GS=0000

Stack Trace : 006f0052 00000000 00000000 00000000
: 00000000 00000000 00000000 00000000
: 00000000 00000000 00000000 00000000
: 00000000 00000000 00000000 00000000
: 00000000 00000000 00000000 00000000
: 00000000 00000000 00000000 00000000
: 00000000 00000000 00000000 00000000
: 00000000 00000000 00000000 00000000

Running under VS2005 debugger gave this call stack:

> msvcr80.dll!wcsstr(const wchar_t * wcs1=0x00000000, const wchar_t * wcs2=0x0ae56c2c) Line 47 C
[Frames below may be incorrect and/or missing, no symbols loaded for ISMsiEntity.dll]
msvcp80.dll!std::char_traits<unsigned short>::_Copy_s(unsigned short * _First1=0x0b4ea6b4, unsigned int _Size_in_words=80208364, const unsigned short * _First2=0x00000028, unsigned int _Count=20) Line 344 C++
msvcr80.dll!memcpy_s(void * dst=0x67c9612c, unsigned int sizeInBytes=1735539232, const void * src=0x67723a10, unsigned int count=0) Line 67 + 0xc bytes C

<edit> Seems to be the same problem as described here: http://community.installshield.com/showthread.php?t=160769

09-21-2006, 06:52 AM
I found the problem, and it turns out it had nothing to do with .NET scan.
The non-null string in the crashing wcsstr() was a filename that made me suspicious. Looking at the containing component, it had two dynamic file links that caused the same file to be included twice (from different locations). Obviously not an ideal way to use dynamic file linking, but it shouldn't cause a crash...
I've attached a very simple project that reproduces this behavior. Now, what do I win for pinpointing a bug in IS? :p

By the way, I think I found another bug in the standalone build. It seems it looks for the Visual J# redist in the wrong location:

Adding Microsoft(R) Visual J# redistributable to setup
ISDEV : error -6644: The Visual J# redistributable C:\Program Files\Macrovision\IS 12 StandaloneBuild\vjredist20.exe is not found on the system. To download this file, launch the Redistributable Downloader from the Tools menu.
ISDEV : fatal error -5087: Stop at first error