Opening InstallShield Projects in Microsoft Visual Studio

[Richard_Winks]

I have MSVS 2010 and IS 2012 Spring SP1 installed.

If I am interpreting this correctly, according to the help document I should be able to open my .ism project (created in IS 2012 Spring SP1) in MS VS IDE by going to Open>Project browse to .ism and open it.

The .ism doesn't show up in the browser.

Because I deal with some legacy installations I also have IS 2011 installed.

I would like to add this existing project to my solution without having to remake the entire thing.

Am I missing something here?

Richard

[Shuttledude]

1. Open your Visual Studio *.sln file.

2. In Solution Explorer, right-click on the *.sln (the solution, at the top of the Solution Explorer window).

3. From the pop-up menu choose Add / Existing Project.

4. Windows Explorer will open, navigate to the InstallShield *.ism file and click Open.

5. This will add the InstallShield project to your Visual Studio solution. You will see the new project in the Solution Explorer.

6. Now whenever you build the solution you will also compile the InstallShield project. You can choose to exclude building the InstallShield project if you wish, for example use the Visual Studio Configuration Manager to de-select the InstallShield project when building in Debug mode.

7. Note that this automatically creates a "bridge" project, *.isproj, which is in the same directory as the *.ism project. The *.isproj project "ties together" the Visual Studio *.sln and the InstallShield *.ism.

[Richard_Winks]

That does the trick.
Thanks

Richard

[Kelter]

In my case, (1)I don't really like using VS as an IS editor, (2)Developers don't have licenses for IS, and (3)I don't want to maintain dependency relationships among projects in more than one location; therefore (1) I don't add the .isproj to the solution, (2) i create a .vcxproj for each .ism instead (this is a lazy way to create a custom msbuild script. Just create a new "makefile" project in VS), (3) I add the .vcxproj to my main solution file, and set up project dependencies to enforce the build order. I then duplicate the "Release" configuration in the solution and name it "Release-Package." The difference between these configurations is that Release doesn't build deployments.

This way i don't have to maintain the dependency relationships in multiple locations, I just use one solution for the build. Users without IS on their machines can still open the solution, and they'll only get errors if they try to build the "Release-Package" configuration. Also, with .isproj files included, the solution takes longer to open.

I tend to just use one configuration and build in the .ism file, and i make everything else about the build generic enough that the build command line doesn't vary by anything but the project name. therefore all of my .vcxproj's have this as a build command line:

"$(IS_CMD_BLD)" -v -p "$(ProjectDir).\$(ProjectName).ism" -r "Release" -c COMP -a "Configuration" -o "$(OutDir)MergeModules" -prqpath "\SetupPrerequisites,\..\Prerequisites"

I don't know if that'll work for you, but it works for me. Also, I don't remember if I had to create the IS_CMD_BLD environment variable or if it gets created when you install IsCmdBld.

[Richard_Winks]

Actually, this is how I have been doing my builds for years. I'm just trying to get everything under a single solution for my TFS builds without relying on a lot of customized build steps.

Richard