Categories
Windows Installer, Application Compatibility and Deployments

How to Troubleshoot MSI Error 1720?

Error 1720 is a generic Windows Installer error message which you get when there is a problem with a custom action script in the package. To troubleshoot this error:

1. Finish the install and look in the application log in the eventviewer. The eventviewer will have a warning with a source of MsiInstaller. This warning will often show you exactly where in the VBscript the error is.

2. Log the MSI installer. You can activate logging with the following command line misexec /i pathtomsi.msi /L*v “pathtologfile.log”. The log file will be created and added to as the install takes place. When the error occurs leave the error dialog on the screen and look at the log file. The end of the log file will contain the exact action that has caused the error. Look at the last MSI action to run without ending. This will be the action that is causing the problem. Often you can find this action in the CustomAction table (use Orca to open it up) and can fix any syntax errors or even hack the action out of the CustomAction and InstallExecuteSequence tables.

Categories
Best Practices Microsoft Windows Installer, Application Compatibility and Deployments

Microsoft Best Practices & Standards: Application Packaging

Here are a few tips I picked up from Microsoft about how to “color inside the lines” when using any tool (including Wise Package Studio) to create an MSI.

  1. Match components in previous versions of the MSI:
    Key path resource matches a resource in previous .MSI list
    Match component layout of previous .MSI
    Set component key to match previous version.
  2. Add all executable files to their own components
  3. Create new component for the resource
  4. Add all .TLB files to their own components
  5. Group matching .HLP and .CNT files together
  6. Group matching .CHM and .CHI files together
  7. Put registry keys associated with files or components in matching components.
  8. Put current user registry keys in their own component
  9. Put non-current user registry keys in their own component.
  10. Group all non-executable files to their own component
  11. Name new non-advertised shortcuts by destination directory.
  12. Group non-key path resources by resource type
  13. Create new components for resources not matching other criteria.
  14. Set component key to table name of key path or the first resource.

Hope these little guidelines helps!

Categories
General Microsoft

MVP Award : Setup and Deployment

Hiiii All, I am very pleased to inform you that, I have been awarded the MVP award for “Setup and Deployment”.

I got the mail from MVP Team last night. Thanks to all my Pals and my readers at Juice.

Categories
Microsoft Windows Installer, Application Compatibility and Deployments

How to check an Executable for Manifests and Digital Signing?

To avoid UAC prompts for applications on launch, there exists a manifest file which contains key information on the privileges. Many times, these manifest files are present along with the executable in the same directory. For example: Altair.exe will have a manifest file called Altair.exe.manifest in the same directory. There can also be cases where the manifest is embedded in the exe itself. In this case, identifying the launch condition for this exe involves a lot of research.

Here is a simple executable which will help research those launch conditions.

Sigcheck.exe is an executable from the Sysinternals team that enables you to check whether a file has been digitally signed. The -m switch allows you to view any manifest within the file. All we need to do is run this sigcheck.exe with -m switch along with the executable, the full manifest will be displayed on the command prompt window.

If the XML manifest is going to prompt an elevation then there will be a tag “requiredExecutionLevel” set to “requireAdministrator”.

You can then re-create a manifest on these 3 categories:

  • Runasinvoker
  • Runasadmin
  • Runwithleastprivilages

Its advised to use Run as Invoker for manifests (Launch condition).

Signcheck.exe can be downloaded here.

Categories
How-to Microsoft

How to Handle .NET Framework Native Images in Software MSI Installation Packages?

When you find in a file which is suffixed by “.ni” in an application capture (For eg: Aclayers.ni.dll), this is an indication that it is a native image for an assembly. (The base assembly can be found in the application installation directory). These files cannot be added directly to the MSI package. Instead, it needs to be done through a .NET executable(ngen.exe).
In this below article, we look at the basics and implementation of this process.

Overview of Native Image Generator:

The Native Image Generator (ngen.exe) creates a native image from a managed assembly and installs it into the native image cache on the local computer. The native image cache is a reserved area of the global assembly cache. Once you create a native image for an assembly, the runtime automatically uses that native image each time it runs the assembly. You do not have to perform any additional procedures to cause the runtime to use a native image. Running Ngen.exe on an assembly allows the assembly to load and execute faster, because it restores code and data structures from the native image cache rather than generating them dynamically.

How Native Generator Works

Ngen.exe does not use standard assembly probing rules to locate the assemblies you specify on the command line. Ngen.exe looks only in the current directory for assemblies that you specify. Therefore, to allow Ngen.exe to locate your assemblies, you should either set your working directory to the directory that contains the assemblies you want to create native images for or specify exact paths to the assemblies.

This tool can be located at <drive>:\WINNT\Microsoft.NET\Framework\<version>\ngen.exe

