There's docs on minimizing the number of UAC prompts: http://helpnet.flexerasoftware.com/isxhelp22/helplibrary/MinimumUACPrompt.htm http://helpnet.flexerasoftware.com/installshield19helplib/helplibrary/SpecifyingRequiredExecution.htm As for a verified publisher: Sign your installation package. There's docs on this too, but for the most part it involves buying a code signing cert and importing it into your *.ism. ... View more

gwesterfield wrote: I am experiencing the same exact error, even when I don't add any new files. If all I do is change the version between the msi's I get the error. Also, the patch log has a ton of "INFO File Key: _(GUID) is newly added" logs which is what I think is accounting for the patch hitting the limit as you can see below. What I don't understand is all the files are 100% identitical and the only changes I have made to the ism is the version. Any idea what could be causing these new file keys to be added when there are no new files? INFO File Key: _54EA9BFC14E7710A5F19837CADA1E8CA is newly added PERF INFO: File Info Lookup Time: 0 ms INFO File Key: _DC3ECD300D578635A09A69FFE4D8B3DC is newly added PERF INFO: File Info Lookup Time: 0 ms INFO File Key: _E77E3757AA11E347958F54916D847290 is newly added PERF INFO: File Info Lookup Time: 0 ms INFO File Key: _2DED20C450A5C40DAE0B11D9DB43B19F is newly added PERF INFO: File Info Lookup Time: 0 ms INFO File Key: _2A5B77D2B5631605ABEEE34C34B6F7E1 is newly added PERF INFO: File Info Lookup Time: 0 ms INFO File Key: _1FD7C352264C433D907DEE909493A7B9 is newly added PERF INFO: File Info Lookup Time: 0 ms PERF INFO: V:\t\911\Prev1\AirWatch.msi 47216 ms PERF INFO: V:\t\Console FP1\9.1.1.3\Latest1\AirWatch.msi 47299 ms SCHEMA: Table: Patch has mismatched schema (or missing column) for: Header ERROR: Failed to execute view: 'File' ERROR: The Last Error Received is: 0x65b (1627) ERROR: The Last Error Received is: 1: 2210 2: \\?\C:\Users\GWESTE~1.VMW\AppData\Local\Temp\3\ISPE6B8.tmp\Prev1.MSI 3: 0 This sounds like you may want to look into 2 things: 1. "Best Practice" dynamic file links. (The default when created newly in any recent IS version--not the default if you're maintaining a project created a long time ago) 2. The "Previous Package" setting in the release configuration. This tries to synchronize primary keys to avoid errors like you're mentioning. What's likely at play is that the legacy style dynamic file links are generating new primary keys every time you build. This isn't likely your only issue if you're generating patches: files left behind on uninstall when folders are removed, no files updated by the patch patch file size is weirdly large ... View more

