Strange that this question has come up so many times lately... The answer is that you can set this up as you're envisioning. Here's what I said in a post recently: Regarding being able to dynamically add files to your project...I've said before that some will disagree with me, but I still think a situation like you're in demands components that use Dynamic File Links to determine which files are included. Adding a dedicated component for every file is just a maintenance nightmare in the real world. I explained it in a lot more detail in this post. I'm not fully aware of what the Automation Interface can do, specifically whether you can use it to establish an automated build framework. We use it to update things in the project like the ProductVersion, Properties, ProductCode, and Path Variables. However, we use home-grown intranet web pages and Perl scripts to allow our inhouse staff to request MSI packages. Our configuration management team has been using Hudson + Visual Build Pro to do similar things. ... View more

sbrown wrote: Also, we have given up on the Windows Installer and are using an Installscript project. Yeah, the jury is still out in our group, too. I still prefer it, mostly because I like to be able to use vbscript for install code, but it does have its drawbacks. Regarding being able to dynamically add files to your project, I was not aware that the AI allowed for such a thing, but building projects using it has been quirky for us. We couldn't use 2011's AI to build the projects because it simply wouldn't build. I installed the StandAlone Build product and it builds the project via AI, but I haven't gotten around to putting that into production yet. Bottom line: I'm not quite ready to put my eggs in that basket given that we have a lot of existing code surrounding the command line build. I've said before that some will disagree with me, but I still think a situation like you're in demands components that use Dynamic File Links to determine which files are included. Adding a dedicated component for every file is just a maintenance nightmare in the real world. With that, you can set up Path Variable to point to your pickup folder, update that value each time you run your build script, and it just plain works. I explained it in a lot more detail in this post. ... View more

Others will say that it's not best practice, but you can always set your component(s) to use Dynamic File Linking, such that they pick up all files in a folder at the time of the build. In the Component view, expand your component and click on Files. In the right-side Files pane, right-click and choose Dynamic File Linking. Choose the New Link button to add dynamically added files. ... View more

It's been a while since I've thought about upgrades, so I'm not sure if there's something else to consider regarding your dilemma, but I think you may need to create an Upgrade in your project. It can't hurt, and you'll probably want an Upgrade entry anyway, so I'd advise you to create one and see if that fixes your problem. I'm not sure if there's an online resource that addresses this, but I'll tell you what I have set up and we'll see if it helps. Under the Installation Designer tab, the Media folder, there is an item called Upgrades. When you click on it, you will see Prepare Setup For Upgrade Scenarios, and beneath that Upgrade Windows Installer Setup. If you right-click on the latter and choose Create Major Upgrade, it will then create a new upgrade entry. For now, just leave the upgrade name as it defaults. Under the Common tab in the right navigation pane, the first field (Major Upgrade) will default to "Products having another upgrade code" being selected, but then puts the Upgrade Code from your product (found in General Information) in the field. I'm not sure why it defaults as such, since it seems like that would result in the same behavior as if the other radio button was selected by default. Anyway, for now, don't change it...updating this field will only be relevant to you if end up creating more than one Release for your project. The second field (Product Version) defaults to "Within a specific range of versions", and sets the defaults to beginning at and ending at the current Product Version of your project (found in General Information). My preference is to change this by selecting the "Any earlier version" radio button. That's it. Build your project, and perform your upgrade...hopefully it will update the files on the target server. ... View more

Package For The Web is still a tool that we use...I'm interested to hear what issue(s) you've found with it. ... View more

