Type Forwarding
For large applications and class libraries, managing the dependency hierarchy among the various assemblies that make up the library can be a challenging exercise. To avoid circular references among assemblies, the natural tendency is to place all types in one big assembly. This has a number of issues—bigger assemblies are slower to download and load, rebuild time is slower in development, and allowing a library to collapse into one big entwined mess under the pressure of entropy eventually makes it difficult to use and prevents extensibility. The obvious solution is to factor types into smaller libraries with well-known and well-managed dependency relations.
Even in the best engineered libraries, new technologies and new requirements that make the dependency factoring decisions made in a previous version of the library invalid. Moving types around so that they are again housed in the appropriate assembly is the simplest solution, but this introduces compatibility issues with code compiled against an earlier version, which will fail at runtime when attempting to use a type that is no longer present in an assembly.
To solve this problem, a type can leave a forwarding address that the .NET runtime will use to locate the new location of a particular type. In version x of an assembly, a type called Customer may be present:
public ref class Customer {};In version x+1 of the assembly, the type may be moved to a new assembly, say NewAssembly.dll. To allow the .NET runtime to find Customer, type forwarding can be used:
#using "NewAssembly.dll"
[assembly:TypeForwardedTo(Customer::typeid)];
Read the Rest of this Article at Developer.com