Developers of many application programs (“applications”) implement the applications so that they can be customized by third parties.  To customize an application, a third party develops custom code (e.g., add-ins and document-level customizations) that uses functionality exposed by the application.  The custom code may improve the usability of the applications or provide additional functionality (e.g., domain-specific functionality).  Such applications are referred to as “host applications” because the custom code is hosted within the process of the application.  Developers of applications typically want to encourage the development of custom code for their applications to increase the demand for their applications.  As a result, such developers may provide “custom code runtimes” that facilitate the development of custom code.  A runtime is code that is loaded along with custom code and provides services to the custom code.  These services may include higher-level functionality than that exposed by the application or may include domain-specific functionality.  When an application is to load and start the execution of custom code, the application may load the runtime and direct the runtime to load and start the execution of the custom code. 
Because of the ease of developing custom code as “managed code,” many applications support the execution of custom code in the .NET Framework provided by Microsoft Corporation.  The .NET Framework provides a common language runtime (“CLR”) that provides high-level operating system type services to the managed programs (including custom code and applications) and serves as an execution engine for managed programs.  The CLR ensures that managed programs do not take any unauthorized action.  As such, the CLR acts as a “sandbox” within which managed programs execute.  The CLR provides application domains (“appdomains”) in which different managed programs can execute to help ensure that an errant managed program will not unduly affect the execution of another managed program. 
In some environments, a host application may execute as unmanaged code, and custom code runtimes and custom code may execute as managed code.  A host application provides the definition of the objects (e.g., Component Object Model (“COM”) objects) that it exposes to the managed code via a primary interop assembly (“PIA”).  A PIA provides a specification of the methods of the exposed objects along with the signature of the methods.  A developer of managed code can access the objects exposed by the host application based on the specification provided by the PIA.  The .NET Framework provides the support needed for invoking such an exposed object across the application domain of the host application executing as unmanaged code and the application domain of the managed code. 
Custom code runtimes provide “wrappers” to objects exposed by the host application.  These wrappers may hide some of the complexity of the exposed objects and may provide higher-level functionality that facilitates the development of custom code.  The custom code runtimes may allow the custom code to access an exposed object only via the wrapper and not directly.  The exposed objects that are wrapped by the custom code runtimes may include application-level objects and document-level objects.  An application-level object is an object that provides general access to the exposed features of the host application that are not specific to manipulating a document.  A document-level object, in contrast, is an object that provides access to the exposed features of the host application that are for manipulating a document.  For example, an application-level object may expose a feature that allows managed code to add a window at the bottom of the window of the host application that displays scrolling stock prices.  A document-level object may expose a feature that allows managed code to insert a value into the cell of an opened spreadsheet.  A wrapper for a document-level object for a spreadsheet may allow cells of a spreadsheet to be bound to a data source.  For example, each row of the spreadsheet may be bound to a record of a table of a database, and each column may be bound to different fields of the table.  When a field of a record of the table is updated, the wrapper interacts with the document-level object to update the corresponding cell of the spreadsheet.  Similarly, when a cell of the spreadsheet is updated, the wrapper is notified by the document-level object and updates a corresponding field in the database. 
FIG.  1 illustrates an architecture that uses adapters for objects of unmanaged host applications.  A host process 100 includes a host application 110, custom code 120, and a custom code runtime 130.  The host application executes as unmanaged code, and both the custom code runtime and the custom code execute as managed code in separate application domains as indicated by application domain boundaries 101.  The host application provides document-level object 111 and application-level object 112, and the custom code runtime provides wrappers 131 and 132.  The custom code accesses the objects exposed by the host application via the wrappers. 
A difficulty with such an architecture results when a host application and its custom code runtime are on different release cycles.  If a new version of the host application is released that provides new functionality for an exposed object, the wrapper of the current version of the custom code runtime cannot access the new functionality of the exposed object.  Nevertheless, existing custom code using the current version of the custom code runtime will likely continue to work correctly with the new version of the host application because host applications typically try to maintain such compatibility.  For example, new functionality may be provided by new methods of an exposed object, rather than changing existing methods.  The difficulty resulting from the different release cycles of the host application and custom code runtime is that a developer of custom code cannot release a new version of the custom code that takes advantage of the new functionality of the host application until a new version of the custom code runtime is released with a new version of the wrapper that exposes the new functionality through the wrapper.  Thus, no custom code can be released to take advantage of the new functionality of the host application or any functionality of a new host application until after the next release of the custom code runtime with the new versions of wrappers for the new functionality or new wrappers for the functionality of the new host application.