This is definitely a PEBCAK issue. I downloaded WIX, created a VB.NET CA with it. Here's the code: Public Class CustomActions _ Public Shared Function BackupConfigFiles(ByVal session As Session) As ActionResult session.Log("Begin BackupConfigFiles") Dim configPath As String = Path.Combine(System.Environment.GetFolderPath(System.Environment.SpecialFolder.ProgramFiles), "My Product") For Each configFile As String In session.Database.ExecuteStringQuery("SELECT `File` FROM `File` WHERE `Component_` = 'ConfigFiles'") If File.Exists(Path.Combine(configPath, configFile)) Then File.Copy(Path.Combine(configPath, configFile), Path.ChangeExtension(Path.Combine(configPath, configFile), "bak"), True) session.Log("Changed extension of " & configFile & " to .bak") End If Next session.Log("End BackupConfigFiles") Return ActionResult.Success End Function End Class At this point, I compiled the code. WIX's fantastic MSBuild extension ran MakeSfxCA for me automatically. So, at this point, I have MyCustomActions.CA.dll built. I drop that binary into my install. I should mention that my install has a .NET 3.5 SP1 prereq, so I am definitely laying down .NET. I go to Installshield's CA screen, and tell it I have a new 'MSI DLL'-->Installed with this package. I point it at MyCustomActions.CA.dll. I tell it my function name is BackupConfigFiles, and tell it to run synchronously and also that I want it to execute with deferred execution in system context. I sequence it directly after InstallInitialize. I build the install, boot up a clean VPC with XP SP3 and run the install. The install (which, without the CA, runs fine), no longer installs. I review the detailed MSI log and see this: [CODE] Action 16:00:12: MyBackupFiles. MSI (s) (C8:28) [16:00:12:639]: Executing op: CustomActionSchedule(Action=MyBackupFiles,ActionType=3089,Source=C:\Program Files\My Product\MyCustomActions.CA.dll,Target=BackupConfigFiles,) MSI (s) (C8:0C) [16:00:12:639]: Invoking remote custom action. DLL: C:\Program Files\My Product\MyCustomActions.CA.dll, Entrypoint: BackupConfigFiles MSI (s) (C8:0C) [16:00:12:639]: Generating random cookie. MSI (s) (C8:0C) [16:00:12:649]: Created Custom Action Server with PID 1304 (0x518). MSI (s) (C8:28) [16:00:12:699]: Running as a service. MSI (s) (C8:28) [16:00:12:709]: Hello, I'm your 32bit Elevated custom action server. Action ended 16:00:12: InstallFinalize. Return value 3. MSI (s) (C8:28) [16:00:12:719]: User policy value 'DisableRollback' is 0 MSI (s) (C8:28) [16:00:12:719]: Machine policy value 'DisableRollback' is 0 MSI (s) (C8:28) [16:00:12:729]: Executing op: Header(Signature=1397708873,Version=405,Timestamp=1022853127,LangId=1033,Platform=0,ScriptType=2,ScriptMajorVersion=21,ScriptMinorVersion=4,ScriptAttributes=1) MSI (s) (C8:28) [16:00:12:729]: Executing op: DialogInfo(Type=0,Argument=1033) MSI (s) (C8:28) [16:00:12:729]: Executing op: DialogInfo(Type=1,Argument=My Software) MSI (s) (C8:28) [16:00:12:729]: Executing op: RollbackInfo(,RollbackAction=Rollback,RollbackDescription=Rolling back action:,RollbackTemplate=[1],CleanupAction=RollbackCleanup,CleanupDescription=Removing backup files,CleanupTemplate=File: [1]) Action 16:00:12: Rollback. Rolling back action: Rollback: MyBackupFiles [/CODE] OK, so what am I doing wrong? I would have at least expected to see 'Begin BackupConfigFiles' in the log file, because that's the first line of code in the CA's function! So, apparently, it's unable to find the BackupConfigFiles function? Please help!:confused: ... View more

Here's the problem. We can sign our installs, but only when logged in as the administrator account. Nobody else can sign, not even users who have admin privileges! Our previous certificate expired so we purchased a new certificate from Thawte. They sent us two files: a p7b and a pvk file. I used pvkimprt to create the pfx file, which I then imported into our build machine's certificate store (I put it in Personal-->Certificates). So, our install is pointing at the pfx file on disk and I specified the password and it builds & signs, but only under the administrator account! As soon as I log in as someone else, I get: ISDEV : error -6259: Internal build error I looked at the KB article for error -6259 and it says to try manually signing with SignTool.exe. That works fine no matter who I am logged in as! So, this works: signtool sign /f C:\ourcompany.pfx /p C:\setup.exe Done Adding Additional Store Successfully signed: C:\setup.exe So, I run sysinternals' processmonitor next. I see where the error happens, but there are so many events occurring (80,000) that I cannot really figure out what's causing the error. By the way, here's a successful log from Installshield: Resolving strings... Language English (United States) built ISDEV : warning -1527: No files are included in the project. Media table successfully built Started signing certificate.msi ... Successfully signed: certificate.msi Performing Upgrading and Patching Validation Started signing install.msi ... Successfully signed: install.msi Setup.exe created Started signing setup.exe ... Successfully signed: setup.exe And here's a failure log: Resolving strings... Language English (United States) built ISDEV : warning -1527: No files are included in the project. Media table successfully built Started signing certificate.msi ... Successfully signed: certificate.msi ISDEV : error -6259: Internal build error ISDEV : fatal error -5087: Stop at first error Release\Release - 2 error(s), 1 warning(s) ... View more

There's a bug in the PRQ file for .NET 2.0 SP1 in IS2009, and I figure I would give everyone the heads up in here. Open any of the .NET 2.0 SP1 PRQ files in the prereq editor and switch to the 'Conditions' tab. Highlight the top entry (the one that looks for a specific value in the registry) and click Modify. The bug is that it's looking at the value defined in SP in HKEY_LOCAL_MACHINE\SOFTWARE\Microsoft\NET Framework Setup\NDP\v2.0.50727, but it's doing a 'Not Equal To' comparison! (The value is 1 when 2.0 SP1 is installed, and 2 when .NET 2.0 SP2 is installed). When you upgrade .NET 3.5 to .NET 3.5 SP1, it upgrades .NET 2.0 to SP2. Now, when your users (who have .NET 3.5 SP1 installed) go to install your installation package (that requires .NET 2.0 SP1), it will tell them they need to install .NET 2.0 SP1 first (even though they have .NET 2.0 SP2)! The prereq needs changed to do a 'Greater Than' comparison rather than a 'Not Equal To' comparison. Hope this helps someone! ... View more