Setup Related Blogs

This page collects content from several weblogs that are related to installation topics. You can also find some headlines on the InstallSite homepage, but this page has more articles from more blogs and also displays the article content. If you know of a blog that you think should be added here, please drop me a note.

Stefan Krueger (InstallSite.org)

RSS

InstallSite Blog

by Stefan Krueger [go to blog]

InstallShield 2011 Released, Changes to Stand-Alone Build Module Licensing

[ posted 2010-08-19 | go to article ]

Today, Flexera Software released InstallShield 2011, their flagship product to create setups using Windows Installer (MSI) or InstallScript technologies, and virtual application packackes for Microsoft App-V.

Highlights of this release:

While some of these may not seems like a big deal, they are practical improvements. For instance, many users have been asking how to use their own icon for the setup.exe file instead of InstallShield's standard icon. Also the pre and post build events could be very handy, especially the "in between" event which enables you to run an external command after the setup has been created but before it is packaged into the self extracting exe.

InstallShield 2011 is available in Premier, Professional and Express editions. The Limited Edition which is available free of charge to Visual Studio users has not been updated yet.

Stand-Alone Build Engine Returns to InstallShield Professional

The Standalone Build Module enables developers to automate installation builds and and integrate them with their product builds. It is installed and run on clean machines separate from the InstallShield IDE, and includes only the part of InstallShield that builds the installation.

Some years ago, the InstallShield Build Engine (SAB) was included with InstallShield Premier and Professional. But with the release of InstallShield 12 in the year 2006 the SAB was removed from the Professional tier, so anyone who needed the SAB had to purchase the Premier edition. (Existing customers were grandfathered with rights to use the SAB until the release of InstallShield 2009, two years ago.) This decision was strongly criticized back then.

Today the Stand Alone Build module returns to the Professional edition: Users buying InstallShield 2011 Professional also get one SAB license.

On the other hand, the number of SAB licenses included with the Premier edition was reduced from 10 to 5 (but customers with an active maintenance plan are grandfathered to 10 SAB licenses, so they don't lose anything).

Stand Alone Build Module now available separately

If the included SAB licenses aren't enough for your scenario, you can now buy additional SAB licenses separately. They are available as single licenses and as team bundles with 10 or 30 licenses.

Changes also in the way SAB licenses are enforced: In contrast to the InstallShield IDE which requires activation over the internet, the SAB uses a license file. Customers can generate such license file in Flexera Software's web portal by entering a unique ID of the build machine (I think the network card's NIC number). This license file can then be transferred to the build machine over the internal network or a USB stick, so you don't have to expose your build machine to internet threats.

End of Life for InstallShield 2008 announced

