NGWS SDK Documentation  

This is preliminary documentation and subject to change.
To comment on this topic, please send us email at ngwssdk@microsoft.com. Thanks!

Locating the Assembly through Probing

In the absence of a codebase describing the location of the assembly, the AssemblyResolver probes for the assembly under the AppBase. The term probing refers to the set of heuristics used to locate the assembly based on its name and culture.

Note that the version of the assembly probed for may differ from the original reference if rules in the application configuration file redirected the original bind to a different version.

By default, the assemblies that are actually deployed in the application directory need not match the bind reference exactly. It is possible for an application author to deploy new assemblies in the application directory that will still satisfy the bind, provided the newer assemblies only contain updates in the revision and/or build number of the assembly.

The AssemblyResolver always probes for the name of the assembly concatenated with three extensions (listed in order of priority):

  1. .MCL
  2. .DLL
  3. .EXE

The AssemblyResolver will always begin probing in the AppBase directory. That is, the first probing URLs generated will always the concatenation of the AppBase, the assembly name, and extension. For example, if the AppBase is c:\program files\myapp and the assembly name is FOO, then the first probing URLs generated will be:

c:\program files\myapp\foo.mcl, 
c:\program files\myapp\foo.mcl, and 
c:\program files\myapp\foo.exe

If the assembly is not found in the AppBase, probing continues in the directories on the assembly search path. The search path is specified using the <AppDomain> tag in the application configuration file:

<AppDomain PrivatePath="utils"/>

The directories given on the search path are relative to the AppBase and must be subdirectories of the AppBase. You cannot use this path to bind to assemblies outside the AppBase. Assemblies outside the AppBase must have shared names and must either be installed in the global assembly cache or pointed to using a codebase as described above.

In addition to the subdirectories given in the configuration file, the NGWS runtime always prepends a directory corresponding to the name of the assembly being probed for. For example, given the path specified above, if the NGWS runtime were probing for “caclr” it would modify the search path to be:

calcr;bin

The AssemblyResolver also considers the culture of the assembly when generating probing URLs. Specifically, the AssemblyResolver will look in culture-specific subdirectories under each directory on the search path. The name of the this subdirectory is the culture name as specified by RFC1766.

Probing is best understood by looking at all the URLs generated for a specific example:

NAME=MyName

APPBASE=http://www.wingtiptoys.com

SEARCH PATH=bin (The AssemblyResolver changes this to: MyName;bin)

LOCALE=de

Explicit Codebases:

Binding context CODEBASE=http://www.tailspintoys.com/codebase.exe

App.cfg CODEBASE=[none]

Probing URLs:

  1. http://www.tailspintoysr.com/codebase.exe
  1. http://www.wingtiptoys.com/MyName.MCL
  2. http://www.wintiptoys.com/MyName.DLL
  3. http://www.wingtiptoys.com/MyName.EXE
  1. http://www.wingtiptoys.com/MyName/MyName.MCL
  2. http://www.wingtiptoys.com/MyName/de/MyName.MCL
  3. http://www.wingtiptoys.com/bin/MyName.MCL
  4. http://www.wingtiptoys.com/bin/de/MyName.MCL
  1. http://www.wingtiptoys.com/MyName/MyName.DLL
  2. http://www.wingtiptoys.com/MyName/de/MyName.DLL
  3. http://www.wingtiptoys.com/bin/MyName.DLL
  4. http://www.wingtiptoys.com/bin/de/MyName.DLL
  1. http://www.wingtiptoys.com/MyName/MyName.EXE
  2. http://www.wingtiptoys.com/MyName/de/MyName.EXE
  3. http://www.wingtiptoys.com/bin/MyName.EXE
  4. http://www.wingtiptoys.com/bin/de/MyName.EXE

If the reference did not contain an Originator (i.e was to a private assembly), the binding process stops at this point. If a match was found, that assembly is returned to the loader. If no match was found, an error is raised. This error ends up as a TypeLoadException in managed code.

If the reference was to an assembly with a shared name, the binding process continues by looking in the global assembly cache.