If your applications and app pools exist and you want them to be re-created, then you should write a custom action to delete them before they are created by the InstallShield custom action. If they don't exist and they're not being created, then the InstallShield custom actions probably aren't being executed. Check the install log to figure out why. ... View more

So would using the automation interface to build the install work for you? It'd be fairly simple to change the product code automatically if you can use it. Kelter wrote: Also, let's say a release includes a change to IIS settings for that web app. If you don't delete and then re-create the web app, then the settings never change. I consider this to be a bug in ISIISInstall. If it finds that the app already exists, then it makes no configuration changes. I'm not sure that it's a bug, more like a deficiency. Sometimes people want to use the IIS settings as defaults and the end user is free to modify them, this is how ISIISInstall behaves. In this use case running a repair on the install will retain the end users modified settings. The other use case, which is the one you're talking about, is that the install should have full control over the settings and running a repair should reset any modifications made by the end-user. We had the same problem as you but also wanted to preserve user modifications to some settings. We solved the problem by writing custom actions to save off all of the IIS settings, delete all of our applications and app pools, and then restore specific settings which may have been altered by end users after ISIISInstall has completed. I can give you more specifics if you're interested. ... View more

If you're signing the files included in your install, sign them before building the install. If your MSI is not embedded in setup.exe, then you can sign the MSI and setup.exe after the install is built (or using the Postbuild Event). If your MSI is embedded in setup.exe and you need to sign the MSI, then you can use the Precompression Event using Premier or SAB. The path variable will reference the directory which contains the MSI. ... View more

Why do you not want to change the product code for each release? If you had a custom bootstrapper, you could generate a transform that changes the product code but I think that would cause problems if you needed to release a patch. It'd be better to manually change it before building or use the automation interface to change it. BTW If you configure the Previous Package property on the release settings, it will match up the files included from dynamic file linking. That should resolve the problem you saw with minor upgrades. Downgrading is a different story. See this post and MichaelU's responses: http://community.flexerasoftware.com/showthread.php?192165-Downgrade-or-rollback-to-previous-version&highlight=downgrade ... View more

Have you checked which version of the Windows Installer is on the XP machine? Maybe try upgrading it. You can also use Sysinternals Process Explorer to see what command line parameters are being passed to Msiexec.exe. ... View more

Rather than put the certificate in the binary table, put it in the Support Files area. The disadvantage to doing that is that the user will need access to the install when doing maintenance. ... View more

Ok, here's the basic steps: 1) insert the certificate into the binary table 2) insert certmgr.exe into the binary table (link) 3) add a custom action to extract the certificate to a temp dir - I'm using a CA script named 'ExtractCertificate' that is called after CreateShortcuts in the Install Exec sequence, Immediate Execution: Dim TempFolder : TempFolder = Session.Property("TempFolder") Dim BinaryFile : BinaryFile = Session.Property("ExtractBinaryFile") ExtractBinary BinaryFile, TempFolder & BinaryFile Function ExtractBinary(BinaryName, OutputFile) Const msiReadStreamAnsi = 2 Dim oDatabase : Set oDatabase = Session.Database Dim View : Set View = oDatabase.OpenView("SELECT * FROM Binary WHERE Name = '" & BinaryName & "'") View.Execute Dim Record : Set Record = View.Fetch Dim BinaryData : BinaryData = Record.ReadStream(2, Record.DataSize(2), msiReadStreamAnsi) Dim FSO : Set FSO = CreateObject("Scripting.FileSystemObject") Dim Stream : Set Stream = FSO.CreateTextFile(OutputFile, True) Stream.Write BinaryData Stream.Close End Function 4) add a property with the same name as the CA created in step 2 and set to the certificate name in the binary table - I'm using Name: 'ExtractBinaryFile', Value: 'MyCert.cer' 5) add a CA to run an executable stored in the binary table - I've named it InstallCertificate a) set the Executable Filename to CertMgr.exe b) set the Command Line to: -add "[TempFolder]\MyCert.cer" -s TrustedPublisher -r localMachine c) set Return Processing to Synchronous (Check exit code) d) set In-Script Execution to: Deferred Execution in System Context e) Set Install Exec Sequence to: After ExtractCertificate 6) add a CA to delete the certificate from the temp dir - I'm using a script CA named CleanupCertificate that is called after the InstallCertificate CA in the Installl Exec Sequence, immediate execution: Set fso = CreateObject("Scripting.FileSystemObject") : fso.DeleteFile fso.BuildPath(Property("TempFolder"), Property("ExtractBinaryFile")), True ... View more

