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
Best Practices How-to Microsoft Windows Installer, Application Compatibility and Deployments

MSI Packaging Guidelines and Best Practices for Windows 7 / Vista

Here are few points which would prove handy while re-packaging an application for Vista / Windows 7.

1. If you must make a change on the system via a custom action, ensure that the custom action is deferred and the msidbCustomActionTypeNoImpersonate bit is set. This will ensure that the custom action inherits elevated privileges from the installed

2. Place all your custom actions in the Execute Sequence to ensure that they are invoked during silent mode and use appropriate conditions on the custom actions to only run when intended

3. Test your application for a locked down user. If necessary, give the user permissions to access folders and registry keys that the application tries to write to via the Locked Permissions table. Do not open higher level folders such as C:\Program Files, C:\Windows or C:\Windows\System32 for locked down users. Instead, set permissions on the exact sub-directory that the application needs access to:

4. AdminUser property commonly used to check for admin rights will not work in UAC. Microsoft has decided to set this to TRUE by default for Application Compatibility reasons. Use MSIUSEREALADMINDETECTION property instead.

5. Add installation logic that was not captured by SetupCapture. Example: Launch conditions that check for system requirements.

6. Turn off Virtualization feature. This will ensure that, duplicate files and registries are not created. This mainly happens to the applications which need a launch. The keys which are virtualized can be removed from the package as well.

7. Add support for Vista-specific features 🙁 This can be found in the “Windows Installer Options” dialog of Installation expert in WPS 7.0)

a. Disable the User Account Control (UAC) prompting for standard user installations.

b. Set options for Restart Manager.

8. Set Windows Installer logging options to provide verbose output. The installation log can provide valuable information about why an installation fails.

9. Remove 16-bit features from packages that will run on the 64-bit version of Windows Vista, if they are not part of the application’s primary functionality.

10. Remove all WRP components from the MSI package. If the installation installs a file that would otherwise be installed to an area that is protected by Windows Resource Protection (WRP), you can do one of the following:

a. Delete it from the installation and test the application with the version that is on the destination computer. However, if you do this, your application can fail if the protected file is updated or changed in the future.

b. Isolate the protected file so it is installed to a different location.

11. Fix installation-related errors that you find while performing installation and functionality tests.

12. Make other changes that are not related to Vista but are required as Customers standards.

13. Resolve CA’s which involved Nested Installation. This will throw an error while deployment.

14. Impersonation should not be used when running setups on Windows Vista. Edit the custom action and change its In-Script Options property to Deferred Execution – System Context. Test to verify that the custom action runs in this context.

15. Edit the custom action to add a description. The Windows Installer Editor documentation contains information you can use to document Wise custom actions

16. Any property beginning with MSI cannot be used. Hence avoid using the same.

17. Components cannot have a dummy GUID; it’s a best practice to generate one.

Categories
Best Practices Windows Installer, Application Compatibility and Deployments

Application Packaging Advantages & Installer Benefits

Application packaging bundles applications and operating systems into a single file called a distribution unit (.msi), which makes it easier to deploy and install them on user’s computers. Packaging reduces the total cost of ownership for the customers by enabling them to efficiently install and configure the applications. This results in an application package, which provides the product with new capabilities like advertise features without installing them, installs products on demand, add user customizations etc.

Advantages of Packaging(creating MSI packages)

    1. Customize Applications to suit the user needs.
    2. Simplify the Installation and Un-installation Procedures.
    3. Saves Time in both Installation and Un-installation.
    4. Once packaged, applications can be quickly installed on a range of desktops in multiple locations, saving administrative costs, simplifying the manage of licensing fees and minimizing support and repair expenditures.
    5. Saves Space of the product by doing apt modifications to applications.
    6. Has a great flexibility of obtaining the lost files through a phenomenon called Self Heal, this reduces the down time of application. If a critical file (a .DLL or .EXE file, for example) that is part of the distribution is corrupt or is deleted, the user can be prompted to repair the installation by presenting the original .MSI distribution. Additionally, if the installation media is available (for example, on a network share), the repair simply happens automatically.
    7. Can be advertised. So that on demand installation could take place.
    8. Upgrading of the application can be done with ease.
    9. Clean installation and Un-Installation is achieved by a process called Roll-Back.
    10. Simplifies management of new user set-up along with the revision and distribution of software repairs and new applications to existing users. Application recovery can also be improved.
    11. Helps eliminate uncontrolled software downloads and installation, enables applications to be safely removed and reduces non-business traffic on a corporate network.
    12. Using .MSI format, can automate software distribution process and ensure that the installation doesn’t break other applications that have already been installed.
    13. Application is installed via an OS service.
    14. State management is maintained. In the past, it’s been difficult to know whether an application is installed on a machine. You would have to query for a .DLL with a specific version number or determine whether an .EXE file with a specific name was present. Windows Installer provides an application programming interface (API) that lets programmers and administrators see whether a specific application is installed on a machine.
    15. Scriptable API. This whips together a VBScript to help us with the MSI file manipulations. The API to manipulate MSI files is so powerful that it can create, validate and update packages, trigger installs and uninstalls, examine the MSI repository data on computers, and perform some custom actions.
    16. Served installs. Because MSI files can be housed in a share point and delivered via a server, we can keep our installation files all in one place or move them around — closer to the users if necessary.

Hope this article helps the people who keep their first steps in packaging… 🙂