209software wrote: I am still having trouble getting installshield to replace my app with the newer version. The users are having to uninstall the old version first. Here's what I want... - The installer should install normally if the program is not there. - The installer should upgrade the software if it's a newer version. - The installer should warn and make the user confirm if this it a downgrade from the currently installed version THIS SHOULD BE THE OUT-OF-THE-BOX default settings for InstallShield builds FOREVER. This whole "You already have a version of this installed" should never occur, or if the developer asks for it, there should be an "Are you NUTS?" dialog box to confirm it. So perhaps a discussion on why this error takes place will be helpful. (Short answer: It's the design of the Windows Installer engine, which InstallShield is constrained by) When you rebuild your install using the same ProductCode, the MSI engine sees that a copy of the MSI with the same product code is already installed. To install it as an upgrade it requires certain command line parameters to be passed (but only if it is already installed). There's some other requirements, but broadly, that's how the installer engine works. You shouldn't see this message if you're building with a setup.exe file. InstallShield tries to simplify this case by embedding logic into the *.exe file and passing those conditional parameters for you. The other option is add an upgrade path (which has other requirements). ... View more

To reply to the sentiment here that something as simple or fundamental as dependency scanning should be easy--you'd be surprisingly mistaken. I've had situations where MSBuild itself was copying to the build output location the wrong version of an assembly whereas it worked with the full IDE on my Dev machine. (In this case, the problem was a dependency of a dependency which picked up the wrong version earlier in the build before processing the direct reference). Are you obfuscating your assemblies? This removes (obfuscates) metadata in the assembly which can trip up dependency scanning. I think there's a whitepaper for including project outputs from Dotfuscator somewhere out there if that's the case... Are you using a primary output? If so, what do the MSBuild logs look like compared to the IDE logs? My advice when it comes to your installer: don't rely on dependency scanning during your build if possible. Statically link in your application and dependencies to the project file. In the short run it may seem like more work, but you'll be a step ahead in the long run to exercise tight control over what goes into your installer. ... View more

There was a blog post on this once: http://blogs.flexerasoftware.com/installtalk/2011/01/building-32-bit-and-64-bit-installations-from-the-same-installshield-project.html ... View more

IIRC, It's more or less the same as VBscript custom actions. http://blogs.flexerasoftware.com/installtalk/2012/10/debugging-vbscript-custom-actions-fact-or-fiction.html ... View more

Microsoft changes how all of that works fairly regularly so the recommendation is to never attempt This /\ I was told once that we absolutely had to do this, because we can't trust our users to know how, so please take a look at it, would you? What I ended up with was a prerequisite batch file of surprising complexity, because across a handful of supported windows versions you've got: Different command line tools for installing windows features Even across two versions with the same command line tools, the windows feature names change Sometimes they change what subfeature a feature belongs to Sometimes they change the dependencies of the feature The solution Microsoft created for this (powershell DSC) isn't necessarily supported across all platforms And if it was, you'd have to install Powershell to start with Which is a windows feature in itself, so return to step 1 and start over with the task of installing a windows feature. ... View more

chad.petersen wrote: But not WiX? You'll have to author that extension and submit for possible inclusion....lol. I'd have to get approval from security & compliance teams to donate my solution to Wix. So that's unlikely. But, if InstallShield comes out with their own feature (especially if it is fancier and more secure than what I wrote--which is likely), they'll have an advocate at my company to purchase the latest version of IS. All told, it's not out of the park nuts to make a winking request here. 😃 ... View more

Cary R wrote: Sort of true. There's extensibility built into setup.exe in the form of prerequisites. One could write an *.exe whose single purpose in life was to check a mutex or lock, and then pass back an error return code if found (which would error out setup.exe). You'd just call this as a silent prerequisite without any conditions so it always runs, and this gets you halfway there. The other half is implementing the lock, which you'd have to make sure takes place during the lifetime of the install. That's a little harder, but my first thought would be to use an Asynchronous custom action which is written to: 1. Grab the mutex (we'll call it _OurMutex for simplicity) 2. Wait for the _MsiExecute mutex to be locked (this happens during the Execute sequence) 3. Wait for the _MsiExecute mutex to be released 4. After which point, you can release _OurMutex because the install is effectively over after the exec sequence has run. This of course presumes that you can get the prerequisite to fire off before the *.msi is cached to the location it shows the error on. Maybe create a dummy *.exe which always passes back an error code to test that first before writing the rest of it. 😃 ... View more

you'd have to modify the Setup.exe itself - which you cannot. Sort of true. There's extensibility built into setup.exe in the form of prerequisites. One could write an *.exe whose single purpose in life was to check a mutex or lock, and then pass back an error return code if found (which would error out setup.exe). You'd just call this as a silent prerequisite without any conditions so it always runs, and this gets you halfway there. The other half is implementing the lock, which you'd have to make sure takes place during the lifetime of the install. That's a little harder, but my first thought would be to use an Asynchronous custom action which is written to: 1. Grab the mutex (we'll call it _OurMutex for simplicity) 2. Wait for the _MsiExecute mutex to be locked (this happens during the Execute sequence) 3. Wait for the _MsiExecute mutex to be released 4. After which point, you can release _OurMutex because the install is effectively over after the exec sequence has run. ... View more

There is a way, of course. If you have any other way of doing it other than this, I'd recommend it. But here goes: [LIST=1] Use a C# custom action type. It's going to be a major pain in just about any other language. This will require first building the assembly and then setting it up in InstallShield. Look into the docs for the .Net Process class For the ProcessStartInfo you feed into the Process constructor, make sure to set UseShellExecute to true, as well as RedirectStandardInput and RedirectStandardOutput The docs I linked for RedirectStandardInput and RedirectStandardOutput have sample code that shows you how to work with the streams. I have found that there is one case that kills this approach: If the executable filters input (for example shows alternate characters in the case of password input), it will break the standard input redirection. I've never found a way around this issue. Good luck! ... View more

Presuming the values you want to save aren't sensitive (like a username & password), you could write them out to the registry and then pull them back in with a System Search to that registry value. I've done this in the past. If you are trying to maintain a value that's sensitive (like a username & password), the aforementioned solution is going to be problematic. When I had to do this in the past, I authored a custom action to encrypt/decrypt the values from either the registry or an *.xml file that my custom action created on the system and used either simple XOR obfuscation or AES256 encryption. This was actually a big undertaking, which used a deferred/system context custom action to write to the registry/xml file, and supported rollback, cleanup, install, uninstall, maintenance and was driven with a custom table. All of which was written in C# using the Wix DTF custom action support, and then either consumed by both Wix and Installshield installers. Alas, I can't share this solution, but it'd be a great feature to include in the next version of InstallShield... Right guys? 😉 ... View more

sfurr999 wrote: I have an application that I'm packaging that requires a license file to be copied to the AppData folder in the user's profile. I have a "CurrentUser" feature and a "Main" feature as a child feature. All application files are in the Main feature and the one license file is in the CurrentUser feature. The license file is setup as a key file as well. When I install the application with an admin account as a per-machine installation, the application installs correctly and drops the license file in the correct directory in the user profile. However, when I log out and back in as another user, I launch the application from the advertised shortcut, it self-heals because it doesn't see the file it the current user AppData folder, but the self-heal is trying to put it back in the profile that the application was installed under instead of the current user. I've created a custom action that pulls the USERPROFILE environment variable and assigns it to the path where I want the file installed, but it's still, somehow, trying to install to a different profile. I'm a new convert to Adminstudio. I was using Wise Package Studio before this and always setup these types of installs the way this one is set up and I've never had issues. Not sure if there is something quirky with AdminStudio that I'm not aware of or what. Any suggestions? :confused: The license file can't be the keypath. The literal file path it installs to is used as the keypath in the registry, which means that it's not repairing that component. Give it a Registry keypath under HKCU; this way the registered path in the MSI registry doesn't change, but it will be found to be missing. My guess is Wise did this on your behalf on the back end. ... View more

IlkkaV wrote: I'm having issues with creating an ODBC entry that's visible for 64-bit applications. The entries I create always go to the 32-bit version (C:\Windows\SysWOW64\odbcad32.exe) instead of the 64-bit one (C:\Windows\System32\odbcad32.exe) and because of that the created ODBC DSN is not visible for the DB list in our 64-bit configuration utility. I've tried the following: -Change template summary of the whole project from Intel to x64 (we have both x86 and x64 releases defined in the same project) -Associate the ODBC DSN entry with a component that's included only in the x64 release -Move the component for the ODBC DSN entry from the default x86 installdir to the root folder for 64-bit components (which is made the installdir using a custom action in a 64-bit version) and marked the component as 64-bit Am I missing something here? Should I give some additional parameters to the DSN entry? I can see myself in the near future needing to do this exact task, so I just gave this a quick try with the following steps: 1. Created a new project 2. Set TemplateSummary to x64;1033 3. Imported a DSN from the ODBC Resources view in InstallShield 4. Went to Components view and marked the newly created component as 64 bit 5. Installed It successfully created it as a 64 bit System DSN. So, based on your steps listed, it should work. Maybe the logfile will show something going wrong during the InstallODBC action? I would also recommend a sanity check by viewing the package in Direct Edit mode to make sure everything looks like it should, since Release flags are involved. ... View more

Hi Jeff, I unfortunately can't get more info from the Development team, as I no longer work for Flexera. I contribute to these forums still under the same account because I like helping people, and find it interesting. The Dev's do read these threads, though. So perhaps any listening can chime in on potential causes. In a worst case scenario, I would reach out to Technical Support and see what they say. ... View more