Abstract: A runtime activation system uses a set of policies designed to provide a balance between backwards compatibility and ease of migrating existing (non side-by-side aware) applications to new runtime versions. The system chooses the runtime version to activate when an application runs or when a runtime application programming interface is invoked based on the set of policies. The system implements these policies by consulting compatibility data associated with the application indicating the intent of the author and level of side-by-side support provided by the application and/or global configuration data. Based on the compatibility data, the system chooses policies that are right in the most common cases, and easy to modify in less common cases. Thus, the runtime activation system allows applications to be flexibly configured to handle new runtime versions in a manner determined by the application author, a system administrator, or others.

Abstract: The efficient use of type descriptors with frozen objects. A frozen object might actually include several type descriptors, a primary type descriptor that is canonical according to a set of canonicalization rules, and an auxiliary type descriptor that is not identical to the primary type descriptor. The auxiliary type descriptor may be used to access the canonical type descriptor. When performing an operation, if the auxiliary type descriptor can be used to perform the operation, then that auxiliary type descriptor may be used. If the canonical type descriptor is to be used to perform the operation, the auxiliary type descriptor is used to gain access to the canonical primary type descriptor. The primary type descriptor is then used to perform the operation.

Abstract: Mechanisms that allow frameworks significant flexibility in varying the library of common base classes in a manner that better suits the domain of applications served by the framework. Instead of providing the base class library, the runtime provides a data contract for the data structure of each base class. The frameworks can then define each base class in a custom way so long as the data contract is honored. Thus, for example, the framework may provide custom framework-specific methods and/or properties as is appropriate for the framework. Another framework might define the base classes in a different way.

Abstract: A runtime activation system uses a set of policies designed to provide a balance between backwards compatibility and ease of migrating existing (non side-by-side aware) applications to new runtime versions. The system chooses the runtime version to activate when an application runs or when a runtime application programming interface is invoked based on the set of policies. The system implements these policies by consulting compatibility data associated with the application indicating the intent of the author and level of side-by-side support provided by the application and/or global configuration data. Based on the compatibility data, the system chooses policies that are right in the most common cases, and easy to modify in less common cases. Thus, the runtime activation system allows applications to be flexibly configured to handle new runtime versions in a manner determined by the application author, a system administrator, or others.

Abstract: Mechanisms that allow frameworks significant flexibility in varying the library of common base classes in a manner that better suits the domain of applications served by the framework. Instead of providing the base class library, the runtime provides a data contract for the data structure of each base class. The frameworks can then define each base class in a custom way so long as the data contract is honored. Thus, for example, the framework may provide custom framework-specific methods and/or properties as is appropriate for the framework. Another framework might define the base classes in a different way.

Abstract: The efficient use of type descriptors with frozen objects. A frozen object might actually include several type descriptors, a primary type descriptor that is canonical according to a set of canonicalization rules, and an auxiliary type descriptor that is not identical to the primary type descriptor. The auxiliary type descriptor may be used to access the canonical type descriptor. When performing an operation, if the auxiliary type descriptor can be used to perform the operation, then that auxiliary type descriptor may be used. If the canonical type descriptor is to be used to perform the operation, the auxiliary type descriptor is used to gain access to the canonical primary type descriptor. The primary type descriptor is then used to perform the operation.

Abstract: Embodiments described herein are directed to extending a software interface to include non-public functions. In one embodiment, a computer system receives a user input indicating that an interface is to be used to manage code inheritance in the generation of a software application. The interface includes a public functions declaration identifying functions that are publicly available to generate an application. The computer system determines that the received indication indicates that a non-public function is to be used in addition to any public functions, where the non-public function is accessible through the interface. The computer system also generates a software application using the non-public function and a public function, as indicated in the received user input.

Abstract: Embodiments are directed to providing intermediate language (IL) code on a per-method basis for at least one method of a binary. In one embodiment, a computer system selects a method from among various methods included in a binary file, where the methods are configured to perform various intended functions for an application. The computer system appends a descriptive marker to the selected method indicating how to obtain IL code that is to be included in the body of the selected method, receives a command to execute the selected method, and refers to the appended descriptive marker to generate an IL code request based on the indication in the descriptive marker. The computer system submits the generated IL code request to one or more IL code providers to request IL code for the selected method, receives the requested IL code for the selected method and inserts the IL code into the body of the selected method.