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) |
|
by Stefan Krueger [go to blog]
[ 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.
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).
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.
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
[ posted 2010-08-08 | go to article ]
Here are links to some articles that I came across during the past week, calendar week 31:
[ 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
[ 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.
[ 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.
[ 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) |
[ 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.
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.
[ 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 |
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) |
About Windows Installer, the .NET Framework, and Visual Studio. [go to blog]
[ 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.
[ 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).
[ 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.
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.
[ 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.
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.
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.
[ 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 InstallFinalize – shared 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) |
[ 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."
[ posted 2010-08-04 | go to article ]
I'm am so frustrated right now.
[ 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:
| Aaron Stebner (Microsoft) |
Thoughts about setup and deployment issues, WiX, XNA, the .NET Framework and Visual Studio [go to blog]
[ 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.
[ 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.
[ 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:
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>
[ 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 |
[ posted 2010-08-27 | go to article ]
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 format of the string is as follows: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:
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.
[ posted 2010-08-25 | go to article ]
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.
[ posted 2010-08-24 | go to article ]
[ posted 2010-08-20 | go to article ]
This unlikely situation is apt to appear on clean Windows/XP or Windows 2003 Server images.
| InstallShield Knowledge Base Articles (Flexera Software) |
Flexera Software KB Articles - InstallShield [blog home]
 |
News | Discussions | Windows Installer | Virtualization | Related Tools | More Help | InstallScript | About InstallSite | Shop | Site Search |
 |
Neuigkeiten | Diskussionsgruppen | Windows Installer | MSI FAQ | Artikel | Shop | Suche |
Copyright © 1997-2010 by InstallSite Stefan
Krueger. All rights reserved. Legal
information.
Impressum,Datenschutzerklärung,
Haftungsausschluss
By using this site you agree to the license
agreement. Webmaster contact