Not surprisingly, with the release of the new version Flexera Software also announced the end of life for the oldest version that is currently supported. Essentially this means that owners of InstallShield 2008 can upgrade to the latest version until November 30, 2010. After that date InstallShield 2008 is no longer eligible for upgrade pricing and they would have to pay the price of the full license. (This doesn't apply to the German edition of InstallShield 2008 which has been discontinued in 2009.)


InstallShield can be purchased from the InstallSite Shop at http://www.installsite.biz/installshield.htm

Bookmark and Share

Links of the Week 31

[ posted 2010-08-08 | go to article ]

Here are links to some articles that I came across during the past week, calendar week 31:

InstallShield, AdminStudio, InstallAnywhere Special Offers extended until 30th July

[ posted 2010-07-05 | go to article ]

Flexera Software announced that the special offers which originally expired on 30th June will be extended for one month, until 30th July (actually they say 31st July but that's a Saturday). This applies to the following offers:

More information about eligible products and versions can be found in the InstallSite Shop at http://www.installsite.biz 

Bookmark and Share

Microsoft's Windows Installer Cleanup Utility no longer available

[ posted 2010-06-28 | go to article ]

The Windows Installer CleanUp Utility (MSICUU) was a last resort to work around problems with broken or partially installed Windows Installer (MSI) packages if the regular measures like uninstalling from Add/Remove Programs control panel have failed. Officially it was available to fix broken installations of Microsoft Office but could be used for any msi based install.

Unfortunately many web sites recommended the tool as a simple way to fix any msi problems, and some users damaged their operating environment by misusing the Windows Installer CleanUp Utility.

As reported by The Windows Club two days ago, Microsoft has removed the MSICUU download from their web site. Knowledge base article 290301 has been updated with the following notice:

This article previously contained a link to the Windows Installer Cleanup utility (MSICUU2.exe). If you were directed to this article to solve a problem installing a product other than Microsoft Office, please contact your software manufacturer for installation support on the product.

While the Windows Installer Cleanup utility resolved some installation problems, it sometimes damaged other components installed on the computer. Because of this, the tool has been removed from the Microsoft Download Center. The Fix it Solutions in this article provide the ability to fully remove Office 2003, 2007 and 2010 suites without damaging other Windows components.

Instead of the Windows Installer CleanUp Utility the knowledge base article now includes "Fix It" tools in the form of msi packages to safely remove broken installations of Office 2003, 2007 and 2010. Since the Fix It tools are packaged as msi files, this won't help in situations where you can't run any msi setup.

MSICUU could also be used to clean the Windows Installer cache from msi files that were no longer needed because the software had already been uninstalled. This could be useful in low disk space situations. I don't know if the mentioned problems also apply to this use of the tool.

Bookmark and Share 

Advanced Installer 7.7 adds full support for Visual Studio 2010 and .NET Framework 4.0

[ posted 2010-06-24 | go to article ]

On June 17th, 2010 Caphyon Ltd. announced the release of Advanced Installer 7.7.

This release adds full support for the latest Microsoft development tools: Visual Studio 2010 and .NET Framework 4.0. The included Installer Repackager has also been improved: It will now detect and preserve high-level constructs like services, drivers, file associations, environment variables and assemblies in scan results. Also new is the ability to create installer packages for Visual Studio add-ins from the Advanced Installer IDE.

Owners of Advanced Installer can get updates free of charge within 6 months after purchase, or as long as they have an active maintenance plan.

Advanced Installer is licensed on a per developer basis and can be installed on multiple machines. It is available in four editions, starting with the Freeware community edition and offering a 30-day trial period for the other editions.

For more information and to purchase Advanced Installer please visit the InstallSite Shop at http://www.installsite.biz/advancedinstaller.htm.

Bookmark and Share 

InstallAnywhere and InstallShield Multiplatform Upgrade Offer

[ posted 2010-06-16 | go to article ]

Yet another special offer from Flexera Software:

Users of any previous version of InstallAnywhere (including end-of-life versions) and even from the discontinued InstallShield Multiplatform can get 20% off the upgrade price to InstallAnywhere 2010.

Note that upgrade eligibility for InstallAnywhere 2008 will end on 30th November 2010, so owners of that version may want to upgrade now instead of later.

This offer expires June 30, 2010.

 

Windows Installer Team (Microsoft)

Windows Installer Team Blog

[go to blog]

Developing for Windows 7

[ posted 2009-09-11 | go to article ]

 

I recently came across several resources that are available from Microsoft to help developers get their applications ready and shining on Windows 7! Since these resources are scattered in several places, I thought it would be beneficial to have a post with a compilation of these. So here you go…

1.       Training Kit for Developers (Windows 7 RTM version)

This kit includes presentations, hands-on labs, and demos designed to help you learn how to build applications that are compatible with and shine on Windows 7 by utilizing key Windows 7 features. You can find topics such as: Taskbar, Sensor and Location, Libraries and Shell, DirectX, Multi-touch, Ribbon, etc. The kit is built for both native Win32 C++ developers and .NET developers. The kit also includes Application Compatibility labs for: Version Checking, Data Redirection, UIPI, Installer Detection, Session 0 Isolation, and High DPI, to help you get over the most common application compatibility issues.

Available for download on Microsoft download center.

 

2.       Application Quality Cookbook

This Cookbook provides you with the means to become familiar with how to verify the compatibility of your applications with the new operating system and provides an overview of the few known application incompatibility issues in Windows 7 and Windows Server 2008 R2. But more than that, it also points out differences in performance, reliability, and usability, and provides links to detailed white papers and other developer guidance.

You can download the complete version (available in .docx and .xps formats) of the Application Quality Cookbook from its location on Code Gallery.

 

3.       Developer Guide

The Windows 7 platform makes it easy for developers to create engaging, user-friendly applications by providing familiar tools and rich development features that allow them to take advantage of the latest PC capabilities. This guide summarizes the key developer advances in each of the following three areas:

·         Solid Foundation

·         Richer Application Experiences

·         The Best of Windows and the Web

You can download the Windows 7 version of the Developer Guide (available in .docx and .xps formats) from its location on Code Gallery.

 

4.       Application Compatibility

If you are facing Compatibility problems with your applications on Windows 7, here are some excellent application compatibility resources to get you started!

·         Application Compatibility Factory (ACF) Program – Helps customers identify and resolve potential compatibility issues they may face when migrating desktops and applications to Windows 7.

·         Windows XP to Windows 7 Migration – Tools and resources available from Microsoft to help you each step along the way when migrating from a Windows XP environment to Windows 7.

·         Microsoft Application Compatibility Toolkit 5.5 – contains the necessary tools and documentation to evaluate and mitigate application compatibility issues before deploying Windows 7.

·         Win7 App Compat FAQ for developers

·         MSDN forum Application Compatibility for Windows Development

 

5.      The Windows 7 Blog for Developers

A blog focusing mainly on the developer aspects of Windows 7.

[Author: Zainab Hakim]
This posting is provided "AS IS" with no warranties, and confers no rights. Use of included script samples are subject to the terms specified at
http://www.microsoft.com/info/cpyright.htm.

Windows 7 Taskbar support with the MsiShortcutProperty table

[ posted 2009-09-03 | go to article ]

Starting with Windows 7, Windows Installer enables native support for setting properties on shortcuts created during installation or re-installation. The MsiShortcutProperty table can be used to set any property defined by the IPropertyStore interface.

In order to use the new table, you need to specify the PropertyKey and PropVariantValue for the shortcut you want to set the properties on (you can set multiple properties on a shortcut). The properties allowed are the ones registered in the current property schema. The system-supplied properties are defined in propkey.h: many of them are new in Windows 7. Properties supplied by 3rd parties are also supported, as long as they have been registered with the schema subsystem (for eg. via PSRegisterPropertySchema). 

You can use string representations for both – e.g. System.AppUserModel.ID for the PropertyKey PKEY_AppUserModel_ID, and a corresponding string representation for the PropVariantValue. Windows will automatically coerce the value to the correct type.

MsiShortcutProperty

Shortcut_

PropertyKey

PropVariantValue

AppIDProperty

OrcaNT.406D93CE_00E9_11D2_AD47_00A0C9AF11A6

System.AppUserModel.ID

Microsoft.WindowsInstallerTools.Orca

PreventPinningProperty

OrcaNT.406D93CE_00E9_11D2_AD47_00A0C9AF11A6

System.AppUserModel.PreventPinning

0

These properties are consumed by shell, not windows installer.

Examples:

1.       Allow an app to glom onto its shortcut on the taskbar

System.AppUserModel.ID property in Windows 7 defines an AppUserModelID. Applications can use this property to group its windows together with the shortcut on the Windows taskbar. This means that if the application sets an AppUserModelID in its process, and same AppUserModelID in the shortcut, then when the shortcut is pinned to the taskbar and the application is launched from it, the application icon will group together with the shortcut. This property is particularly useful for applications that wish to override the taskbar’s default grouping and unification – apps running under a host process, or an app that owns several different processes. PropertyKey, PropVariantValue that you would author in the MsiShortcutProperty table of your package would be “System.AppUserModel.ID” and “CompanyName.ProductName.SubProduct”, respectively.

2.       Prevent pinning of shortcuts

Setting “System.AppUserModel.PreventPinning” property to “1” prevents a shortcut from being pinned to the taskbar.

FAQs

Q: Is there a new standard action that I need to schedule?

A: No, setting of shortcut properties will be a part of the CreateShortcuts standard action.

 

Q: Can I set properties on shortcuts that are not a part of my installation?

A: No, you can only set properties on shortcuts created by your installation.

 

Q: What happens if the setting of a property fails?

A: If Windows Installer fails to set a shortcut property, it will return a warning and the installation will continue.

 

Q: What happens on downlevel platforms?

A: This functionality is only available on Windows Installer 5.0 and above. The MsiShortcutProperty table – if present – is ignored on Windows Installer 4.5 and below.

 

[Author: Ashish Awasthi]
This posting is provided "AS IS" with no warranties, and confers no rights. Use of included script samples are subject to the terms specified at
http://www.microsoft.com/info/cpyright.htm.

 

Heath Stewart (Microsoft)

Heath Stewart's Blog

About Windows Installer, the .NET Framework, and Visual Studio. [go to blog]

Comparison of PatchWiz and WiX v3 Patch Build

[ posted 2010-08-24 | go to article ]

The Windows Installer SDK ships a library named patchwiz.dll. This contains the logic to build a patch from pairs of database packages (.msi files, or simply MSIs) along with other configuration properties. Another tool that the SDK ships is msimsp.exe which uses patchwiz.dll and parses command line options. These tools consume an input file with the same format as a database package but with a different set of tables. This is known as a PCP file (because of the .pcp extension).

When we started planning a patch build system for Windows Installer XML (WiX), we considered building a new system that is completely under our control but without using any undocumented APIs or formats. The result was the WiX patch build system that first shipped in version 3.0 and is used by many divisions and other groups throughout Microsoft.

Even while WiX v3 retains the ability to build PCP files for use with patchwiz.dll, it provides new support using the <Patch> element a two tools: torch.exe and pyro.exe, which builds transforms and patches respectively. This gives us the ability to add validation for common problems and the ability to easily filter most changes, though you need to fragment your authoring properly.

The following table is a comparison of patchwiz.dll and the WiX patch build system.

Feature PatchWiz WiX
Ignore certain files to be upgraded by the patch. Yes Yes
Ignore certain other resource types to be upgraded by the patch (ex: registry values, components, etc.).   Yes
Produces binary delta patches. Yes Yes
Creates patches between MSIs. Yes Yes
Maintains relationships between groups of authored resources (ex: files and registry values in the same fragment).   Yes
Supports authoring of validation flags. Yes Yes
Supports authoring of error flags.   Yes
Consumes tertiary MSIs to include additional data in the patch transform. Yes  
Produces easily parsable output for diagnosing authoring issues.   Yes
Can automatically extract compressed files when creating transforms.   Yes

What’s more, if you’re already building with WiX 3.0 or newer, you already have these tools.

Visual Studio 2010 Uninstall Utility

[ posted 2010-08-24 | go to article ]

While we hope you’ll love Visual Studio 2010 for all the application development it enables with powerful features and a robust extension model that enables great extensions like the Productivity Power Tools, if you ever need to uninstall Visual Studio it can be difficult. If you’ve ever tried to remove Visual Studio you already know this.

But have a tool that can help for English installations: the Visual Studio 2010 Uninstall Utility.

An excerpt from that page reads,

Default (VS2010_Uninstall-RTM.ENU.exe)
Uninstalls all top level products of 2010 release and its supporting components. This mode does not remove Visual Studio components shared with previous product releases (e.g. Visual Studio 2008) or system level updates such as Microsoft .NET Framework 4.0.

Full (VS2010_Uninstall-RTM.ENU.exe /full)
Removes Visual Studio 2010 and supporting products, including components shared with previous versions of Visual Studio. Note: may break features of previous versions of Visual Studio installed on the machine. This option does not remove Microsoft .NET Framework 4.0 from the machine.

Complete (VS2010_Uninstall-RTM.ENU.exe /full /netfx)
Removes entire set of Visual Studio 2010 and supporting products, including Microsoft .NET Framework 4.0 and components shared with previous versions of Visual Studio. Note: may break features of previous versions of Visual Studio or other products taking dependency on Microsoft .NET Framework 4.0.

For other languages or editions, you can remove the packages in manual order from Add/Remove Programs (Programs and Features).

Customizing Shortcuts for Visual Studio

[ posted 2010-08-22 | go to article ]

After installing the last several releases of Visual Studio, you’ll find shortcuts to command prompts that automatically set up the PATH, INCLUDE, LIB, and other environment variables. At least with Visual Studio 2010 these command prompts have larger buffers and enable quick edit mode, but some people like to customize these shortcuts to their liking.

Since Visual Studio installs for all users, these shortcuts are protected and can only be edited by administrators. In Windows 7 you are simply prompted to elevate; however, in Windows Vista with UAC enabled, when you try to edit the shortcut you may see the following error message.

Error Updating Shortcut

Unable to modify the shortcut: C:\ProgramData\Microsoft\Windows\Start Menu\Programs\Microsoft Visual Studio 2010\Visual Studio Tools\Visual Studio Command Prompt (2010).lnk.
Check to make sure it has not been deleted or renamed.

OK

To customize the shortcut, you should copy it to a user-writable location. You should not modify the protected shortcut as that could cause it to be left behind if you ever uninstall Visual Studio. But rather than have a second entry in your Start Menu you can keep the same name and it will show up instead of the per-machine copy.

  1. Find the shortcut. The easiest way is to just press the Start button and type “Visual Studio Command Prompt”.
  2. Right click and select Copy.
  3. Right click on All Programs at the bottom of the Start Menu and select Open.
  4. Double click to open Programs.
  5. Click on the Organize button and select Paste.
  6. Right click on the shortcut and select Properties.
  7. Edit any of the properties you want, but do not change the name of the shortcut. For example, you can change the screen height to 60.
  8. Click OK to save the changes.

Now whenever you launch the shortcut from the Start Menu, you’ll be starting your copy with your changes. You’ll still need to delete your copy if you ever uninstall Visual Studio but now you can make all the changes you want without having to elevate.

Detection keys for .NET Framework 4.0 and Visual Studio 2010

[ posted 2010-05-05 | go to article ]

Now that Microsoft .NET Framework 4.0 and Visual Studio 2010 have been released, developers may wonder how to detect them on the system. As with previous releases, we support registry detection of either product family and Windows Installer component detection for Visual Studio. Detecting either product uses a separate set of supported keys.

.NET Framework 4.0

The .NET Framework has and continues to use registry keys and values under HKLM\Software\Microsoft\NET Framework Setup. To detect .NET Framework 4.0, you can check if the following key is present and the value is set to 1.

Key HKEY_LOCAL_MACHINE\SOFTWARE\Microsoft\NET Framework Setup\NDP\v4\Client
Name Install
Type REG_DWORD (32-bit integer)
Data 0x00000001 (1)

The core .NET Framework 4.0 package is English, so 1033 is always available. To detect specific language support, see the LCIDs listed in the table of supported languages. You can also detect if the full package is installed, which includes the core (Client) and extended support, such as ASP.NET.

Key HKEY_LOCAL_MACHINE\SOFTWARE\Microsoft\NET Framework Setup\NDP\v4\Full
Name Install
Type REG_DWORD (32-bit integer)
Data 0x00000001 (1)

For more information, see the .NET Framework 4.0 deployment guide for developers. Administrators may be interested in the .NET Framework deployment guide for administrators.

Visual Studio 2010

The detection keys for Visual Studio are used both to detect if the product is installed and what service pack level is installed. As with previous versions, these keys and values are under HKEY_LOCAL_MACHINE\SOFTWARE\Microsoft\DevDiv\VS\Servicing.

Key HKEY_LOCAL_MACHINE\SOFTWARE\Microsoft\DevDiv\VS\Servicing\10.0\$(var.ProductEdition)\$(var.LCID)
Name Install
Type REG_DWORD (32-bit integer)
Data 0x00000001 (1)

The values for $(var.ProductEdition) include the following table. The for other products, this value corresponds to the ProductEdition property in the Property table of the Windows Installer package for that product. The locale IDs for $(Var.LCID) are listed here.

Visual Studio 2010 Ultimate VSTSCore
Visual Studio 2010 Premium VSTDCore
Visual Studio 2010 Professional PROCore
Visual Studio 2010 Shell (Integrated) IntShell

For Dev10 we have also added detection values to the edition keys so that you do not have to detect every single language for ever edition.

Key HKEY_LOCAL_MACHINE\SOFTWARE\Microsoft\DevDiv\VS\Servicing\10.0\$(var.ProductEdition)
Name Install
Type REG_DWORD (32-bit integer)
Data 0x00000001 (1)

These registry keys and values are also used to detect the service pack level. Instead of checking for the Name registry value, check the SP registry value. Ignore SPIndex; Microsoft uses this internally. In addition to the registry keys above, we also set a version-dependent registry value listed below.

Key HKEY_LOCAL_MACHINE\SOFTWARE\Microsoft\DevDiv\VS\Servicing\10.0
Name SP
Type REG_DWORD (32-bit integer)
Data 0x00000001 (1)

Keep in mind, however, that as with all shared resources the more shared a resource is the less accurate it may be. This is because there is no version policy for registry values and other resources that do not have versions like text files. If two languages were installed at different servicing pack levels – which is unsupported but possible – the value would be set by the last product to be installed or reinstalled (repaired).

For more information, see the Visual Studio 2010 detection system requirements. This also includes information to use the CompLocator in your Windows Installer package as an alternative to registry detection.

Major Upgrades with Shared Components

[ posted 2010-04-09 | go to article ]

Major upgrades are Windows Installer products that can be installed like any other product with the added benefit of removing one ore more related products. For example, version 2 of a product can be installed on a clean machine, or on a machine with version 1 already installed and will remove version 1.

When another version of a product is removed depends on where you schedule RemoveExistingProducts. If you schedule the action late – either before or after InstallFinalizeshared components are a potential factor when developing your product installation. But before going into detail, let’s first discuss what major upgrades really are.

A common misconception is that major upgrades occur when the UpgradeCode is the same. The fact is that the UpgradeCode is only a minor detail for major upgrades. It’s really more of a related or family code. One product may upgrade any number of products regardless of whether their UpgradeCodes are the same. The Upgrade table is used to list all of the UpgradeCodes for products that may be upgraded, while the FindRelatedProducts action is responsible for using that information to gather all related products identified by their ProductCodes. RemoveExistingProducts uses that list of ProductCodes and runs a nested uninstall for each.

As the FindRelatedProducts action name denotes, the UpgradeCode is mainly used to relate different products. This is also evident with the MsiEnumRelatedProducts function. But without scheduling the RemoveExistingProducts action, that’s really all those products are even if the UpgradeCode is the same: related products.

Scheduling RemoveExistingProducts early is a safe way to perform a major upgrade. All the older products are removed first and you have flexibility to do things in your product deployment that may not be allowed in small updates or major upgrades. But doing so is also inefficient if the product composition really doesn’t change much or many of the files aren’t updated. You’ll be uninstalling one or more products in full and laying bits back onto the machine. If you have many of the same file versions, it may be more efficient to schedule RemoveExistingProducts later.

If you schedule RemoveExistingProducts later, however, you must consider the impact of shared components. This is because until RemoveExistingProducts actually executes, two or more products with the same components are installed. And since you should never change the GUID of a component that shares the same installation location, that means there are now shared components – components with a reference count of two or more (depending on how many products have installed those components to the same locations).

Imagine that you ship a component with GUID {788FAC73-431F-41AF-BF72-9AB2AE74DB4E} that installs files foo.dll and bar.dll. Already this is not the best component design since you’re installing two files – two versioned files to be exact – in the same component, but it helps illustrate the point. If another product installs the same component with GUID {788FAC73-431F-41AF-BF72-9AB2AE74DB4E} to the same location then that component is now a shared component with a reference count of two. If foo.dll wasn’t actually upgraded, the Windows Installer does not copy the file again but does install the component only to increase the reference count. This is why scheduling RemoveExistingProducts late is more efficient: potentially less disk I/O.

But this also raises the key point: because the other product – a newer version of the previous product – did not contain bar.dll in the composition of the component with GUID {788FAC73-431F-41AF-BF72-9AB2AE74DB4E}, bar.dll will be orphaned. This is because the component has a reference count of two before the previous product is uninstalled. When that product is actually uninstalled, the component is not removed from disk but instead the reference count is simply decremented to one. Because the new product does not know about bar.dll for the component in this scenario, bar.dll will be left behind when this newer product is removed. It’s now an orphaned file.

So while scheduling RemoveExistingProducts later may be more efficient, it’s also less safe that scheduling it early. Of course, if you follow good component authoring rules foo.dll and bar.dll would be in their own components. If this were the case and the newer product in this scenario still didn’t contain bar.dll, bar.dll and its parent component would be removed from disk because the reference count would only be one when that older product is removed.

 

Rob Mensching (Microsoft)

RobMensching.com /Blog - Posts

[go to blog]

WiX Working Group video of the night, underwater base jump.

[ posted 2010-08-06 | go to article ]

Tonight was a quiet night of working. Progress was made on our various fronts. I picked this video out of the queue to meet the mood. The general reaction when the clip finished was, "Whoa."

Read More...

Frustrated.

[ posted 2010-08-04 | go to article ]

I'm am so frustrated right now.

Read More...

The first thing I do with an MSI log.

[ posted 2010-08-03 | go to article ]

If you've dealt wit the Windows Installer at all, you know the fastest way to figure out what went wrong is to look at a verbose log file. The normal log file doesn't provide enough information to really diagnose things going wrong, so I always generate a verbose log file like so:

Read More...

 

Aaron Stebner (Microsoft)

Aaron Stebner's WebLog

Thoughts about setup and deployment issues, WiX, XNA, the .NET Framework and Visual Studio [go to blog]

New knowledge base article with detection information for all versions of the .NET Framework

[ posted 2010-08-05 | go to article ]

Microsoft has posted an updated knowledge base article today with a unified list of install state and service pack level detection information for each of the currently released versions of the .NET Framework (1.0, 1.1, 2.0, 3.0, 3.5 and 4).  You can find the knowledge base article at http://support.microsoft.com/kb/318785 and I encourage you to take a look if you have any scenarios where you need to detect .NET Framework install state information.

Also, as a reminder, I have posted some sample code that demonstrates how to implement .NET Framework detection logic, and this type of example might be useful if you need to be able to detect the .NET Framework install state in your installer or your application code.

Possible workarounds for XNA Game Studio setup errors caused by XnaLiveProxy

[ posted 2010-08-04 | go to article ]

Every once in a while, I hear from a customer on the Creators Club forums or via my blog who cannot install XNA Game Studio due to a problem with the XnaLiveProxy component that is installed behind the scenes during setup.  I wanted to describe how I diagnose this type of issue and offer a few suggestions for working around this issue in case anyone runs into a similar problem in the future.

How to diagnose this issue

The first thing I do when XNA Game Studio setup fails is look at the setup log files.  XNA Game Studio setup automatically creates verbose setup log files at the following locations:

I sort the logs in this folder by modified date and then look for the most recent log file named GameStudioSetup*.log.  Then, I search for the string Bootstrapper.exe Error in this log file.  For this particular issue, the error in GameStudioSetup*.log will look like the following:

Bootstrapper.exe Error: 0 : In Task InstallXnaLiveProxy: MSI Task Processor Failed on task: Copying XNA Game Studio files \n Please consult C:\Users\myusername\AppData\Local\Temp\XNA Game Studio 4.0 Setup\Logs\xnaliveproxy-20100724.150035.LOG for additional log information.

This error message lists the name of an additional log file that will contain more detailed error information.  The next step I take is to search for the string return value 3 in the xnaliveproxy*.log file listed in the above error message.  For this particular issue, the error in xnaliveproxy*.log will look like the following:

MSI (s) (7C:00) [12:34:56:789]: Product: Microsoft XNA Game Studio 4.0 (XnaLiveProxy) -- Error 1722. There is a problem with this Windows Installer package. A program run as part of the setup did not finish as expected. Contact your support personnel or package vendor.  Action InitializeXnaLiveProxy, location: C:\Program Files\Microsoft XNA\XNA Game Studio\v4.0\Bin\XnaLiveProxy.exe, command: /install

How to work around this issue

Here are some possible causes and suggested workarounds for this error:

1.  A problem with Games for Windows – LIVE

To work around this issue, I recommend going to the Programs and Features control panel, removing the item named Microsoft Games for Windows – LIVE Redistributable, installing the latest version of Games for Windows – LIVE, then trying to run XNA Game Studio (or Windows Phone Developer Tools) setup again.

2.  A problem with the DirectX 9.0c runtime files

If the above doesn’t help, then I recommend trying to install the DirectX 9.0c redistributable using the standalone web installer, then trying to run XNA Game Studio (or Windows Phone Developer Tools) setup again.

3.  A problem with the .NET Framework

If neither of the above help, then I recommend trying to uninstall + re-install the .NET Framework 3.5 or 3.5 SP1 (if you are trying to install XNA Game Studio 3.0 or 3.1) or the .NET Framework 4 (if you are trying to install XNA Game Studio 4.0, then trying to run XNA Game Studio (or Windows Phone Developer Tools) setup again.

Installing offline documentation for Windows Phone Developer Tools

[ posted 2010-07-20 | go to article ]

The Windows Phone Developer Tools CTPs and Beta have only offered online documentation for general Windows Phone developer topics and Silverlight Windows Phone application development topics.  However, it is possible to use the Visual Studio 2010 Help Library Manager to download an offline copy of the Windows Phone developer documentation.  Here are the steps I’ve used to do this on my computer:

  1. Launch Help Library Manager.  To do this, open Visual Studio 2010 or Windows Phone Developer Tools, click on the Help menu and choose Manage Help Settings.
  2. If you have never run Help Library Manager before, you will have to first select a local path to download the content to.  This dialog looks like the following:

    Help Library Manager local content location
  3. After selecting a local path, the main Help Library Manager page will appear.  Click on the link named Install content from online.  This dialog looks like the following:

    Help Library Manager main page
  4. In the list of online content, scroll to the bottom, locate the item named Windows Phone Development and click the Add link.  This dialog looks like the following:

    Help Library Manager install from online
  5. If you would like, you can also use the Help Library Manager to install offline content for other technologies like the .NET Framework, the Windows SDK, etc.

XNA Game Studio 4.0, which is installed as a part of the Windows Phone Developer Tools setup process, installs a CHM file with offline documentation, but the CHM file can only be launched via the shortcut on the Windows start menu (located at All Programs | Microsoft XNA Game Studio 4.0 | XNA Game Studio Documentation).  The CHM cannot by pressing F1 while working on an XNA Game Studio project in the Visual Studio IDE.

We are planning to make the XNA Game Studio 4.0 documentation available for offline download via the Help Library Manager in the future.  Once we do that, you will be able to download and install the documentation in the same way that I described above for the Windows Phone Development documentation.  After installing the offline documentation using Help Library Manager, you will be able to access the documentation by pressing F1 while working on an XNA Game Studio project in the Visual Studio IDE.

<update date="7/30/2010"> Updated the first step in this post with an easier way to launch Help Library Manager. </update>

 

Link to a survey about the .NET Framework 4 setup and deployment experience

[ posted 2010-07-17 | go to article ]

Peter Marcu has posted a new survey on his blog that I wanted to link to here in order to try to help him get more responses.  He's looking for feedback about changes made to the setup and deployment experience for the .NET Framework 4 to help determine how to continue to improve the experience in future versions of the .NET Framework.

If you are a developer working on the deployment of applications that require the .NET Framework, I encourage you to check out his blog post at http://blogs.msdn.com/b/pmarcu/archive/2010/07/16/do-you-deploy-a-managed-app-part-2.aspx and post comments there or send him an email to share your experiences and suggestions for improvements.

 

Christopher Painter

Deployment Engineering

[go to blog]

WiX-Users: Exceeding Version Limits

[ posted 2010-08-27 | go to article ]

Sohail Somani recently asked on the WiX-Users List:

I'm currently in the middle (or nearing the end, I hope) of porting an installer from the evil that shall not be named to WiX.


Mostly, it's been pretty easy. However, one thing which is sticking out is the version number. The products being ported use the current year as the major version number and this means strings like "2011.foo.bar".


...Is there a  simpler way to exceed the limits...? 

The tool ( let me guess: InstallShield ) Sohail used to use isn't the evil, it's how it was used that is incorrect. Over my many years of writing installs I've seen this situation happen over and over:

(I'll use one real world example to illustrate how absurd this really can get when you let functionals try to drive the decision without consulting technical resources. Seriously.... don't ask )

Release Manager:  I need the product version to be  DMLSS_V3.00.01.A.01.10
Setup Developer: I am sorry, I can only do x.x.x.x with certain upper and lower bounds for each field.
Release Manager:  That's crazy, the install shouldn't dictate what I choose.  You must make it what I say.

However, certain the release manager is about how things must be done to meet his 'special' business needs ( aren't they always? ), the MSI SDK is quite clear on the definition of the ProductVersion property:

The format of the string is as follows:

major.minor.build
The first field is the major version and has a maximum value of 255. The second field is the minor version and has a maximum value of 255. The third field is called the build version or the update version and has a maximum value of 65,535.
The old tool allowed this violation ( usually without much real life harm, perhaps some problems doing Major Upgrades ) but WiX simply doesn't allow it.  I think that's a good thing because it helps the install developer when he needs to tell management:

Setup Developer: I'm sorry, I can display your custom version scheme on the dialog but I cannot possibly assign it to the ProductVersion.

Instead it looks like Sohail is just looking for a way around MSI to make the release manager happy.  I understand that pressure but personally I never tolerate it.  I suppose that's partly why I change jobs so often.    Still, it can get better as evidenced by the fact that I've been at my current employer for nearly two years now when the last time I worked for them I barely made it past a year.    Push back hard enough and provide sound reasoning and eventually it will improve.

IsWiX Stretch Goals

[ posted 2010-08-25 | go to article ]

Wilbert van Dolleweerd left a comment on the blog entry IsWiX - Three Great Tastes asking:

We are in the process of migrating away from Installshield to Wix. It is a good tool if you don't mind a bit of commandline work (for the record: I'm a VIM user ;-) 
Would love to see your ideas for IsWix and how you're willing to enhance it. I might even consider contributing to it.

IsWiX is already a very usable tool at my day job as it was designed for our specific needs.  However,  I'd love to grow it into general purpose tool.  With that in mind, here is a short list of stretch goals I have for IsWiX.  I am also very open minded to feedback to see where people would like to see this project go.



User Documentation

I had written a user manual for IsWiX but it used a company confidential template so I left it behind.

Presentation

I'd like to develop a one hour overview of Windows Installer / WiX technologies targeted at traditional developers for use at CodeCamp and DotNet User Group type events. I am somewhat concerned that there might not be much interest in this from developers.

Robust Automation Interface

SDK Documentation and Visual Studio Project Templates to help people write designers and domain objects for Fireworks / IsWiX.

Support for Sharp Develop

Matt Ward was very helpful in coaching me in the use of their XmlEditor control and I know they are WiX fans so I'd like to try to give something back.   Combining SharpDevelop, WiX and IsWiX seems like a no brainer for small companies and developing markets who can't afford Visual Studio / InstallShield.

Improvements to the XML Editor

IsWiX is meant to be used with Votive which already has a decent XML editor.  The XML editor in IsWiX was initially implemented primarily as a  way to preview the changes to the in memory document but it would be nice to mature it to a point of being similar in capabilities of Visual Studio but a lot lighter weight.

VIM Text Editor
OK, this is somewhat a gag feature ( but I'm actually serious here ) but it would be interesting to somehow host VIM in a Winforms control.  Imagine switching from designer mode to editor mode and using all the VIM tricks you are used to and then switching back to designer mode.
Refactor Files and Folders

I need to clean this up to use proper domain objects and allow it to exist in Product's, Fragments or Modules.  It currently only supports Modules since that was the easiest path to supporting our use case.

COM Extraction

Add the ability for the Files and Folders designer to interact with Heat to perform COM harvesting and authoring.  Currently I use a utility that serves as a front end to heat to author the COM snippets and then manually integrate them using the text editor.

Additional Designers

Finish work on Custom Tables Schema Editor and implement Services, Registry and ShortCuts Designers

IsWiX - Three Great Tastes

[ posted 2010-08-24 | go to article ]

WiX vs InstallShield has long been a Red vs Blue debate. Some people believe that setup source is code and should be edited as such while others are in the camp that it's just a document that should have visual designers to automate the workflow.  Finally there are others who need to also be able to programatically update source files from time to time.
Each of these approaches have pros and cons so with IsWiX I decided to support them all.    After all what's garbage to one developer might be a treasure to another. Let's look at these three great tastes:

Graphical Designers














Many of us live in the land of  Windows and use tools like Visual Studio. We like to be able to point, click, drag and drop and cleanly visualize the results of our labor.  Drag a tree of files from the Source view to the Destination view and let someone else do the work of writing the XML for us.  As they say in Jamaica- No Problem Mon!   You can create really nice UI's with rich client side validation such  a constraint for Module@Platform that provides a list list of  types or maybe preventing a user from adding the same file twice.  Properly designed UI's and Domain Objects can generate code as clean as hand written code only you didn't have to spend all day slaving over the computer to write it.  Detractors will claim that it's a crutch that prevents you from learning what is really happening behind the scenes but the same argument could be made of copy and paste and assuming all is well when it seemed to work.  At the end of the day it's up to the developer to turn on the curiosity gene and really understand the entire technology stack.

Text Editors













Some developers just hate reaching for the mouse.  Give them a command line interface and VI and that's all they need or want.  Interestingly, many of these people work on Windows and DevDiv / Visual Studio @ Microsoft and that in itself is a life mystery that I will never quiet grok.  Personally I think it's some form of super-geek 'I'm smarter then you.' cult philosophy but that's just a theory with no hard evidence. While I'm no stranger to the command line, ( My resume includes CPM, AmigaDOS, MS-DOS and various flavors of Unix ) I just don't enjoy typing large amounts of XML. Still, it's nice to be able to look behind the scenes and read what the visual designer actually did.  It's nice to get the XSD validation ( although not as protecting as client side validation ) and it's nice to be able to make hand tweaks to generated code.  After all, there's always an edge case out there and graphical designers and code generators should never stand in your way of getting the job done.  At the end of the day, you are smarter then the computer.

Automation Interfaces















Finally, there are times ( for whatever reason ) when you just need to be able to inject a little magic into the process.  You shouldn't have to use raw XML DOM's to manipulate the source nor should can you possibly use a graphical designer.  Therefore, anything a graphical designer can do must also be possible programtically through an automation interface.   Additionally, a well thought out automation interface can help create an ecosystem of tools that are currently unimagined.

Summary and Invitation

So that basically sums up the three great tastes of IsWiX.  In thinking this over, it's now clear to me that a best in breed solution should borrow ideas from both WiX ( XSD is wonderful ) and InstallShield ( Designers and Automation Interfaces Rock ).   InstallShield is a wonderful product but I have several major concerns:

1) InstallShield's use of DTD in it's project format is dead to me.  It's barely readable/editable and is a nightmare once you get into branching and merging situations.

2) InstallShield needs to be rewritten.  I can only imagine the hell it must be maintaining 10+ year old C++ code.  It's time for a reboot.  Just as InstallShield embraced Windows Installer over a decade ago, it's time for them to embrace the .NET framework and some form of XSD based document format.  I vote for WiX.

3) In the area of Agile Software Development, InstallShield's build automation story is really good but it falls really short in the area of Distributed Development.  The Collaboration piece simply isn't powerful enough and the pricing model and learning curve of the main IDE just doesn't make it a good tool choice.
3) InstallShield's Automation Interface is lacking in terms of API coverage.  You have to resort to raw manipulation of the underlying tables every time you hit a wall. Additionally using it from .NET is a horrible excercise in COM Interop with no factory pattern or interfaces to allow you to easily switch your code from one version of the API to another.  This beast was made for VBScript ( see #2 ).