You're already separating out all other pickup files between the projects, so my suggestion is to also take the extra step to separate the lib files too. If you can make that happen, the rest of what I've written below will fall in place naturally, and you'll be able to a single IS project as your install project by creating two different releases. If you can't, it can still be done, but the picture is muddied a bit. I'm going to take you down the path of creating two Features - one for the application files in the frm, sql, and lib folders - and the other feature for the images that are specific to Product B. Then you'll create 2 Releases - one for Product A and one for Product B - and when you build your packages using IsCmdBld.exe, you'll pass in as arguments to specify what is to be built, and from where it is built. Start by creating your two pickup area paths by clicking Path Variables beneath Media in the left navigation pane. Click on New and give your path variable a name like PickupFolder, or something like that. The Defined Value should be the path to the files to be packaged (i.e. C:\projects\projectB). Now create two Features, one that includes files from the sql, frm and lib folders, and the second includes files from the image folder. In the Release Flags field of each Feature, give each a unique name...something like Images and AppFiles, maybe. Now create the Components associated to each, and add your files. When you do so, you should see something similar to " \frm", which lets you know that your Path Variable is getting utilized to find the files. If it doesn't show as such, then stop, because you won't be able to update this precedent path via IsCmdBld.exe when you build the packages later. Now create your two product packages in the Releases view beneath Media in the left navigation pane. If you've already built the project, you should already have a Configuration, but if not, right-click on Release in the middle navigation pane and choose New Product Configuration and name it ProductA, then create another New Product Configuration and name it ProductB. In the Product Configuration Flags field of ProductA, enter "AppFiles" (to include only that Feature). In this same field of ProductB, enter "AppFiles, Images" to include both Features. From there, create your release by right-clicking on ProductA, choosing New Release, and naming it ProductARelease (or something that makes sense to you). Do the same for ProductB. You'll want to explore the rest of the fields of the Configurations and Releases to ensure the packages are built as you want them. To build each project, utilize command-line build arguments to specify not only the package to be built, but also to location of the pickup folder(s). The product configuration is controlled by the -a flag, the release is specified with the -c flag, and the "l" (as in little) argument controls the Path Variable. So, here's an example command for ProductB: ISCmdBld.exe -a ProductB -c ProductBRelease -l PickupFolder="C:\projects\projectB" Then, when you want to build the Product A, change each flag specific to Product A. (NOTE: If you use Dynamic Linking to add files to your Components, this gets even easier. You can simply create one Feature and one Release, and you can pass in the name of the Product, Version, path for the Path Variable...and you're done!) ... View more

In the Dialogs view of the IS IDE, click on the combobox control that the server\instance appears in during the UI sequence. Determine the Property name assigned to that combobox...it's possible that it's not IS_SQLSERVER_SERVER. When you have that, make sure that you're adding that Property name to CustomActionData so that your Deferred Action will be able to read it. ... View more

liorafar wrote: I want to create new projects on 2011 and keep the old version projects in 10.5 does anyone knows if projects from InstallShield 10.5 and 2011 can be built together and live together without any problems ? Absolutely. However, you might consider converting those 10.5 projects to IS2011. In this thread, you'll see a problem with building an IS2011 project using the Automation Interface when IS2010 was also installed. I also had the same problem with the Build method, but was unable to try the fix (uninstall IS2010), so I use the Automation Interface to modify the ISM (product name/version, path variables, project properties), then use command-line build instead of the AI. This past month I converted most of our existing 10.5 projects into IS2011 projects, and the majority of them were not only simple to convert, but we've had nearly zero problems with the resultant installers. Some of the smaller projects remain IS10.5, and we'll continue to build them on our build server along side our IS2011 projects. The only problem I had with converting the 10.5 projects to IS2011 was one of the projects relies on Maintenance mode to upgrade an existing installation, but after the conversion to IS2011, IS set UPDATEMODE to true instead of MAINTENANCEMODE. That took a while to uncover and fix, but now it works just as it did. ... View more

Executing an MSI after the UI sequence but just before the Execute sequence is something I've done in one of my projects. The notable danger there is that you must keep in mind that it will not be executed during silent installs. ... View more

It's not the greatest situation to get yourself into, but you can make it tenable, for sure. I have taken an existing Wise installation package and wrapped it in an MSI and had great success with it. I use a vbscript custom action to perform prechecks, execute the Wise package, passing it the values it needs to run silently, and also do the other things that were being done manually by our support staff. You'll want to be mindful of other MSIs that might need included in your installation, because creating a wrapper MSI around them will cause you some headache. In that case you may be better off creating an InstallScript project. But yeah, go for it! ... View more

Ah, I see what you're saying now...there's no way to adjust the path to the given Static-linked file. Bummer. Guess you'll need to adjust 2 Path Variables in your build, then... ... View more

You and me both, so don't sweat the ignorance. It's a complex monster, to be sure... You're using Dynamic Links, correct...and is it a MSI or InstallScript project? Maybe I'm assuming incorrectly. Either way, you should just be able to type that value in. When you originally add the component, it may create a new Path Variable for the given component's file pickup path, but I always go back and make sure it makes sense, because it can't know the absolute best way to create the variable. You should be able to type over whatever it assigns as the path variable name, and then adjust your path variables accordingly. ... View more

Ok, so then everything I said applies. Can you not make your Link To path this: \FilesA and \FilesB ? ... View more