Best Practices and Guidelines: Packaging .NET Assemblies

This is a MSDN extract; I have still posted it because many of us do not follow these rules while packaging .NET applications. The Installer can install, remove and update Win32 and .NET assemblies, including side-by-side and private assemblies in Windows XP. To avoid common problems, follow these rules when using assemblies:

General:

  • A component should contain no more than one assembly.
  • All of the files in an assembly should be in a single component.
  • Each component that contains an assembly should have an entry in the MsiAssembly table.
  • The strong assembly cache name of each assembly should be authored into the MsiAssemblyName table.
  • Use the Registry table instead of the Class table when you register COM Interop for an assembly.
  • Assemblies that have the same strong name are the same assembly. When the same assembly is installed by different applications, the components that contain the assembly should use the same value for the ComponentId in their Component tables.

Win32 Assemblies:

  • Do not use the manifest file or the catalogue file as the KeyPath in the Component table for the component containing the Win32 assembly.
  • The KeyPath value in the Component table for a component that contains a Win32 policy assembly should be Null.
  • Add a row to the MsiAssemblyName table for each name and value pair that are listed in the <assemblyIdentity> section of the Win32 assembly’s manifest.

.NET Assemblies:

  • The KeyPath value in the Component table for a component that contains the assembly should not be Null.
    When you install an assembly used by the common language runtime to the global assembly cache, the value in the File_Application column of the MsiAssembly table must be Null.
  • Add a row to the MsiAssemblyName table for each attribute of the assembly’s strong name. All assemblies must have the Name, Version, and Culture attributes that are specified in the MsiAssemblyName table. A publicKeyToken attribute is required for a global assembly.

10 comments

  1. Hi, under gerneral, these apply to *ANY* type of package / installation, not just .NET apps. But a good head’s up anyway

  2. Hi, under gerneral, these apply to *ANY* type of package / installation, not just .NET apps. But a good head’s up anyway

  3. Thanks for your comments buddy. Well, this information which is put up here was an MSDN extract.

    Henceforth, I would request you to use your name for commenting. It would be great to know you..rather than being “anonymous”

  4. Thanks for your comments buddy. Well, this information which is put up here was an MSDN extract.Henceforth, I would request you to use your name for commenting. It would be great to know you..rather than being “anonymous”

  5. Assemblies installed to the global assembly cache by a per-user installation are not protected by Windows File Protection. Assemblies that are installed to the global assembly cache by a per-machine installation are protected by Windows File Protection.

  6. Assemblies installed to the global assembly cache by a per-user installation are not protected by Windows File Protection. Assemblies that are installed to the global assembly cache by a per-machine installation are protected by Windows File Protection.

  7. Thanks buddy for this valuable information,but under WIN32 assemblies if we do not specify KEYPATH for component containing WIN32 assembly then it would voilate Component rule(Every component should have key path).

  8. Thanks buddy for this valuable information,
    but under WIN32 assemblies if we do not specify KEYPATH for component containing WIN32 assembly then it would voilate Component rule(Every component should have key path).

  9. Yes Sush. Its true. But those components should not have a keypath as it would repair…and you never want a component to repair when its shared right?

  10. Yes Sush. Its true. But those components should not have a keypath as it would repair…and you never want a component to repair when its shared right?

Leave a Reply

Your email address will not be published. Required fields are marked *