4) I was reading about Paternerships vs Dependencies the other day and it made me realize: When pay up to $9500 per seat for InstallShield with maintenance and then do the activation dance, you are dealing with the latter.  You are at their mercy to even use the software with no promises that they will actually fix their bugs or release features that are important to you.   That's probably fine for a lot of shops but I've been increasingly concerned by it.  That's saying a lot since I used to think of this as a parnoia argument.

WiX on the other hand has some clear technology advantages but continues to suffer from severe underfunding and narrow user stories.  I'm convinced they are some very smart people and that most of choices that they have made that I've disagreed with in the past are really just a result of the realities of the available resources.

It's with this in mind that I've decided to set out on creating IsWiX.

I'm throwing the gauntlet down: 

Who will help me?

PS-  IsWiX is intentionally released under the MS-PL license to enable anyone to take the ball and run with it.  I'm under no illusions of grandeur or wealth - I just hope that my little contribution can somehow spark thought and improve this little domain we call deployment engineering / setup authoring.  Regardless of what happens,  it's been a wonderful opportunity to develop my .NET skills while working in a domain that made sense to me.  No doubt this will help prepare me for the inevitable day that I retire from writing installs.

InstallShield Stand Alone Build Error -1131

[ posted 2010-08-20 | go to article ]

I was just reading this InstallShield KB article and it really makes me scratch my head.   Basically what it is saying is that the SAB has a dependency on the MS C++ 2005 SP1 Redist but that the SAB installer doesn't actually install it and hence an installer failure becomes a runtime/  failure.

Are you serious?  InstallShield has the best setup bootstrapper / chainer on the market.   Did no one notice they needed to add a C++ redist prereq?   Did they know but just not want to add the 2.3MB to the package?  Did they not know to use an AppSearch/LaunchCondition to gate the install?

But the part that really gets me is:

This unlikely situation is apt to appear on clean Windows/XP or Windows 2003 Server images.

Isn't the point of the SAB to enable *CLEAN* build machines?  If customers are following proper CM practices there should be alot of people with build machines that don't resemble the magical build machine antipattern.  I run my build machines lean and mean and I just looked - no C++ runtime on them.   No Visual Studio either.

 

InstallShield Knowledge Base Articles (Flexera Software)

Flexera Software KB Articles - InstallShield [blog home]

 

 

 

English News Discussions Windows Installer Virtualization Related Tools More Help InstallScript About InstallSite Shop Site Search
deutsch Neuigkeiten Diskussionsgruppen Windows Installer   MSI FAQ Artikel     Shop Suche

Copyright © 1997-2010 by InstallSite Stefan Krueger. All rights reserved. Legal information.
GERMAN Impressum,Datenschutzerklärung, Haftungsausschluss
By using this site you agree to the license agreement. Webmaster contact