Categories
Best Practices Windows Installer, Application Compatibility and Deployments

Best Practices to follow while Packaging Applications

Hard-coding should be avoided

In an MSI, Hard coding should be avoided to the maximum and should be replaced by properties. For e.g. instead of “C:\Program Files\…”, property “ProgramFilesFolder should be used.

Least Use of custom actions involving 3rd party tools

Any changes which are being made to the system during an installation should possibly be made through an MSI involving least use of 3rd party tools. For e.g. If an UI Installation needs to created, it should be done through MSI Dialogues not through Visual Basic exe’s. If a file has to be installed conditionally, same should be done through MSI’s functionality not through VB Scripts.

Deletion and allocation of resources (files, registries) to proper components.

During Setup capture, Wise package Studio, captures lot of junk registries and usually you will find all these registries in a component by name “registryXX”.
This component needs to be carefully looked at since this component will have registries which otherwise should belong to other components. For e.g this component will have registries for e.g HKCR\CLSID\{GUIID} or HKCR\Interface\{GUIID}.If there is a dll in your application and registration of this dll has this GUID, then this registry should be moved from this component to the component having this dll else this registry is categorized as junk registry and needs to be removed.

 Ini Files should be retained as INIFile Table Entries not as Files, to the extent possible.

Ensure that any INI file changes are recorded in the INI file table, rather than just as files in the file table. This will ensure that INI files are edited if they exist already, rather than replaced with the version within the MSI Package.

Shortcuts should be made as “Advertised” shortcuts to the extent possible.

This is to ensure Self Healing.

DLL’s should be registered through Advertising Tables to the extent possible.

This is to ensure Self Healing and minimize registry conflicts.

As soon as you realize that the source installation is an MSI or installs an MSI embedded in it, it should be scripted as Vendor MSI.There should be no empty components in the MSI.

 Only COM Dll’s should be isolated.

If any custom actions are used, “In-Script” options and “Processing Options” need to be set correctly for them.

During Setup Capture

if it’s observed that lot of .INI Files have got captured, it’s better to exclude the INI files from the capture and then a second capture can be taken just with INI files or the INI files can be added as files, else the capture will take several hours and some times may not complete.

it’s possible that .INI Files, .INF Files, .HLP Files or .CHM Files do not get captured properly. To make sure all these files are present in MSI, it’s better to compare the size of the application folder in target machine (where application is installed) with captured folders after Setup Capture.

In some applications, it’s required to do the capture in some specific accounts and Wise can’t be installed in that account. In such cases it’s better to use the Wise as “run as” rather than going for some other capture techniques.  

Note: Run as account should be the account in which Wise is installed.

 

Lot of CHM files

 When there are lot of CHM files need to be added in the script which might have missed during capture, add it to the components directly rather than adding through Installation Expert. The reason for this is if you add through Installation expert, then the CHM files will be moved to the components, which is already having some CHM files, getting installed in some other folder.

 

Categories
Windows Installer, Application Compatibility and Deployments

How to Slip Stream Application Patches?

There are better methods to handle patches with Windows Installer. However, when this doesn’t work, Slip-Streaming can be a Just in time solution. Slip-Streaming is a process which applies MSP to the MSI where MSI has not been installed on the system. If the Service Pack is in MSP format, then it can be directly installed on the system where the application is present.

In this phenomenon, MSP is automatically added to the MSI file itself and one can directly install the changed MSI. It can be called used by the following command:
msiexec /p abc.msp /a abc.msi

Disadvantages of Slip-Streaming Patches
1. The patch alone can never be un-installed.
If the patch has some problems, we will need to uninstall the entire application and to install the base application again without any patch. This is a very tedious process.
2. The user will not be aware of the patch application on the core MSI.
3. Consecutive patches can’t be applied.

Thanks Sunil and Harsha for this information!

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

Capture configuration Entries through Gap-Capture

This tip will shine some light on the concept of performing a “Gap Capture”. Let’s start with a simple equation: GAP CAPTURE = SOURCE APPLICATION – CAPTURED MSI.

Basically, a Gap Capture is the difference between a Source Application and Captured MSI.

When do we do this??

You have done the setup capture but your MSI fails in Functionality Testing. One reason could be that some files or registry is missing in your package. To capture the LEFT OUT entries, we need to do GAP capture.

How do I do this ??

1. Install Captured MSI of the Application on your system.
2. RUN Setup Capture and take the SnapShot.
3. Install Source Application over it.
4. Now finish the Capture (SnapShot of OS+MSI+Source Application)

What you’ve captured in the WSI is now a GAP Capture.

What Next??

First re-build the machine and install your earlier packaged MSI. If the Gapcaptured content is a registry entry or a file. just add this entry in the machine and launch the application shortcut. If it launches fine..its a Bingo!

