InstallSite Blog : Visual Studio

InstallShield LE for Visual Studio 2010 (Beta) now available

stefan — Wed, 09 Dec 2009 21:24:00 GMT

As reported before, Visual Studio 2010 (currently in beta) includes an "InstallShield 2010" project template in the "Setup and Deployment" category. Back then the link didn't work, but now it's live. From the "InstallShield Limited Edition for Microsoft Visual Studio 2010" page you can now download a setup package. Registration is required before you can start the download, and my standard Flexera privacy caveat applies: Anyone who knows your e-mail address can retrieve the other information you entered in this form, like your real name, phone number, company name, city and country.

According to the download page: "InstallShield Limited Edition for Visual Studio 2010 replaces the functionality provided by the Visual Studio Installer tool. It provides a subset of the world-class functionality found in our more advanced InstallShield editions.". Note that installing InstallShield LE doesn't remove the Visual Studio Installer (VSI) project type, but it offers an alternative.

Now the interesting question is what subset of the full InstallShield functionality is included in the Limited Edition, and what has been removed? I haven't seen this officially documented, so here are the most notable differences I found so far. (In this screen shot of Solution Explorer you can see the disabled views marked with a lock symbol)

You are limited to one InstallShield project type, probably the equivalent to "Basic MSI". Other project types like Merge Module, InstallScript or Smart Device are not included.
You cannot customize the Feature structure of your setup. So you are limited to one feature, similar to VSI.
There are no localization options. Multi language setups are only supported in the Premier edition of InstallShield.
Text File Changes and XML File Changes views are disabled.
SQL Scripts and COM registration are unavailable.
Billboards and Support Files can't be specified.
Dependency Scanners are not included (but it's always better to know your runtime dependencies than having a machine trying to guess)
The Patch Design view is also been locked.

While some more important and some less important functionality has been disabled in the Limited Edition, InstallShield LE still offers some advantages compared to Visual Studio Installer:

Prerequiste installation to pre-install packages like the .NET Framework or Internet Explorer 8.
INI File Changes and Environment Variables views.
IIS configuration view.
More dialogs to chose from, but only limited customization options (similar to InstallShield Express).
Slightly more custom action scheduling options, but by far not equivalent to the full InstallShield version. Essentially you can call a custom action at the beginning or at the end of the UI sequence, or in the Execute sequence after RegisterProduct. In VSI you can't insert custom actions in the UI sequence at all.
More customization options for Major Upgrades (in the "Upgrade Paths" view)

Like in the full InstallShield version, the "Update Notifications" view enables you to register your product with FlexNet Connect to send automatic updates to your customers. However this requires a FlexNet Connect account which is sold separately.

InstallShield LE has a wizard to import VSI projects.

To summarize, it looks like InstallShield LE has been tailored to be a replacement for Visual Studio Installer, only adding a limited amount of extra functionality. The big advantage is that you can move to the more powerful InstallShield editions whenever you need the full functionality, without having to start over, and that you are already familiar with the InstallShield user interface. Ideally, the upgrade would simply remove some lock icons from the list of editors in Solution Explorer.

Related information:

Visual Studio 2010 Beta 2 includes link to InstallShield Limited Edition

stefan — Mon, 02 Nov 2009 09:02:26 GMT

Some beta testers of Visual Studio 2010 pointed out that in the New Project dialog there is a new template called "InstallShield 2010". It's listed next to "Visual Studio Installer" under Other Project Types > Setup and Deployment. It's not a real template but only a button labeled "Enable InstallShield Limited Edition" as you can see in the screenshot from the Professional edition of Visual studio 2010 Beta 2:

Clicking this button takes you to another page with some explanation what InstallShield Limited Edition for Microsoft Visual Studio 2010 is, and a button "Go to InstallShield". However the link behind this button isn't (yet?) working, it redirects to the Microsoft homepage.

So it looks like Microsoft and Flexera Software are extending their cooperation to make a limited edition of InstallShield available to Visual Studio users. Users of Microsoft System Center Configuration Manager (SCCM) can already get a limited edition of Flexera Software's AdminStudio at no additional cost.

There is currently no information about the capabilities and limitations of this edition of InstallShield.

While it's good to see that Microsoft is going to offer Visual Studio users an alternative to Visual Studio Installer projects (which are still available) to create Windows Installer (MSI) setups, I'm still sad that they decided not to include the Windows Installer XML toolkit (WiX) with Visual Studio 2010, as they had planned previously. And since Visual Studio 2010 is still in beta, they could even decide not to include InstallShield either.

Speaking of WiX - the WiX toolset now supports Visual Studio 2010 Beta2:

Related information:

Microsoft's recent Security Updates for Visual Studio break Windows Installer Updates

stefan — Sat, 12 Sep 2009 00:30:44 GMT

This problem was brought up in a question on the InstallSite Forum and is also mentioned in a blog post by Gauravb (who appears to be a Microsoft employee).

The typical symptom is missing or not updated files after you install a Small or Minor Update to your application (Major Upgrades are not affected). In the installer log file you'll notice that some features have been switched to "advertised" state and instead of being installed locally. The actual cause is noted in the SELMGR error message in the log similar to this:

SELMGR: ComponentId '{-GUID-}' is registered to feature '-Feature-Name-', but is not present in the Component table. Removal of components from a feature is not supported!

This happens if your setup includes a merge module like Microsoft_VC80_CRT_x86.msm and you rebuilt your setup package after installingsecurity updates 971090 and 973673 for Visual Studio 2005 SP1 or 971092 and 973675 for Visual Studio 2008 SP1. These security updates install newer versions of merge modules.

Apparently a component that existed in the original version of the merge module has been removed in the updated msm. Removing a component is a violation of Windows Installer's rules for Small and Minor Updates.

Affected Merge Modules and GUIDs

Visual Studio 2005 SP1

I examined to merge modules installed by Visual Studio 2005 SP1 and updated by by security updates 971090 and 973673. I found that all of these merge modules are affected by this problem, i.e. they have components removed:

Microsoft_VC80_ATL_x86.msm
Removed 2 components with GUIDs {9B2CAF3C-B0AB-11EC-B01F-C8B3B9A1E18E} and {9B2CAF3C-B0AB-11EC-C01F-C8B3B9A1E18E}
Microsoft_VC80_CRT_x86.msm
Removed 2 components with GUIDs {9BFFB8F8-F55F-10B2-C01F-C8B3B9A1E18E} and {9BFFB8F8-F55F-10B2-B01F-C8B3B9A1E18E}
Microsoft_VC80_DebugCRT_x86.msm
Removed 2 components with GUIDs {583FF03B-A196-24C8-C01F-C8B3B9A1E18E} and {583FF03B-A196-24C8-B01F-C8B3B9A1E18E}
Microsoft_VC80_DebugMFC_x86.msm
Removed 2 components with GUIDs {55141F6E-A388-29A8-C01F-C8B3B9A1E18E} and {55141F6E-A388-29A8-B01F-C8B3B9A1E18E}
Microsoft_VC80_DebugOpenMP_x86.msm
Removed 2 components with GUIDs {8E601675-4F66-A4DE-B01F-C8B3B9A1E18E} and {8E601675-4F66-A4DE-C01F-C8B3B9A1E18E}
Microsoft_VC80_MFC_x86.msm
Removed 2 components with GUIDs {9EE2A7ED-8A13-0C17-C01F-C8B3B9A1E18E} and {9EE2A7ED-8A13-0C17-B01F-C8B3B9A1E18E}
Microsoft_VC80_MFCLOC_x86.msm
Removed 2 components with GUIDs {7831D131-CCF1-43EF-C01F-C8B3B9A1E18E} and {7831D131-CCF1-43EF-B01F-C8B3B9A1E18E}
Microsoft_VC80_OpenMP_x86.msm
Removed 2 components with GUIDs {218504D2-AA7D-7B33-B01F-C8B3B9A1E18E} and {218504D2-AA7D-7B33-C01F-C8B3B9A1E18E}
policy_8_0_Microsoft_VC80_ATL_x86.msm
Removed 1 component with GUID {6967BA9D-3E8C-8E05-C01F-C8B3B9A1E18E}
policy_8_0_Microsoft_VC80_CRT_x86.msm
Removed 1 component with GUID {671DDE41-A620-9193-C01F-C8B3B9A1E18E}
policy_8_0_Microsoft_VC80_DebugCRT_x86.msm
Removed 1 component with GUID {5A7EB616-E2EE-6D78-C01F-C8B3B9A1E18E}
policy_8_0_Microsoft_VC80_DebugMFC_x86.msm
Removed 1 component with GUID {5D61A50B-77A2-68DD-C01F-C8B3B9A1E18E}
policy_8_0_Microsoft_VC80_DebugOpenMP_x86.msm
Removed 1 component with GUID {8506B23C-BABD-5C8B-C01F-C8B3B9A1E18E}
policy_8_0_Microsoft_VC80_MFC_x86.msm
Removed 1 component with GUID {6BEC5B24-C056-8A14-C01F-C8B3B9A1E18E}
policy_8_0_Microsoft_VC80_MFCLOC_x86.msm
Removed 1 component with GUID {D5A7A18A-DEA5-8DD7-C01F-C8B3B9A1E18E}
policy_8_0_Microsoft_VC80_OpenMP_x86.msm
Removed 1 component with GUID {07EE8801-38A9-ABAC-C01F-C8B3B9A1E18E}

Visual Studio 2008 SP1

I also examined to merge modules installed by Visual Studio 2008 SP1 and updated by by security updates 971092 and 973675. I found that all of these merge modules are affected by this problem, i.e. they have components removed:

Microsoft_VC90_ATL_x86.msm
Removed 4 components with GUIDs {2F605F26-3021-38F6-AC31-175C0DFA59B9}, {76C3F0F6-9B9D-35DA-81C6-CA8A88CC93CA}, {DBD31579-020A-349E-8ED6-D06FEA75AF45}, and {86226397-23DB-3430-8C8A-AEA661B1AE77}
Microsoft_VC90_CRT_x86.msm
Removed 4 components with GUIDs {AEC90EFE-39B8-3978-8A5D-068FEF83D275}, {B708EB72-AA82-3EB7-8BB0-D845BA35C93D}, {1A5C156B-3CC3-36E3-BAD7-9FD0D48156D3}, and {68D7E2DF-5BC5-318C-AF19-19D1D29ED692}
Microsoft_VC90_DebugCRT_x86.msm
Removed 4 components with GUIDs {58425F02-9D68-3D93-85D9-39B29E29BC7B}, {BAD864A4-C2C0-3C54-8964-B268B7016DEC}, {FC82857E-2B1F-3E92-A906-97FD9825D3C7}, and {0BDD8003-3267-389F-813F-AD12EC5DC534}
Microsoft_VC90_DebugMFC_x86.msm
Removed 4 components with GUIDs {F0A00871-E0E2-32B2-A659-FE4DA7002A2D}, {342BA686-A9E6-3FB4-AFC0-7034FF188D52}, {7E7F1AD6-F52E-3AE6-BAA5-32B96EE05F4E}, and {B833CE77-211C-355F-9DBB-294FD746EF17}
Microsoft_VC90_DebugOpenMP_x86.msm
Removed 4 components with GUIDs {5586775C-EA44-30E2-A3E2-5C50F4EA39A0}, {B0C784B6-DDCC-3D69-A33A-5DE42951883C}, {E59B8FDA-55AE-3049-96FC-606E8C5BF2BE}, and {8FD717AF-E0E2-365E-8445-AECD9A21E5A0}
Microsoft_VC90_MFC_x86.msm
Removed 4 components with GUIDs {D01CBF08-20B4-30C8-AF5A-96F9847E82A3}, {C6357C55-7461-3D51-9AE5-FD71CA24027A}, {611881C8-BE2F-393E-A04F-81C63DF00851}, and {15F67BFD-D6AA-3C8B-A1BB-C33E17E925C6}
Microsoft_VC90_MFCLOC_x86.msm
Removed 4 components with GUIDs {5A06E1CC-89C9-3DB9-9BC8-5BFA56B58BFB}, {FF2F571A-6C54-31E3-B23E-2A60283B08A8}, {C9F2C40F-28CD-392C-A0C3-3AADEC130C0A}, and {4D8012CE-B2CE-3493-91B8-B8A9B982F6B8}
Microsoft_VC90_OpenMP_x86.msm
Removed 4 components with GUIDs {A85D53AA-906D-31C5-96E3-E21BB9154E2C}, {D511F4F3-A911-32CF-AC11-9C97EF948BFC}, {B16F86FC-BD94-30FA-98AA-17ABE54F0478}, and {28B6B10C-E41F-302B-A673-01F436427522}
policy_9_0_Microsoft_VC90_ATL_x86.msm
Removed 2 components with GUIDs {A62CCE52-C380-3111-BA7D-3D0EDFA31213} and {C2FCD113-35CA-3027-92CD-F2D646277CA1}
policy_9_0_Microsoft_VC90_CRT_x86.msm
Removed 2 components with GUIDs {14F2B62D-DF5F-335F-A517-0991F44CB087} and {0355F5D0-467C-30E9-894C-C2FAEF522A11}
policy_9_0_Microsoft_VC90_DebugCRT_x86.msm
Removed 2 components with GUIDs {C990308F-4696-3069-B753-AB178CE2007B} and {FBB763D7-1B85-36C2-B127-4577B3FC45A1}
policy_9_0_Microsoft_VC90_DebugMFC_x86.msm
Removed 2 components with GUIDs {9B8A0715-C004-3493-8350-A387E1163D46} and {9EC89F44-FA15-308D-8582-22744424F0CF}
policy_9_0_Microsoft_VC90_DebugOpenMP_x86.msm
Removed 2 components with GUIDs {A134D5FD-99B1-3230-89AC-C4F81B697BFC} and {19185A82-2047-34BF-BBE1-5E64579BE356}
policy_9_0_Microsoft_VC90_MFC_x86.msm
Removed 2 components with GUIDs {6BFBB2DC-4F78-3217-ACCF-CD2838A84621} and {12EA53B4-340A-3F5D-B1BC-4A3BEC4A89A7}
policy_9_0_Microsoft_VC90_MFCLOC_x86.msm
Removed 2 components with GUIDs {0FEBA8D0-5D22-3D3A-947D-559E29BF07DF} and {6F026C46-D6BC-3805-A3B0-117AF8473928}
policy_9_0_Microsoft_VC90_OpenMP_x86.msm
Removed 2 components with GUIDs {8D71CE57-BDC3-34B0-ADAD-EA4C5AFC9664} and {649A198A-C19D-325F-BF3A-C7EAE62F5EF6}

Workarounds

This means that if your setup includes any of these merge modules, the security update prevents you from shipping Small or Minor Updates.The workaround I'd recommend is using a Major Upgrade (i.e. change the ProductCode and add an entry in the Upgrade table) to update your application.

Gauravb's blog lists some other workarounds which I don't think are feasible:

Use the VC Redistributable Installer EXE package to install the runtime instead of the merge modules. - Good advice for new packages or Major Upgrades, but you can't remove the merge modules from your package in a Small or Minor Update.
Use the old verion of the merge modules, - This means you would knowingly be installing a vulnerable file on your customer's computer.

Another potential workaround would be to add dummy components to your msi setup with the same GUIDs as the components that were removed from the merge modules. But that could cause conflicts with other msi files that include the original version of the module.

No joke – WiX will NOT Ship with Visual Studio

stefan — Fri, 03 Apr 2009 04:07:00 GMT

Several months ago, Microsoft had announced that the next version of Visual Studio (Visual Studio 2010, code name Rosario) will ship with a subset of the Windows Installer XML Toolkit (WiX). But on April 1st, 2009, Rob Mensching, the WiX project lead, had bad news to announce on his blog: “Visual Studio will not ship the WiX toolset, contributes only”.

Given the date, and since Microsoft officially had announced WiX in Visual Studio and CTP pre-releases of Rosario included WiX, I assumed that this was an April Fool’s joke. Unfortunately, it is not.

I don’t know what the exact reasons were for this unexpected decision, so I can’t really judge. But I think that it’s a lose-lose situation. Visual Studio won’t ship with an advanced Windows Installer authoring tool. And the open source WiX project won’t be “blessed” as a product that’s backed by Microsoft support.

The good news is that WiX will continue to work with and integrate in Visual Studio, and that the work that the Visual Studio team has contributed to the WiX project isn’t lost but will help to finalize WiX 3.0.

Let’s hope that the disappointment that this decision probably has caused in the team will not stop their enthusiasm.

Deploying VSTO Office Add-Ins with Windows Installer

stefan — Fri, 01 Aug 2008 10:38:05 GMT

If you are creating Office add-ins you may find this two-part MSDN article useful. It describes how to install add-ins created with Visual Studio Tools for Office (VSTO) using Windows Installer. The article uses Visual Studio to create the MSI.

InstallShield Support for Visual Studio 2008, .NET Framework 3.5 and VC++ 9

stefan — Thu, 03 Jan 2008 18:16:06 GMT

Macrovision released updates for InstallShield 2008 to support integration with Visual Studio 2008 and redistribution of the .NET Framework 3.5 and VC++ 9 runtime files:

These updates are only available for InstallShield 2008, but not for previous versions (although the .NET 3.5 prerequisite and the VC++ merge modules may work with other InstallShield versions)

Microsoft to "productize" WiX

stefan — Mon, 26 Nov 2007 23:20:36 GMT

Rob Mensching reports that Microsoft will include a sub-set of the Windows Installer XML toolkit (WiX) in the next version of Visual Studio, code named Rosario. WiX is an open source project for authoring of Windows Installer (MSI) setups. While Microsoft employees played an important role in the WiX project from the beginning, they did this in their free time.

But now Microsoft staffed a number of full time developers to fix bugs in WiX version 3 and to further improve its integration in Visual Studio. The work of these developers will be fed back into the open source project. With the release of "Rosario" (not before the end of 2008) Microsoft will also provide technical support for WiX.

However WiX will not replace Setup & Deployment projects in Visual Studio - at least not in this release. That's because WiX has a steep learning curve and there are currently no visual designers for WiX. So I guess a significant fraction of developers is still going to prefer the seemingly easy to use (but also quite limited) S & D projects.

Maybe it would be a good idea to have these visual designers generate WiX code, so developers can easily move to the full power of WiX when needed, without starting over. Something like the ClickThrough idea in WiX.

Applause to the WiX team who brought the project thus far (and plans to bring it even further), to the Visual Studio team for moving into the right direction, and to Microsoft for progressing their open source engagement (which I believe was not easy for the company, and in which Rob Mensching also played an important role)!