This tool is used to create a native Image from a .NET assembly and installs it into the native image cache on that computer. Since assembly image is present on the local machine cache loading of the assembly becomes faster because .NET reads data from the native image than generating them dynamically (JIT). Pre-compiling assemblies with Ngen.exe can improve the startup time for applications, because much of the work required to execute code has been done in advance.

The default usage for NGen is extremely simple: ngen install aclayer.dll

This will generate native images for aclayer.dll and all of its dependencies and create a native image for this dll in C:\Winnt\Assembly\Native Images as aclayer.ni.dll.

This process can be quite slow. For larger applications you may wish to use the /queue option which will queue up aclayer.dll, and all of its dependencies, so that they will be converted by the Native Image Service. This will happen in the background, at the service’s earliest convenience. Once the native image is generated it will be stored in the native image cache and used automatically.

Usage:

While Installing:
Identify the Assembly which creates these native images, mention the same path in these scripts. Example: C:\Program FIles\DWG TrueView 2008\AcLayer.dll. For multiple assemblies use the function mentioned.

Use this script in your MSI Package.

Option Explicit
Dim wshShell, ngen, FSO, windir, assembly,PrgFiles
Set wshShell = CreateObject(“WScript.Shell”)
Set FSO = CreateObject(“Scripting.FileSystemObject”)
windir = wshShell.ExpandEnvironmentStrings(“%Windir%”)
PrgFiles = wshShell.ExpandEnvironmentStrings(“%ProgramFiles%”)
ngen = windir & “\Microsoft.NET\Framework\v2.0.50727\ngen.exe”

if FSO.FileExists(ngen) then
assembly=chr(34) & PrgFiles & “\DWG TrueView 2008\AcLayer.dll” & chr(34)
Generate(assembly)
end if

set FSO = nothing
set wshShell = nothing

Function Generate (Byval file)
Dim strCmd,wshShell1
Set wshShell1 = CreateObject(“WScript.Shell”)
strCmd= chr(34) & ngen & chr(34) & ” install ” & file
wshShell1.run strCmd,0
Set WshShell1 = nothing
End function

While Un-Installing:

Option Explicit
Dim wshShell, ngen, FSO, windir, assembly,PrgFiles
Set wshShell = CreateObject(“WScript.Shell”)
Set FSO = CreateObject(“Scripting.FileSystemObject”)
windir = wshShell.ExpandEnvironmentStrings(“%Windir%”)
PrgFiles = wshShell.ExpandEnvironmentStrings(“%ProgramFiles%”)
ngen = windir & “\Microsoft.NET\Framework\v2.0.50727\ngen.exe”

if FSO.FileExists(ngen) then
assembly=chr(34) & PrgFiles & “\DWG TrueView 2008\AcLayer.dll” & chr(34)
DeleteImages(assembly)
end if

Function DeleteImages (Byval file)
Dim strCmd,wshShell1
Set wshShell1 = CreateObject(“WScript.Shell”)
strCmd= chr(34) & ngen & chr(34) & ” uninstall ” & file
wshShell1.run strCmd,1
Set WshShell1 = nothing
End function

Note: To run Ngen.exe, you must have administrative privileges. Hence, run this CA in deferred/System Context mode.

Categories
Windows Installer, Application Compatibility and Deployments

How to Fix Custom Action Issues in MSI Installation?

When an installation fails, it may be because of the Custom Action(s) it contains. Here’s how to examine the MSI logs to troubleshoot the problem. Generate the MSI log and search for RETURN VALUE 3. This will help you identify and solve the problem in some cases.

Further, the possible Return Values for CAs are:

Value Description
0 Action not invoked; most likely does not exist.
1 Completed actions successfully.
2 User terminated prematurely.
3 Unrecoverable error occurred.
4 Sequence suspended, to be resumed later.

Also note that there is an MSI verbose log parsing tool (wilogutl.exe) in the Windows Installer PSDK that is also very useful in locating errors inside verbose log files. This tool is more thorough in identifying errors — just browse to the log file, wait for it to parse the whole log and then read the output it produces.

Categories
General Microsoft

MVP summit : Conversation with Steve Balmer

hey buddies, Read this lovely conversation of Steve Balmer with MVPs during a Summit.
http://www.microsoft.com/Presspass/exec/steve/2008/04-17MVP.mspx

Its worth reading through Balmer’s answers to the queries raised.

Categories
Best Practices How-to Microsoft Tools Windows Installer, Application Compatibility and Deployments

How to create a Windows Installer Patch using Wise Package

Step 1: Launch the Patch Creation tool from within your Wise product. The Patch Creation tool’s Welcome dialog appears. This dialog offers an outline of the steps for creating a patch.

Step 2:
Read the information on the Welcome dialog, and click Next when finished. The Specify Patch Settings File dialog appears.