I haven't looked into this for IS2010 yet. If you want a work around, include the certificate in the binary table, write a custom action to extract the certificate to a temp dir, write another custom action to run Certmgr.exe, and finally write another CA to delete the certificate from the temp dir. If you want to go this route, I can post some more details for you. ... View more

Did you find this yet? When you have a web site or an application selected click the Application Mappings property in the right pane. ... View more

How are you running the install for the second instance? I use a batch file which runs msiexec.exe: msiexec.exe /I "MyInstall.msi" TRANSFORMS=:My2ndInstance MSINEWINSTANCE=1 I'd assume you can run setup.exe and pass in the TRANSFORMS and MSINEWINSTANCE properties. ... View more

I don't know if the Windows Installer will be able to set your permissions on a network drive. I think the standard actions that use the LockPermissions table run under the system account so it won't have the proper rights on the network. Below is a screenshot showing the properties for a custom action that calls subinacl. You'll need to change the In-Script Execution to Deferred Execution so that it runs with the current users permissions and I'd suggest adding some validation in the UI to verify that the current user has the proper rights. Otherwise the install may error and rollback. ... View more

sligers wrote: Hi, I´ve try to set folderpermissions ( INSTALLDIR ) on VISTA using LockPermission Table. How can I differ between FixedDrive and Remote ? Please help ! Is your question about setting permissions on a local drive vs. a network drive? You can try using subinacl to see if it works on network drives - I believe that it will as long as the user has the rights but I've never tried it. You can download it here. ... View more

I think you'll need to write a CA that gets the parent directory of INSTALLDIR then use MsiSetTargetPath to modify the directory associated with those components. ... View more

One other important thing I forgot to mention when dealing with multiple instances. Because the component ID's are the same, some resources will not be removed when the instance is uninstalled. I wrote a CA that runs at the end of each install and will cleanup resources from components that were uninstalled. The ones I've noticed are shortcuts and registry entries. The CA just iterates the respective table and deletes the resource if present. I've filtered the registry cleanup to certain keys because merge modules and COM objects will also populate the registry table. ... View more

You can do this with a Basic MSI project. I have 5 projects, each install is part of a suite, that do exactly what you're trying to do - they even support 6 instances! 🙂 To start, the project must be setup to build uncompressed so that the MSI file is not embedded in setup.exe. So here's the process: 1) I build the project on the command line so the whole build process is automated. 2) After the project builds successfully a batch file runs that executes a vbscript once for each instance. The batch file has the product codes and upgrade codes for each instance as well as the instance names. The vbscript creates and embeds a transform that makes the following modifications to the install: a) the package code get a new random GUID assigned b) the instance name gets included in the ProductName property - "[ProductName] ([InstanceName])" c) the product code gets assigned the value passed in d) the upgrade code gets assigned the value passed in e) IS_SQLSERVER_DATABASE gets the instance name included in f) several other application specific properties get the instance name included in g) the upgrade table gets updated with the passed in value h) a CA gets created that modifies INSTALLDIR (type 51) i) a CA gets created that sets a flag indicating whether INSTALLDIR was modified by the previous CA (type 51) j) the CA's get inserted into the InstallExecuteSequence and InstallUISequence tables before CostFinalize. the CA's only get executed if "Not INSTALLED" and the flag has not been set k) shortcut names get modified to include the instance name l) certain registry keys get modified to include the instance name (Registry and RegLocator tables) m) application pool names get modified to include the instance name n) the IIS root folders get modified to include the instance name 3) Finally, the MSI is resigned using signtool.exe. I don't have a custom setup launcher but I've considered building one. If I do, I will do it exactly how Wesley describes. It would be pretty simple to implement and you get to keep some of the good features in setup.exe like prerequisites. For now I just include a batch file for each instance that passes the correct parameters to MsiExec.exe to install the instance. ... View more