Now, add this content to the MSI. Many a times, it can also be beause of an autoupdation of an ini file. In this case, install the source application and extract the ini files into your package and check for its functionality. I reckon, these steps will help !!!

Categories
General Microsoft

Mis-understood Features of Windows Vista

This is a very good article to understand Windows Vista better. There are lot more to talk about. Once you go through that article, I believe your complains would be reduced for sure !!!!

You can obtain the article from here

Categories
Best Practices Windows Installer, Application Compatibility and Deployments

How to add Assemblies to Global Assembly Cache (GAC)

Installation of assemblies should not be dealt using gacutil.exe (Custom action) in an application installation suite. Gacutil is not designed to be used during installation. Gacutil.exe works, but it is a developer tool, and developer tools go into SDKs and not runtime packages typically. It isn’t really appropriate to put more tools into the runtime because that causes it to get larger, which makes it more difficult for applications to redistribute because of increased download, size, etc.

In general, installing an assembly to the GAC is an application deployment activity, and is most often done during application setup. One should use Windows Installer to install your application. Starting with version 2.0, Windows Installer has built-in functionality to install assemblies to the GAC – the MsiAssembly and MsiAssemblyName tables in particular. Its always better to use a MSI as an installer and directly authoring files, registry and GAC installation steps using built-in Windows Installer functionality instead of using a batch script, regsvr32 and Gacutil. We can gain a lot of benefits from using an MSI (clean rollback; uninstall, serviceability, deployment options, etc). Therefore we should use this built-in functionality to handle GAC installation and un-installation.

This means that if we want to obtain Windows Vista Logo certification for our application, we should use Windows Installer and the built-in GAC installation functionality for our setup.

Reference: Aaron Stebner’s WebLog

Categories
General Microsoft

My MVP certificate !!!

Here’s the photograph of my certificate..

mvpcert

And this is my identification card for the next year…

mvpcert1

These would remain one of my most favoured possessions for sure!!!

Categories
How-to Windows Installer, Application Compatibility and Deployments

Basics and Introduction to .NET Framework Assemblies

An Assembly is a logical unit of code. Assembly physically exist as DLLs or EXEs. One assembly can contain one or more files. The constituent files can include any file types like image files, text files etc. along with DLLs or EXEs. When you compile your source code by default the exe/dll generated is actually an assembly, Unless your code is bundled as assembly it can not be used in any other application. Every assembly file contains information about itself. This information is called as Assembly Manifest.

What is assembly manifest?

Assembly manifest is a data structure which stores information about an assembly. This information is stored within the assembly file(DLL/EXE) itself. The information includes version information, list of constituent files etc.

What is private and shared assembly?

The assembly which is used only by a single application is called as private assembly. Suppose you created a DLL which encapsulates your business logic. This DLL will be used by your client application only and not by any other application. In order to run the application properly your DLL must reside in the same folder in which the client application is installed. Thus the assembly is private to your application.

Suppose that you are creating a general purpose DLL which provides functionality which will be used by variety of applications. Now, instead of each client application having its own copy of DLL you can place the DLL in ‘global assembly cache’. Such assemblies are called as shared assemblies.

What is Global Assembly Cache?

Global assembly cache is nothing but a special disk folder where all the shared assemblies will be kept. It is located under <drive>:\WinNT\Assembly folder.

How assemblies avoid DLL Hell?

As stated earlier most of the assemblies are private. Hence each client application refers assemblies from its own installation folder. So, even though there are multiple versions of same assembly they will not conflict with each other. Consider following example:

  • You created assembly Assembly1
  • You also created a client application which uses Assembly1 say Client1
  • You installed the client in C:\MyApp1 and also placed Assembly1 in this folder
  • After some days you changed Assembly1
  • You now created another application Client2 which uses this changed Assembly1
  • You installed Client2 in C:\MyApp2 and also placed changed Assembly1 in this folder
  • Since both the clients are referring to their own versions of Assembly1 everything goes on smoothly

Now consider the case when you develop assembly that is shared one. In this case it is important to know how assemblies are versioned. All assemblies has a version number in the form: major.minor.build.revision. If you change the original assembly the changed version will be considered compatible with existing one if the major and minor versions of both the assemblies match. When the client application requests assembly the requested version number is matched against available versions and the version matching major and minor version numbers and having most latest build and revision number are supplied.

Categories
Microsoft Windows Installer, Application Compatibility and Deployments

APPCRASH Messages – Overview and Example Scenarios

Vista and Windows 7 have a variety of fault-protection systems that try to prevent a crashing application from taking down your entire computer. When Windows Vista detects that an application has crashed, it terminates it and generates an Appcrash error report. This report is useful, since it can be sent to Microsoft Team. Most of the applications crashes give an exception code of c0000005.

APPCRASH Scenarios: (in the order of their occurrence Rates)

