Community Forums
Results 1 to 4 of 4

Thread: Tips and Tricks for faster installer builds?

  1. #1
    Join Date
    Jan 2007
    Posts
    8

    Question Tips and Tricks for faster installer builds?

    Hello All,
    My current project has 1 ism, with 1 release configuration producing a compressed web format setup.exe wrapped .msi containing 4,300+ files across 170+ directories, which I then configure/ compile into 20 different unique installers using ISCmdBld.exe.

    Currently this process takes almost 2 hours to build, and is the most time consuming step of our build.

    Anyone know of any tips, trick, hacks, methods, processes, best practices, white papers, or other documentation to expedite build time?

  2. #2
    Join Date
    Aug 2005
    Posts
    518
    I have a few for you:

    1. Don't use COM Extract at build where you don't need to. This adds significant overhead, because the library has to load, do its thing, and then have the *.reg stuff processed. You can instead use Self-regstration or Static COM Extraction (i.e. in the COM Regstration view of the component select to "Extract COM Information for key file"). Pros: Could make a huge difference in build time, Cons: You either shift the burdens of registration failure from build time to design time (time consuming, and you could miss changes to the library's interfaces if you're not automatically extracting) or to the Runtime (self registration introduces points of failure). Every way you can skin this cat has pros and cons with regards to risk vs. performance.

    2. Use a fast disk for the staging/build target location.

    3. Don't have the build process pull the source files from the network (stage locally and build).

    4. Don't build the project directly to the network (copy when done)

    5. Depending on your requirements, you might save some build time by disabling the creation of file hashes inside the installers. This is very IO intensive, you can imagine, and could involve your install time going up due to unnecessary file overwrites:

    https://msdn.microsoft.com/en-us/lib...(v=vs.85).aspx

    Just off the top of my head.

    It's possible there's some other parts that take a good long time which are candidates for some optimization. What do your build logs indicate is taking a long period of time?
    Cary R.
    Configuration Engineer

  3. #3
    Join Date
    Jan 2007
    Posts
    8
    Quote Originally Posted by Cary R View Post
    It's possible there's some other parts that take a good long time which are candidates for some optimization. What do your build logs indicate is taking a long period of time?
    Am I missing something? Even with verbose mode turned on (IsCmdBld -v), I don't get a step by step breakdown of duration.

    Thanks for the other tips, this is exactly what I was hoping for; but yes, I too picked up on the obvious - use a fast disk, keep it all local on the fast disk, don't build stuff you don't need to.

  4. #4
    chad.petersen Guest
    Not at my current company, but at a prior job I had a similar build. I set up all of the most common files that were not language specific into a merge module that I shared across the various installers. Those core files that did the meat of the work. It built the Merge Module once and it seemed to process the Merge Module faster as it incorporates it into each installer. Wouldn't work in every case, but it helped cut times by about 1/4 in this situation.

    Chad

Posting Permissions

  • You may not post new threads
  • You may not post replies
  • You may not post attachments
  • You may not edit your posts
  •