PrimoBurner, DVDBuilder and PrimoMpeg runtime requirements - Part 2

As it was stated in a previous post the .NET versions of PrimoBurner, DVDBuilder and PrimoMpeg require the presence of a specific VC runtime. Each .NET assembly that we provide (PrimoBurner.NET.dll, DVDBuilder.NET.dll, PrimoMpeg.NET.dll) contains a manifest in which the required CRT is described. This CRT dependency is something that is not easily controlled as it is a consequence of several factors: Visual Studio version (20005/2008), VS service packs, Windows Updates and preprocessor #defines. Instead of forcing a .NET assembly to link against a specific CRT version, we provide the merge modules for the CRT that we use.

The following CRT dependency list gives the required CRT version and the merge modules for our .NET products:

PrimoBurner 3.0.4 for .NET Framework 2.0
CRT 8.0.50727.4053 : 32-bit runtime, policy / 64-bit runtime, policy

PrimoBurner 3.0.4 for .NET Framework 3.0/3.5 
CRT 9.0.30729.4148 : 32-bit runtime, policy / 64-bit runtime, policy

DVDBuilder 2.0.5 for .NET Framework 2.0
CRT 8.0.50727.4053 : 32-bit runtime, policy / 64-bit runtime, policy

DVDBuilder 2.0.5 for .NET Framework 3.0/3.5
CRT 9.0.30729.4148 : 32-bit runtime, policy / 64-bit runtime, policy

PrimoMpeg 1.0.5 for .NET Framework 2.0
CRT 8.0.50727.4053 : 32-bit runtime, policy / 64-bit runtime, policy

PrimoMpeg 1.0.5 for .NET Framework 3.0/3.5
CRT 9.0.30729.4148 : 32-bit runtime, policy / 64-bit runtime, policy

Strictly, it is not required to use the policy. (and we don't use it in our SDK installers). The policy merely redirects existing applications which use an older CRT to the currently installed version. This may help when a program uses 3rd-party components which have different CRT dependencies. In this case the application needs to provide only the highest CRT version that it uses and the corresponding policy. CRT redirection does not work between major versions (8.0.* and 9.0.*).

It is much safer to include the appropriate CRT merge modules in the installer than using vcredist_<arch>.exe. It is safer because the merge modules use reference counting and this guarantees that the CRT won't be removed from the system as long as the application is installed. On the other hand vcredist does not use reference counting and it may be removed either by another misbihaving uninstaller or by the user (since the vcredist entry is not related to the application entry). This may break the existing application.