codeBase Path

If the assembly is still not found, the runtime inspects the element (within ) of the three configuration files mentioned above, each file overriding the other as before. If the assembly is strongly named, the codebase could point anywhere, including, say "http://www.myCompany.com/somepath". If it is not strongly named, the path must be inside and relative to the application directory, and any redirected version information is ignored. In this example, the assembly at "somePath\someAssembly.dll", if not strongly named, will be loaded regardless of any version redirection.

    <codeBase version="2.0.0.0" href="somePath\someAssembly.dll" />

If the element exists for the assembly and it is not found in the specified location, the runtime will give up and cause an exception.

Probing

If there's no element and the assembly hasn't been found, the runtime starts "probing". It starts by searching for the assembly in the same location as the application.

    [application root]/([culture, if specified]/)[assembly name].dll
    [application root]/([culture, if specified]/)[assembly name]/[assembly name].dll

The runtime can also be instructed to search for the required assembly by probing other specific directories, using the element in the config file, or at runtime by calling AppDomain.AppendPrivatePath(). Paths specified at runtime are checked before those specified in the config files. In this example, the element (which is in ) instructs the runtime to probe two additional paths for the assembly:

    <probing privatePath="subdir1;subdir1\sub-subdir" />

These paths are probed in the same manner as before, testing first the path (with culture information if specified), then the path (with culture information if specified) and any subdirectory with the assembly name.