Why indeed, when after MSI 5.0 it caches the whole entire compressed *.msi? Full packages that you can rename to the original package name and use just like the original installer? Having been around for the evolution of this scenario, I'll tell you. Prior to msiexec.exe 5.0, it used to strip the internal cab files out of the package when it saved it to c:\windows\installer. But of course, doing so changed the file hash of the package, and would break the display of the MSI's publisher in the UAC prompt when uninstalling or modifying the package (that is, if you'd signed the package with a signing cert). So a fix had to be put in place for Win7, because messing with signed packages is a security issue, not an installer issue. That fix was to cache the whole package. Problem solved! So if it's the full package, why can't you use it to repair instead of needing the original package? MSI source resolution requires a package that matches exactly by name. So even if it registered c:\windows\installer as a valid source (which it doesn't by default), it won't use the package because the file name is randomized to not be human-readable. I had the idea to create a symbolic link to a different location using the original package name and try using it to repair--and it worked great. I later found out some other guy came up with this a few years earlier. And of course, there's good reasons why this isn't a useful feature to bake into InstallShield (specifically, the SymLink API's don't seem to work correctly when done via automated deployment process under the SYSTEM account). So yeah... Cache the install locally is your best bet still. Crazy as it is. ... View more

switch to a single compressed *.exe and you should be able to use that setting. ... View more

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/library/windows/desktop/aa370532(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? ... View more

Sounds like this: https://flexeracommunity.force.com/customer/articles/en_US/ISSUE/Q113345 They broke the HTML table in the latest KB article, though. Ignore that broken rowspan tag. Gist of it is: the older COM Extraction would include a root level key if some *.dll's, *.ocx, etc. touch the key for some reason, but otherwise don't write anything to it. You can manually tweak an already built MSI file to fix this, or you can rebuild it with a newer InstallShield to see if the new filters correct it. ... View more

eladef wrote: Check this link I created a CA (with the needed condition) that set the REINSTALL property to the Feature I need to reevaluate. /\---this. Sort of, anyways. The difference between a Change and a Repair in this case is a Reinstall control event. You don't necessarily need a custom action--you could duplicate the event on the MaintenanceType dialog and have it run for Change as well as Repair. ... View more

If I recall correctly the Prereq engine uses ShellExecute() to run stuff. So you should just be able to use a *.bat file. A *.bat file will show the command window, though. So if that's a dealbreaker, a c# executable is just a few lines of code. ... View more

This gets asked periodically. You'll basically have to do it in an external *.dll of some sort, or prototype the rand/srand functions in msvcrt.dll and call it from InstallScript check out: https://stackoverflow.com/questions/45296986/random-password-creation-using-install-shield-install-script http://www.cplusplus.com/reference/cstdlib/rand/ You'll basically generate an integer between 0 and 93, add 33 and treat it as a Char. Repeat the process X times for however long a password you want, appending char by char to a String variable. ... View more

Don't do this. If you have 2013 Pro, build with 2013 Pro SAB. You should be entitled to it. If there's a compelling reason, I can suggest a way to downgrade the project file on the fly. But it is hacky, and you really don't want to do that if you have any other option. (Not to mention, it might not work if you're using 2013 Pro related functionality). ... View more

DataAnalyzer wrote: So I'm wondering if it's a timing issue or order issue. 1. Could InstallShield be trying to register the OCX before other files in the setup are properly installed? 2. Do I need to or is there a way to make sure this is the last object to be registered? Thanks. 1. It could be! It is possible it requires another file to be registered first. Unfortunately, you'll have to manually figure out this dependent ordering. 2. There is a way. If you set it to self-register (and use the InstallShield self-registration option in the settings), you can go to the ISSelfReg table in Direct Editor and populate the 'Order' column A question you didn't quite ask was about how COM Extraction helps with ordering. So here goes: If you ensure everything is correctly registered on the build machine, then Com extraction reduces the registration process to Windows Installer operations that don't require executable code running inside the *.ocx (and thus fail because of dependent ordering) It's for this reason that COM Extraction makes the setup more reliable. But... You still have to figure out the correct order to register them in to prepare the build machine for the project build. Otherwise, the build will fail with an error attempting COM Extraction. Hope this helps! ... View more

Whatever language you use, you should check out the Win32_NetworkAdapter class in WMI. You should be able to easily query this and iterate through the adapters. https://msdn.microsoft.com/en-us/library/aa394216(v=vs.85).aspx VBScript, C#, Powershell, whatever should work fine for this task. ... View more

DonAIR wrote: We are actually looking into dacpac's. Are you using them currently? It hasn't hit the installshield process at our office yet so we haven't started looking into it fully, I just know they eventually want to provide us with dacpacs. Anything I should look into? I am not personally yet in my installs, but I know a few people that are. Basically, those folks have implemented logic to locate the command line executable that processes the *.dacpac, not unlike how you'd do with SQLCMD. Which is to say you have to install as a prereq, create a search to locate the *.exe, and then pass through all the params on the command line. ... View more

DonAIR wrote: disregard my stupidity, I figured that out. I thought i could only import, didn't realize i can link directly to files. now I just need to figure out the best way to use schema versioning on it. https://flexeracommunity.force.com/customer/articles/en_US/INFO/Q111714 Pretty much the definitive article on it. I might suggest looking into Data Tier Applications for your database maintenance. AFAIK, no installer tool supports *.dacpac's out of the box (you have to use executable custom actions for them), but they take a lot of the rigor out of database installations. I believe they also can produce *.sql scripts which are usable by SQLCMD (which frustratingly still require a lot of massaging to use in an installer tool...). ... View more

So... I do not think that the InstallShield automation layer supports manipulating services. But, is it possible for you to use the same service name and executable name every time? If so, you can use build automation to just make sure that a different executable is found in the staging location for your various customer builds. ... View more

You have a couple options: 1. Using InstallShield Automation to flip the 64 bit component flag. Start with the docs on ISWiProject object, and you should end up with ISWiComponents collection which you can iterate through to flip the flags. 2. A hackier way is to use the Direct editor to do a find-and-replace on the Component table. The 64 bit setting is a single flag, and so you can make a list of all of your non-64 bit components attributes value, and do a find-and-replace of the exact match of those + 256 (the 64 bit flag) see: https://msdn.microsoft.com/en-us/library/windows/desktop/aa368007(v=vs.85).aspx ... View more

manishpandeyIXD wrote: Hi Experts, I need to call a web url using installscript Can you please suggest the code to call weburl. Regards, Manish It depends what you are trying to do. If you are just hitting a URL for analytics or something, CopyFile supports a URL as a source file: http://helpnet.installshield.com/installshield22helplib/Subsystems/installshield22langref/helplibrary/LangrefCopyFile.htm ... View more