Scenario 1
Problem Event Name: APPCRASH
Application Name: explorer.exe
Application Version: 6.0.6001.18000
Application Timestamp: 47918e5d
Fault Module Name: msvcrt.dll
Fault Module Version: 7.0.6001.18000
Fault Module Timestamp: 4791a727
Exception Code: c0000005
Exception Offset: 00009c00
OS Version: 6.0.6001.2.1.0.768.3
Locale ID: 1041
Additional Information 1: 72b2
Additional Information 2: 693d7799b8b778ed847472df9568cf8f
Additional Information 3: a1b0
Additional Information 4: 0d44ab9553a107ee7d95071a61aa480b

This problem can be solved, if the dll or supported depreciated dll is isolated to the application installation directory. For eg: Renaming cmoctl32.dll file to .old and let it rebuild itself. Like trashing an ini file and letting it rebuild itself.

Scenario 2
When some core application components (VB and VC++ runtime, DHTML controls etc…) are missing the machine/build, we get the APPCRASH message for few of the applications.

Scenario 3
Problem Event Name: APPCRASH
Application Name: PhotoStudio.exe
Application Version: 5.5.0.91
Application Timestamp: 46861e12
Fault Module Name: dtype32.dll
Fault Module Version: 3.9.4.4
Fault Module Timestamp: 3ebed48a
Exception Code: c0000005
Exception Offset: 0000e004
OS Version: 6.0.6001.2.1.0.256.1
Locale ID: 2057
Additional Information 1: d6bf
Additional Information 2: 0623d5f43aa286e60fe956167dbc9d6f
Additional Information 3: f083
Additional Information 4: 4aaeb79ec497d908d232129b547584f0

In these scenarios the application is not supported to run in Vista. Here we need the latest version/update to work with Vista. For the entire list of applications which works on Vista, refer to this link.

Applications which work with Vista
https://winqual.microsoft.com/member/softwarelogo/workswithlist.aspx

VISTA Certified applications List
https://winqual.microsoft.com/member/softwarelogo/certifiedlist.aspx

Scenario 4
Sometimes, on invoking the application shortcuts, we get the appcrash message with CLR20r3 error. This error occurs when there is a un-compatible .NET framework installed. It’s an exception in Winforms that Under References, System, System.Data, System.Drawing, System.Windows.Forms, and System.XML might have been developed references to .NET framework 1.1.

In few scenarios, the application doesn’t work if a higher version of framework is installed. In this case, we may need to create a manifest where we inform the application to check only for the framework 2 or 1.1 components.

Scenario 5
Some Application services which is not compatible to start with Vista, throws the APPCRASH message.
An exception here is that, services which are running in session 0 will show a Session 0 Isolated OTS window.

Scenario 6
When you have a third party control panel applet (older version of application), we have an appcrash pointing to explorer.exe.
In this case, we will need to update the application with the newer version.

Scenario 7
Seemingly random crashes are often caused by RAM errors. This can happen in Vista and not XP because of the way Vista loads. Vista uses something called Address Space Load Randomization (ASLR) to load the system into slightly different areas of RAM every time it loads as a security feature. XP doesn’t do this. This means if you have bad RAM (or bad hardware causing the symptom of bad RAM) XP may not notice it because the bad RAM isn’t in a system area. Vista because it loads the system into varying areas of RAM may crash with many different errors.

One Solution for this is to run SFC (System File Checker http://support.microsoft.com/kb/929833).

If you find/or have encountered few other scenarios, please add your comments to this page.

Categories
Windows Installer, Application Compatibility and Deployments

How to avoid Self-Healing of an MSI Package?

The correct way to avoid self healing on a component is not but removing the keypath.

If you want self healing to be disabled you should be removing Component code. A blank key path confuses self healing. A blank component GUID stops self healing data being written to the registry, effectively disabling it.

Categories
How-to Microsoft

How to register a File Extension in Windows?

If your application uses special file extensions, you might want to register them so that the application gets started when the icon associated with the file gets double-clicked.

There are special tables for this in the MSI structure (Extension and ProgId). The contents of these tables are used for advertising. You can also make your own registry entries to create application-to-file-extension relations. This example shows how to register the .dvi extensions to be opened with the yap.exe program.

Link the extension .dvi to the DVI.Document class:

Key: HKLM\SOFTWARE\Classes\.dvi
Value: <default> = “DVI.Document”

Describe the DVI.Document class:

Key: HKLM\SOFTWARE\Classes\DVI.Document
Value: <default> = “DVI Document”

Select Icon #0 from yap.exe which is in the MSI:

Key: HKLM\SOFTWARE\Classes\DVI.Document\DefaultIcon
Value: <default> = “[!yap.exe],0”

How to open the .dvi file if it is double clicked in the Explorer:

Key: HKLM\SOFTWARE\Classes\DVI.Document\shell\open\command
Value: <default> = “[!yap.exe]” “%1”