I have run in to this exact same problem, same error. IS12 and 2008 on IIS6, Windows 2003. This can occur when creating application pools as well as virtual directories. This can occur in .NET 1.1.4322 and .NET 2.0.50727 applications. This can occur if IIS is running in high isolation mode. Basically, I don't think it has anything specifically to do with your installation per se, but more to do with IIS and IS trying to use the same resource at the same time and one of them is winning out... unfortunately it isn't the side you're working with. This does occur some times and not others and I see it more often than not on our web servers which host more than 5 web sites. Typically these are test and acceptance environments; being shared resources, these servers have more on them than a production server would. What I have found to be a 'work around' if you can call it that, is to reset IIS prior to running the install. My guess, if I had to make one, is the underlying custom action is using ADSI to take care of the creation/destruction of these objects, but doesn't have a 'wait' mechanism if the path is busy. If a QA person was recently on the site to be upgraded, then IIS has not released the application's resources yet, and the path is busy. By forcing an IIS reset, you are manually freeing up the resources and if the application does not load before you complete the install, it should go through. I have not seen this occur on first time installations, only upgrades which makes sense as there are no locked resources to cause this error on a first time install. While the work around is fine in test or acceptance environments, it is a drag when it comes to deploying to a production level environment where service interruption is not always acceptable. If it happens on your application pools and not your virtual directories, you might be able to get away with just recycling the application pool(s) prior to installation and see if that works. For us, it happens on everything from app pools to virtuals so an IIS reset is a sure-fire kill all... It would be really really nice if IS could trace this down I'd be more than happy to share anything I know with them if contacted. ... View more

Thanks to Hidenori! 🙂 🙂 🙂 I've tested this patch (ISWIBuild.dll) out on 3 separate install projects each with 3 instances in them, and so far the Major Upgrades work using the "Products Sharing My Upgrade Code" option. Each instance of the install removes the previous instance and ignores other instances installed during a major upgrade. hidenori wrote: I was able to reproduce the behavior that the upgrade code in the instance-transform is not used when you perform a major upgrade with the "Products Sharing My Upgrade Code" option selected. I filed the work order #IOC-000066649 so that it will be fixed in the next major release. Also, I created the hotfix for InstallShield 2008. You need to copy the new ISWIBuild.dll to the C:\Program Files\Macrovision\IS2008\System folder and rebuild your setup in order to apply the fix. If you are using the standalone build, you need to copy the new SABuild.dll to C:\Program Files\Macrovision\IS2008 Standalone folder. Note that this is an unofficial release as it has not been completely tested by our QA team. I strongly recommend that you make a backup copy of the original file before copying the new file. Regards. ... View more

I've been beating my head against the major upgrade problem for a while now and I think the following will help: For sake of illustration, let's assume you have 3 Instances in your project and this is a Basic MSI: Instance0 = Default Install Instance1 = Bob's Install Instance2 = Tom's Install Recipe Part I: In your upgrade settings, leave it on "Products sharing my upgrade code". Build your EXE normally, your InstanceId property should default to 0 in the Property table. This will be the "Default" install, set it aside for later and have a drink. Recipe Part II: In your upgrade settings, change it to "Products using another upgrade code", change the guid of the upgrade code to that being used by Instance1 or the "Bob" install. This property should be in your ISProductConfigurationInstance table as UpgradeCode. (Also remember the MSI rules about changing ProductCode, PackageCode and Version when doing upgrades, they still apply but you have to apply them in this table by hand... or with some vb script or other method at your disposal http://msdn2.microsoft.com/en-us/library/aa370579.aspx) Build your EXE set with transform1. You can set the transform by passing parameters to the MSI (i.e. TRANSFORMS=:InstanceId1.mst MSINEWINSTANCE=1 /qf/liwearucmopvx /log "c:\MyInstallInstance1.log") This will result in the "Bob" install. Now that Bob is done, have another drink and come back for the third. Recipe Part III: In your upgrade settings, change the guid of the upgrade code to that being used by Instance2 as we did earlier Build your EXE set with transform2 This will result in the "Tom" install. Have another drink. You'll wind up with 3 separate Setup.exe bootstrappers, each one built with the same compressed MSI save for 1 row in the Upgrade Table. This will keep them separate enough to allow major upgrades to occur as they do in projects where multi-instance nonsense is not a problem. By this time you should be on your way to either channeling Julia Child or inebriation, either way the blasted things are done. I think the problem is that since the MSI is looking at a shared upgrade table with entries for each instance, it sees the relationship and removes all other 'older' copies. I could be way off base, but finally I got this working for me and if I can save someone else the same forehead bruise then so be it. ... View more