Showing results for 
Show  only  | Search instead for 
Did you mean: 
Level 2

Fatal error -5056 when building IS project via VS2012 using Team Foundation build

I'm trying out the IS 2012 Spring edition in hopes to be able build Visual Studio 2012 solution that includes IS projects via TFS Team Build. Currently, I can build the solution manually on the TFS Build server but the build fails with the below error when trying to run it in a TFS Team Build. Does anyone here have possible suggestions on what may be the cause of this.

C:\Program Files (x86)\MSBuild\InstallShield\2012Spring\InstallShield.targets(68,3): error : -5056: Internal build error
C:\Program Files (x86)\MSBuild\InstallShield\2012Spring\InstallShield.targets(68,3): error : Exception Caught


Labels (1)
0 Kudos
2 Replies
Level 7

First of all, if you are using Team Foundation Server 2012 then you'll need to use InstallShield 2012 Spring with SP1. If you're using TFS 2010 then you won't need SP1 for InstallShield 2012 Spring.

Have you taken these steps? --

1) Open your VS2012 *.sln solution, add the *.ism InstallShield project. This creates the *.isproj "bridge" project, which connects the *.ism to the *.sln.

2) In VS2012 use the Configuration Manager to make sure the install project builds whenever the solution builds (select its checkbox in the configuration manager's "Release" view).

3) Check in all changes (i.e., the changeset) to TFS.

4) Create a TFS build definition that builds the Release configuration for the *.sln. In the build definition, on the "Process" tab, expand the "Advanced" tab and set MSBuild Platform to X86. Do this even if the operating system on the build box is 64-bit. That's because InstallShield installs as a 32-bit app on a 64-bit computer, and the x86 flag helps TFS "find" the InstallShield programs. If you specify "Auto", which is the default value, it will look under "Program Files" instead of "Program Files (x86)", and fail to find the InstallShield programs.

5) Save the build definition, and Queue the build. Note: modifying a build definition does *not* create a changeset to check into TFS -- it's considered a "live" change that happens as soon as you save it.

Special note: if even one of the projects in your Visual Studio solution is a C++ project you will not be able to build the install project! If they are all C# projects, then the install project will build fine. I have reported this as a bug to FlexeraSoftware personnel and they have been able to reproduce it.

Also, in the Releases view of Installshield, remember to set "Distribute After Build" = Yes on the "Events" tab; this will copy the compiled install to the area where will get picked up and copied over to the "DropZone" for TFS (enabling your uses to go grab the compiled install). Also on the "Events" tab, fill out the "Copy To Folder" information. E.g., ..\..\..\Binaries In other words don't use a path like C:\Builds\MyBuild\Build1\Binaries because that's an absolute path, and TFS does not always use the same path ... part of the path is the build name, which changes with each build, so you need to use relative instead of absolute paths. Same thing applies for all your path variables (Media/Path Variables in InstallShield).

Hope this helps. It took me a long time to discover all these things on my own.
0 Kudos
Level 2

Thanks Shuttledude,

I spent several hours yesterday with Flexera with no resolution. I had already performed all the steps you listed except for installation of SP1. Now I'm up and running.

Thanks again,

0 Kudos