This screen allows you to select options which control the AppDomain and Assembly load, process, and management.

The options are described below:

As part of it's normal operation, BitDiffer must load external assemblies in order to compare them. The .NET loader will not allow loading of 2 assemblies with the same strong name into the same AppDomain (referred to as a "version conflict" in this documentation), but BitDiffer requires this functionality to be useful. Therefore, AppDomains must be created for loading assemblies. Loading and unloading AppDomains is an expensive operation, so this isolation level option lets you control the tradeoff between performance and assembly version conflict risk. The available levels are:

• Automatic

Automatic is the recommended option. The automatic mode isolation level will scan the assemblies before loading them, and select the Medium isolation level if possible, or revert to the High isolation level if you have multiple assemblies with the same strong name in the same directory. Use this option unless you have a specific reason to change it.

• High

In high isolation level, each assembly is loaded into it's own private AppDomain. This isolation level provides the maximum safety from conflicting assembly versions, but also yields the worst performance.

• Medium

In medium isolation level, each directory from which assemblies are loaded has it's own AppDomain. This option is appropriate in most situations and provides an ideal balance. It is possible, however, to have version conflict errors if you manually copy and rename assemblies with the same strong name into the same directory.

• Low

The low option is not available in the GUI but can be selected in the command line application. The low option creates a single AppDomain to host all external assemblies. This option creates excessive risk without much performance gain.

• None

The none option is not available in the GUI but can be selected in the command line application. The none option loads all assemblies directly into the BitDiffer application domain. This option is not appropriate in any conceivable scenario.

Assemblies can be loaded into different AppDomain contexts. The reflection context uses the xxxReflectionOnly API and provides access only to the assembly metadata. The execution context load the assembly using the direct load API without restriction.

Changing this option may yield slightly different performances based on your scenario. In general, it is appropriate for BitDiffer to load assemblies using the reflection context due to the nature of the work it is doing.

When an assembly is loaded for analysis and it's types and methods are inspected, any referenced assemblies must also be loaded. This option controls where assemblies are searched in order to resolve a reference. Prefer Local Folder will search first in the same folder of the assembly for the reference. Prefer GAC will search first in the GAC for the assembly reference.

Prefer Local Folder emulates the normal .NET assembly resolution process and so is probably the appropriate choice unless you have a specific reason to change it.

BitDiffer can perform the analysis work of extracting metadata from assemblies in parallel. This has the potential to greatly speed up performance on appropriate CPU architectures. If you have a dual or multi-core CPU (or multiple CPUs), select the multithread option to take advantage of all CPU cores. If you have a one single-core CPU, the multithread option will create more context switches and possibly hinder performance. In this case, select the singlethread option.