Each package fragment installer represents an installation step defined in install.xml

The <mi:PackageFragmentInstallers /> element contains the steps to be executed during installation.

You define each install (or uninstall) step as a specific package fragment installer with an <mi:Add /> element, which have the following layout:

<mi:Add 
      installerType="Namespace.InstallClassName, AssemblyName"
      uninstallerType=" Namespace.UninstallClassName, AssemblyName ">
      <!-- CUSTOM XML – THIS IS PASSED ON TO THE FRAGMENT INSTALLER -->
</mi:Add>

This element contains the following attributes:

• installerType: The full name of type implementing the IPackageFragmentInstaller interface. This is a required attribute.
• uninstallerType: Full name of type implementing the IPackageFragmentUninstaller interface. This is a required attribute only if the package can be uninstalled.

Any elements placed inside the <mi:Add /> element is passed on to the installer class at runtime. This is how you can ‘customize’ the behavior of a fragment installer.

The fragment installers are called one by one, in the sequence they have in install.xml. When uninstalling, the fragment (un)installers are executed in reverse order.

Here is a shortened version of installation steps defined in install.xml of the Composite.Community.Blog package:

<mi:PackageFragmentInstallers>
	<mi:Add 
		installerType="Composite.Core.PackageSystem.PackageFragmentInstallers.FilePackageFragmentInstaller, Composite" 
		uninstallerType="Composite.Core.PackageSystem.PackageFragmentInstallers.FilePackageFragmentUninstaller, Composite">
		<Files>
			<File sourceFilename="~\Bin\CookComputing.XmlRpcV2.dll" 
				targetFilename="~\Bin\CookComputing.XmlRpcV2.dll" allowOverwrite="false" />
			<!-- other related elements -->
		</Files>			
		<Directories>
			<Directory sourceDirectory="~\Frontend\Composite\Community\Blog\" 
				targetDirectory="~\Frontend\Composite\Community\Blog\" allowOverwrite="true" 
				deleteTargetDirectory="false" />
			<!-- other related elements -->
		</Directories>
	</mi:Add>
	<mi:Add 
		installerType="Composite.Core.PackageSystem.PackageFragmentInstallers.DynamicDataTypePackageFragmentInstaller, Composite" 
		uninstallerType="Composite.Core.PackageSystem.PackageFragmentInstallers.DynamicDataTypePackageFragmentUninstaller, Composite">
    <Types>
		<Type providerName="GeneratedDataTypesElementProvider" ...  />
		<!-- other related elements -->
	</Types>		
	</mi:Add>
	<mi:Add 
		installerType="Composite.Core.PackageSystem.PackageFragmentInstallers.DataPackageFragmentInstaller, Composite" 
		uninstallerType="Composite.Core.PackageSystem.PackageFragmentInstallers.DataPackageFragmentUninstaller, Composite">
		<Types>
			<Type isDynamicAdded="true" type="Composite.Community.Blog.Tags">
				<Data dataScopeIdentifier="public" locale="?"  
					dataFilename="~\Datas\Composite.Community.Blog.Tagss_public.xml" />
			</Type>
			<!-- other related elements -->
		</Types>
	</mi:Add>
	<mi:Add 
		installerType="Composite.Core.PackageSystem.PackageFragmentInstallers.FileXslTransformationPackageFragmentInstaller, Composite" 
		uninstallerType="Composite.Core.PackageSystem.PackageFragmentInstallers.FileXslTransformationPackageFragmentUninstaller, Composite">
		<XslFiles>
			<XslFile pathXml="~\Web.config" installXsl="~\Config\Install.xsl" />
		</XslFiles>
	</mi:Add>
</mi:PackageFragmentInstallers>

Package Fragment Installers

Normally, when you create a CMS Package with the Package Creator, the package fragment installers are defined in this element for you.

Some of them copy files from the package's ZIP file to the website at specific paths, others create required data types and populate them with some data, still others do some more specific operations like updating configurations.

If you need specific changes to the way package fragment installers copy files and folders or update the C1 CMS configuration, you may want to know how to add and configure these fragment installers in install.xml:

• FilePackageFragmentInstaller
• ConfigurationTransformationPackageFragmentInstaller

For updating and transforming XML files (for example, Web.config) or modifying text-like files (for example, CSS files), look into these fragment installers:

• FileXslTransformationPackageFragmentInstaller
• XmlFileMergePackageFragmentInstaller
• FileModifyPackageFragmentInstaller

As in many cases a CMS Package creates data types with some data, these are other commonly used fragment installers:

• DynamicDataTypePackageFragmentInstaller
• DataTypePackageFragmentInstaller
• DataPackageFragmentInstaller

To handle trial licenses when installing commercial CMS Packages, this package fragment installer is used:

• PackageLicenseFragmentInstaller

Other package fragment installers are:

• DllPackageFragmentInstaller
• LocalePackageFragmentInstaller
• UserGroupUserAdderFragmentUninstaller
• PackageVersionBumperFragmentInstaller

Besides, you can create your own package fragment installer and use it in your install.xml along with the standard ones.