Step 3: The radio buttons on the Specify Patch File Settings dialog indicate whether to create a new patch file or Open an existing patch settings file. A patch file (.PCP) stores settings from the Patch Creation tool, such as the names of the previous and new .MSIs and whether to include whole files or file patches when compiling the patch. For this exercise, select the radio button to create a new patch file and click Next. The Specify Previous Versions dialog appears.

Step 4: Use the Specify Previous Versions dialog to add entries for each of the previous versions of an installation that the latest version can patch. Click Add to add a previous version. The Previous Version Details dialog appears.

Step 5: Click Browse to browse to the .MSI for the previous version of your application. Click Open after locating the .MSI.

Step 6: Make any desired changes on the Previous Version Details dialog. The settings in the Validation section of the dialog indicate the requirements of the previous installation on the destination computer in order to install this patch. Please view the online help by pressing F1 on the Previous Version Details dialog for more information about the various fields.

Step 7: Click OK when finished making changes on the Previous Version Details dialog. A dialog might appear, saying that the installation database is marked as compressed and PatchWiz.dll does not operate on compressed databases. Click Yes to run an admin install to extract the files from the .MSI and continue creating the patch. Windows Installer extracts the .MSI and the Specify Previous Versions dialog shows a target path pointing to a temporary directory where the extracted .MSI resides.

Step 8:
Add other previous versions if applicable, then click Next on the Specify Previous Versions dialog. The Specify Upgrade Version dialog appears.

Step 9: The Specify Upgrade Version dialog shows the path to the .MSI that upgrades the previous versions enumerated on the Specified Previous Versions dialog. When launching the Patch Creation tool with an installation project already open, the Upgrade MSI path field contains the path to the .MSI for the current installation project. Click Browse to browse to the upgrade .MSI if the Upgrade MSI path field doesn’t already contain the correct information.

Step 10:
Click Advanced to display the Advanced Upgrade Version Details dialog. This dialog shows the Patch GUID and a field for Previous Patch GUIDs to replace. Please view the online help by pressing F1 on the Advanced Upgrade Version Details dialog for more information about the fields on the dialog. Click OK when finished making changes to the Advanced Upgrade Version Details.

Step 11: Click Next on the Specify Upgrade Version dialog. A dialog might appear, saying that the installation database is marked as compressed and PatchWiz.dll does not operate on compressed databases. Click Yes to run an admin install to extract the files from the .MSI and continue creating the patch. Windows Installer extracts the .MSI to a temporary directory, and then the Compile Patch dialog appears.

Step 12: The Compile Patch dialog shows several options for compiling the patch. The first field is the name of the Output .MSP file. Browse to the location where to store the .MSP file, or type in the full path including the file name.

Step 13: The Advanced Settings on the Compile Patch dialog determine whether to create file patches or to use entire files, whether to allow the Product Code or Version Number to differ between the previous and upgrade, and whether to create a log file. Mark the checkboxes for these options to enable them.

Step 14:
The Multi-patch Media settings indicate the starting file sequence and disk ID numbers as well as the volume label for the .MSP and the prompt that displays when the application needs to be repaired. Again, please view the online help by pressing F1 on the Compile Patch dialog for more information. Note that the Volume Label on this dialog must match the volume label on the CD or other write-protected media that distributes the patch. Click Next on the Compile Patch dialog to continue the patch creation process.

Step 15: The Patch Creation tool begins creating the patch. A dialog might appear, saying “ProductCodes between Target and Upgraded images do not match; do you want to proceed anyway?” Click Yes to continue creating the patch, or click No to stop. Another dialog might appear, saying “ProductVersions between Target and Upgraded images do not match; do you want to proceed anyway?” Click Yes to continue creating the patch, or click No to stop.

Step 16: When the Patch Creation tool has finished creating the patch, the Compile Patch dialog says Patch creation completed and has a View Log button. Click View Log to view the patch creation log, or click Finish to close the Patch Creation tool.

 

Categories
General Microsoft Windows Installer, Application Compatibility and Deployments

Frequently Asked Questions About Windows Installer

Here’s a great reference if you want/need to learn some Windows Installer concepts and best practices. This document is very useful to individuals who are starting to do application packaging

http://www.microsoft.com/technet/community/en-us/management/msi_faq.mspx

Categories
How-to Microsoft Windows Installer, Application Compatibility and Deployments

Understand the Windows Installer Logs

Here’s a fantastic document by Richard on “how to interpret Windows Installer logs”. This is a very essential and a noteworthy bookmark for every packager and administrator. Especially, Don’t miss the Annotated Verbose Installer Log section; it has a pdf file, which contains a log file generated on Vista.

Special Thanks to Richard Mc Donald for this wonderful Document!

Click here to Download the Annotated Verbose Log