Runtime services for network software platform

Runtime services for network software platforms are described. In one implementation, runtime services are configured for a web application. A configuration file is created containing tags that provide references to configuration information specific to operational behavior of the web application. The configuration file is read upon receiving a request to start the web application. The runtime services for the web application are initialized based on the configuration information read from the configuration file.

TECHNICAL FIELD

This invention relates to network software, such as Web applications, and computer software development of such network software.

BACKGROUND

Microsoft Corporation has developed a network software platform known as the “.Net” platform (read as “Dot Net”). The platform allows developers to create Web services and applications that will execute over the Internet. The .Net platform is a software platform for Web services and Web applications implemented in a distributed computing environment. It represents the next generation of Internet computing, using open communication standards to communicate among loosely coupled Web services that are collaborating to perform a particular task. Active Server Pages (ASP) has long been the foundation for creating rich and dynamic Web sites using server-side scripting. Through the use of the .NET platform, ASP has evolved into “ASP.NET,” which is a set of technologies in the Microsoft .NET Framework for building Web applications and Web Services.

One of the challenges facing developers using the aforementioned technology as well as related Web site development and server software is the amount of code that needs to be written by developers in order to create objects in applications running on Web servers. Currently, a large amount of code is needed to create objects and “glue” them together, which is time consuming for developers to create and subject to errors.

Another challenge facing developers is figuring out interrelationships between programmable systems. For instance, what happens if an object is removed from an application? Will it cause the Web site to crash? Determining accurate interrelationships between many different systems can be an extremely difficult for custom developers of Web sites.

Memory is another issue facing developers of applications running on the Web. Memory is limited, and therefore, the developer typically writes code to ensure that objects are freed from memory. However, with the open nature of many network software platforms, many times the data structures used for particular objects and the code associated with such structures are incompatible. Thus, there may be a failure to recognize when an object is no longer being used by an application, because the object isn't managed by the particular platform it is running-on. As a result, many objects can continue to use memory resources beyond a period of time when they should have been removed from memory.

SUMMARY

Runtime services for network software platforms are described. In one implementation, runtime services are configured for a web application. A configuration file is created containing tags that provide references to configuration information specific to operational behavior of the web application. The configuration file is read upon receiving a request to start the web application. The runtime services for the web application are initialized based on the configuration information read from the configuration file.

In another implementation, unmanaged objects associated with Web applications are automatically expunged from memory. A request to process a Web page containing unmanaged objects operating on a Web server is received. A reference pointer is assigned to the unmanaged object and the reference pointer is stored in a data structure. The unmanaged object is stored in memory. When a notification is received that the web page containing the unmanaged object is no longer being processed the reference pointer is used to locate the unmanaged object from memory. Once located, the unmanaged object is then removed from memory.

In another implementation, programmable misuse of configuration information associated with objects is prevented. A dependency database is maintained describing dependencies associated with modules used by an application. Information entered by a programmer describing how the programmer desires to use the modules in an application is received. A check is made whether the information entered by the programmer matches the dependencies associated with the modules maintained in the database. If the entered information does not match the dependencies, then an error exception notification is enabled.

DETAILED DESCRIPTION

Overview

To overcome inefficiencies and problems described in the Background section, the following description introduces the broad concept of providing an extensible programming framework that streamlines building of Web applications. This is accomplished through several different implementations. In one implementation, an application run time and configuration file (catalogue) stores information that enables a developer to configure and initialize applications, eliminating most initialization coding for objects. In another implementation, a run time disposal system removes objects from memory including those objects across disparate systems. And in another implementation, the runtime permits dependencies between systems (or objects) to be mapped to prevent a developer from rendering an application into an unstable state.

Various application program interfaces (APIs) for a network platform upon which developers can build Web applications and services are described herein. In the exemplary implementation the .NET platform created by Microsoft Corporation is described. The .NET platform is a software platform for Web services and Web applications implemented in the distributed computing environment.

In the described implementation, the .NET platform utilizes XML (extensible markup language), an open standard for describing data. XML is managed by the World Wide Web Consortium (W3C). XML is used for defining data elements on a Web page and business-to-business documents. XML uses a similar tag structure as HTML; however, whereas HTML defines how elements are displayed, XML defines what those elements contain. HTML uses predefined tags, but XML allows tags to be defined by the developer (also referred to as the “programmer”) of the page. Thus, virtually any data items can be identified, allowing Web pages to function like database records. Through the use of XML and other open protocols, such as Simple Object Access Protocol (SOAP), the .NET platform allows integration of a wide range of services that can be tailored to the needs of the user. Although the embodiments described herein are described in conjunction with XML and other open standards, such are not required for the operation of the claimed invention. Other equally viable technologies will suffice to implement the inventions described herein.

As used herein, the phrase application program interface or API includes traditional interfaces that employ method or function calls, as well as remote calls (e.g., a proxy, stub relationship) and SOAP/XML invocations.

Exemplary Network Environment

FIG. 1shows a network environment100in which a network platform, such as the .NET platform, may be implemented. The network environment100includes representative Web services102(1), . . . ,102(N), which provide services that can be accessed over a network104(e.g., Internet). The Web services, referenced generally as number102, are programmable application components that are reusable and interact programmatically over the network104, typically through industry standard Web protocols, such as XML, SOAP, WAP (wireless application protocol), HTTP (hypertext transport protocol), and SMTP (simple mail transfer protocol) although other means of interacting with the Web services over the network may also be used, such as Remote Procedure Call (RPC) or object broker type technology. A Web service can be self-describing and is often defined in terms of formats and ordering of messages.

Web services102are accessible directly by other services (as represented by communication link106) or a software application, such as Web application110(as represented by communication links112and114). Each Web service102is illustrated as including one or more servers that execute software to handle requests for particular services. Such services often maintain databases that store information to be served back to requesters. Web services may be configured to perform any one of a variety of different services. Examples of Web services include login verification, notification, database storage, stock quoting, location directories, mapping, music, electronic wallet, calendar/scheduler, telephone listings, news and information, games, ticketing, and so on. The Web services can be combined with each other and with other applications to build intelligent interactive experiences.

The network environment100also includes representative client devices120(1),120(2),120(3),120(4), . . . ,120(M) that utilize the Web services102(as represented by communication link122) and/or the Web application110(as represented by communication links124,126, and128). The clients may communicate with one another using standard protocols as well, as represented by an exemplary XML link131between clients120(3) and120(4).

The client devices, referenced generally as number120, can be implemented many different ways. Examples of possible client implementations include, without limitation, portable computers, stationary computers, tablet PCs, televisions/set-top boxes, wireless communication devices, personal digital assistants, gaming consoles, printers, photocopiers, and other smart devices.

The Web application110is an application designed to run on the network platform and may utilize the Web services102when handling and servicing requests from clients120. The Web application110is composed of one or more software applications130that run atop a programming framework132, which are executing on one or more servers134or other computer systems. Note that a portion of Web application110may actually reside on one or more of clients120. Alternatively, Web application110may coordinate with other software on clients120to actually accomplish its tasks.

The programming framework132is the structure that supports the applications and services developed by application developers. It permits multi-language development and seamless integration by supporting multiple languages. It supports open protocols, such as SOAP, and encapsulates the underlying operating system and object model services. The framework provides a robust and secure execution environment for the multiple programming languages and offers secure, integrated class libraries.

The framework132is a multi-tiered architecture that includes an application program interface (API) layer142, a common language runtime (CLR) layer144, and an operating system/services layer146. This layered architecture allows updates and modifications to various layers without impacting other portions of the framework. A common language specification (CLS)140allows designers of various languages to write code that is able to access underlying library functionality. The specification140functions as a contract between language designers and library designers that can be used to promote language interoperability. By adhering to the CLS, libraries written in one language can be directly accessible to code modules written in other languages to achieve seamless integration between code modules written in one language and code modules written in another language. One exemplary detailed implementation of a CLS is described in an ECMA standard created by participants in ECMA TC39/TG3. The reader is directed to the ECMA web site at www.ecma.ch.

The API layer142presents groups of functions that the applications130can call to access the resources and services provided by layer146. By exposing the API functions for a network platform, application developers can create Web applications for distributed computing systems that make full use of the network resources and other Web services, without needing to understand the complex inter-workings of how those network resources actually operate or are made available. Moreover, the Web applications can be written in any number of programming languages, and translated into an intermediate language supported by the common language runtime144and included as part of the common language specification140. In this way, the API layer142can provide methods for a wide and diverse variety of applications.

Additionally, the framework132can be configured to support API calls placed by remote applications executing remotely from the servers134that host the framework. Representative applications148(1) and148(2) residing on clients120(3) and120(M), respectively, can use the API functions by making calls directly, or indirectly, to the API layer142over the network104.

The framework may also be implemented at the clients. Client120(3) represents the situation where a framework150is implemented at the client. This framework may be identical to server-based framework132, or modified for client purposes. Alternatively, the client-based framework may be condensed in the event that the client is a limited or dedicated function device, such as a cellular phone, personal digital assistant, handheld computer, or other communication/computing device.

Developers' Programming Framework

FIG. 2shows the programming framework132in more detail. The common language specification (CLS) layer140supports applications written in a variety of languages130(1),130(2),130(3),130(4), . . . ,130(K). Such application languages include Visual Basic, C++, C#, COBOL, Jscript, Perl, Eiffel, Python, and so on. The common language specification140specifies a subset of features or rules about features that, if followed, allow the various languages to communicate. For example, some languages do not support a given type (e.g., an “int*” type) that might otherwise be supported by the common language runtime144. In this case, the common language specification140does not include the type. On the other hand, types that are supported by all or most languages (e.g., the “int[]” type) is included in common language specification140so library developers are free to use it and are assured that the languages can handle it. This ability to communicate results in seamless integration between code modules written in one language and code modules written in another language. Since different languages are particularly well suited to particular tasks, the seamless integration between languages allows a developer to select a particular language for a particular code module with the ability to use that code module with modules written in different languages. The common language runtime144allow seamless multi-language development, with cross language inheritance, and provide a robust and secure execution environment for the multiple programming languages. For more information on the common language specification140and the common language runtime144, the reader is directed to co-pending applications entitled “Method and System for Compiling Multiple Languages”, filed Jun. 21, 2000 (Ser. No. 09/598,105) and “Unified Data Type System and Method” filed Jul. 10, 2000 (Ser. No. 09/613,289), which are incorporated by reference.

The framework132encapsulates the operating system146(1) (e.g., Windows®-brand operating systems) and object model services146(2) (e.g., Component Object Model (COM) or Distributed COM). The operating system146(1) provides conventional functions, such as file management, notification, event handling, user interfaces (e.g., windowing, menus, dialogs, etc.), security, authentication, verification, processes and threads, memory management, and so on. The object model services146(2) provide interfacing with other objects to perform various tasks. Calls made to the API layer142are handed to the common language runtime layer144for local execution by the operating system146(1) and/or object model services146(2).

The API142groups API functions into multiple namespaces. Namespaces essentially define a collection of classes, interfaces, delegates, enumerations, and structures, which are collectively called “types”, that provide a specific set of related functionality. A class represents managed heap allocated data that has reference assignment semantics. A delegate is an object oriented function pointer. An enumeration is a special kind of value type that represents named constants. A structure represents static allocated data that has value assignment semantics. An interface defines a contract that other types can implement.

By using namespaces, a designer can organize a set of types into a hierarchical namespace. The designer is able to create multiple groups from the set of types, with each group containing at least one type that exposes logically related functionality. In the exemplary implementation, the API142is organized into four root namespaces: a first namespace200for Web applications, a second namespace202for client applications, a third namespace204for data and XML, and a fourth namespace206for base class libraries (BCL). Each group can then be assigned a name. For instance, types in the Web applications namespace200are assigned the name “Web”, and types in the data and XML namespace204can be assigned names “Data” and “XML” respectively. The named groups can be organized under a single “global root” namespace for system level APIs, such as an overall System namespace. By selecting and prefixing a top level identifier, the types in each group can be easily referenced by a hierarchical name that includes the selected top level identifier prefixed to the name of the group containing the type. For instance, types in the Web applications namespace200can be referenced using the hierarchical name “System.Web”. In this way, the individual namespaces200,202,204, and206become major branches off of the System namespace and can carry a designation where the individual namespaces are prefixed with a designator, such as a “System.” prefix.

The Web applications namespace200pertains to Web based functionality, such as dynamically generated Web pages (e.g., Microsoft's Active Server Pages (ASP)). It supplies types that enable browser/server communication. The client applications namespace202pertains to drawing and client side UI functionality. It supplies types that enable drawing of two-dimensional (2D), imaging, and printing, as well as the ability to construct window forms, menus, boxes, and so on.

The data and XML namespace204relates to connectivity to data sources and XML functionality. It supplies classes, interfaces, delegates, and enumerations that enable security, specify data types, and serialize objects into XML format documents or streams. The base class libraries (BCL) namespace206pertains to basic system and runtime functionality. It contains the fundamental types and base classes that define commonly-used value and reference data types, events and event handlers, interfaces, attributes, and processing exceptions.

In addition to the framework132, programming tools210are provided to assist the developer in building Web services and/or applications. One example of the programming tools200is Visual Studio™, a multi-language suite of programming tools offered by Microsoft Corporation.

Configuration and Initialization Services

FIG. 3shows an exemplary system300for assisting developers in initializing and configuring a Web application302. The exemplary Web application302may include e-commerce business applications and services. For instance, a service that permits customers to purchase items from a Web site may be one example of a type of Web application302used in system300. Additionally, other Web applications110such as those described above with reference toFIGS. 1 and 2could be represented by Web application302.

Web application302includes a set of Web pages304. The set of Web pages are linked together allowing a visitor to move from one page another through a Web browser (not shown) on client devices120(seeFIG. 1). ASP.NET allows those pages to be accessed by the Web browser. The arrangement of pages constitutes a part of a Web site's topology. A page or a set of pages can contain or point to a variety of resources, including images, text, scripts, links to resources and so forth. A user may perform “actions” while on a page of the Web site by “clicking” on a designated location and being linked to a desired location or cause an event to occur. For example, an action may include clicking on and/or interacting with an advertisement, traversing from one page to another, purchasing an item, adding an item to a virtual shopping basket, etc.

Each time a user performs an action on a page, the action calls one or more objects306representing a collection of APIs that permit the actions to occur, which is sometimes referred to as the “runtime” behavior of a Web site. In order to place the Web application302into a state that can be used by a customer, the application's302runtime services308must be configured and initialized. Run time services308include modules307(1), . . . ,307(N), (referenced generally as number307) that provide the capability for a developer to configure and initialize the application302.

The developer uses the runtime services308to create a web configuration file310by inserting configuration information that are necessary to configure the run time services308and the operational behavior of the set of objects306. Typically, a developer initially opens a text editor (not shown) such as a notepad, types in tags (such as XML tags312) pertaining to the configuration, and saves the configuration information in the configuration file310. For instance, using the editor the developer will typically load tags into a Web configuration file310. Each tag generally references some type of runtime configuration information necessary for the Web application302. That is, the tags provide a means for retrieving configuration information from various sources for configuring the Web application302. For example, configuration information can be retrieved from a data source using an SQL query to retrieve the configuration information from the source. The tags in the exemplary implementation take the form of XML tags312, but could utilize other tagging technologies capable of referencing information. Database314stores low level configuration information for the run time services308such as pointers to one or more other databases316(1), . . . ,316(N).

Once the Web configuration file310is created, it can be utilized by Web application302. For example, Web application302starts-up because a user from a client device120browses to the Web site containing Web application302. At the first occurrence of a user requested page from application302, application302starts up (i.e., is loaded into memory of a server). Then, ASP.NET instance (through the collection of APIs306) calls out to the runtime service308based on information in Web configuration file310, which are initially read from the Web configuration file310. Accordingly, the runtime services308are activated as part of the application302. Once activated, the runtime services308reads configuration information specific to the application302from the Web configuration file310. Based on the configuration information read from the configuration file, Web application302is initialized (i.e., put into a state to be used by the Web application302to perform operations). Thus, Web application302through it framework (i.e.,132inFIG. 1) is able to determine which modules need to be created and initialized based on information read from the configuration file310.

FIG. 4is a flow chart illustrating an exemplary method400for configuring and initializing runtime services for a Web application. Method400includes blocks402–408. The order in which the method is described is not intended to be construed as a limitation. Additionally, portions of the operations may be optional, performed intermittently, or performed simultaneously. Furthermore, the method400can be implemented in any suitable hardware, software, firmware, or combination thereof.

At block402a configuration file310is created for Web application302. Typically, the objects306created for the application by a developer requires configuration information in order to initially execute an action request performed on a page from the set of web of pages304. Accordingly, the developer uses tags (e.g., XML tags312) to provide configuration information specific to the operation behavior of the Web application302.

At block404, a request is received to start the application302. The configuration file310is loaded into memory. At block406the configuration file310is read to determine which runtime services308are used in the application302. That is, ASP.NET reads the configuration file310and determines which run time services308to invoke. The runtime services contains one or modules containing resources necessary for the application302to operate. The runtime services308can include application services or page services. “Application services” includes services and data common to the entire application302(such as profiles systems and catalog systems) and are globally available to user sessions. “Page services” includes services and data common to an individual page, accessed within the scope of a user's request to Web site running the Web application302, such as the current user's profile.

At block408, based on the configuration information read from the configuration file310the runtime services308are initialized for the application302. Thus, method400provides automatic initialization of the Web application302and removes the onus on the site developer for creating and manually configuring the set of objects (e.g., runtime objects)306.

Automatic Disposal of Unmanaged Resources

FIG. 5shows a system500that releases unmanaged objects from memory. The system500shows similar components that were described above with reference toFIG. 3, such as a Web application302set of Web pages304, objects306, run time services308. System500includes some additional elements that are part of the Framework132and/or Web application302including a garbage collector502, one or more catalogues504(1), . . . ,504(N) (referenced generally as catalogue504), an interoperable bridge506, memory508and a data structure510.

Garbage collector502manages the allocation and release of data from memory508. Each time an object is created, runtime services308allocates space for the objects in memory508. Because memory508is limited, garbage collector502performs a collection to free memory. Typically, this is accomplished by checking for objects that are no longer being used by the application302and to perform the necessary operations to release the memory used by these objects.

Runtime services308also allocates space for objects in memory508that are not managed by the garbage collector502. These objects are referred to as “unmanaged objects” because they represent references that are not native to the .NET framework. Runtime services308are able to access objects that are not native to the .NET framework through interoperable bridge506, which uses the CLR144(FIG. 1) to assemble the objects in runtime callable wrapper assemblies507(1), . . . ,507(N) (referenced generally as number507). These assemblies507contain metadata which describes the objects stored in each of the assemblies. For example, in one implementation component object model (COM) interoperable objects maintained in catalogue504can be accessed by run time services308through the interoperable bridge506and loaded into memory508. It is possible that other unmanaged objects may be maintained in catalogue504.

One problem arises when attempting to release space from memory508involving objects that are not managed by the garbage collector502, because these objects are pulled from a resource that utilizes technologies that are not native to the .NET framework. The garbage collector502knows that unmanaged objects exist but is unable to automatically purge memory of unmanaged objects (such as COM interoperable objects from COM catalogue504) in a timely manner, because the garbage collector502does not know what data is contained in the runtime callable wrapper assemblies507and therefore doesn't know when data contained in the assemblies is no longer being utilized by the Web application302.

Typically, an unmanaged object is stored in memory508after being requested by Web application302. The unmanaged object will remain in memory beyond the completion of the request. To address this problem, runtime services308assigns reference pointers512(1), . . . ,512(N), to unmanaged objects received from the interoperable bridge506that are requested by Web application302. Each reference pointer, referenced generally as number512, is assigned when the request is made for the unmanaged object. Each reference pointer512is then stored in a data structure510(e.g., a list) maintained in memory508. Each reference pointer512points to a location in memory508in which a corresponding unmanaged object is stored. Web application302sends a notification to run time services308when Web application302completes a request. When run time services308receives the notification, each reference pointer512along with its unmanaged object, pertaining to the request, is forcibly expunged from memory508.

FIG. 6is a flow chart illustrating an exemplary method600for expunging unmanaged objects from memory. Method600includes blocks602–614. The order in which the method is described is not intended to be construed as a limitation. Additionally, portions of the operations may be optional, performed intermittently, or performed simultaneously. Furthermore, the method600can be implemented in any suitable hardware, software, firmware, or combination thereof.

At block602, a request is received to process a Web page containing one or more unmanaged objects. For example, one or more unmanaged objects maintained in the COM catalogue504may be requested for the Web page.

At block604, one or more reference pointers512are assigned to the unmanaged object(s). At block606, each reference pointer is stored. For example each reference pointer512is stored in data structure510maintained in memory508. The reference pointer uniquely identifies the unmanaged object it is assigned to reference. At block608, the unmanaged object(s) are stored in memory508.

At block610, a notification is received indicating that the request for the page containing the unmanaged object(s) is complete. For example, Web application302makes the notification to the runtime services308.

At block612, any unmanaged object(s) associated with completed page that are stored in memory508are located by using the reference pointer(s)512. That is, each reference pointer512stored in data structure510maintained for this page is examined to determine what unmanaged objects should be removed from memory and their locations in memory. At block614, based on the reference pointers512, system500is able to locate and forcibly remove from memory any unmanaged objects maintained in data structure510associated with a particular completed request.

Dependency Management

FIG. 7shows another feature associated with runtime services308for managing dependencies between configuration information associated with programmable components. Runtime services308may utilize one of the programming tools210shown inFIG. 2and may part of the framework132(seeFIG. 1).

Runtime services308through programming tools210permits a programmer708(such as a Web site developer) to configure various programmable components associated with their particular Web application110. Typically, the programmer708uses a configuration file702(such as Web configuration file310shown inFIG. 3) to configure the various programmable components, such as, for example specifying a site name, joining data, specifying a redirecting URL, providing a cache name attribute, and indicating an event pipeline. The aforementioned examples are only a few of many other various attributes that can be configured depending on the Web application. Unfortunately, programmers inevitably make mistakes, either in misusing objects, in omissions, or in incorrectly configuring a particular component.

Dependency manager704maintains a dependency database706describing dependencies associated with modules (i.e., programmable components) used by an application such as a Web application110. For example, referring toFIG. 7, Module307(1) shows dependencies on Modules307(2),307(3),307(4), and307(5). In order for Module307(1) to operate correctly, Modules307(2),307(3),307(4), and307(5) should be available for Module307(1) to access or some type of error may occur that may cause the Web application110to fail. Dependency manager704checks dependency database706to make sure that such dependencies (e.g., Module A depends on Modules B, C, D and E) are adhered to when the application starts up.

If the programmer708makes an error in configuring a module, then dependency manager704will issue some type of error exception notification to the programmer708after checking the dependency database706. The error exception may inform the programmer708of the exact error the programmer made. For example, if the programmer708deletes Module307(5), dependency manager704may issue an error exception notification indicating that Module307(1) may fail because Module307(1) depends on Module (5).

The dependency database706is initially coded by a developer of the Modules307. The developer (not shown) enters the dependencies and their correct orders (e.g., Module307(1) depends on Modules307(2),307(3),307(4), and307(5)). It is also possible that programmer708(e.g., builder of Web application302) could have permission to enter specific dependencies in the capacity of a developer and/or the developer and programmer708could be the same entity.

FIG. 8is a flow chart illustrating an exemplary method800for preventing programmable misuse of modules such as the grouping shown inFIG. 7. Method800includes blocks802–810. The order in which the method is described is not intended to be construed as a limitation. Additionally, portions of the operations may be optional, performed intermittently, or performed simultaneously. Furthermore, the method800can be implemented in any suitable hardware, software, firmware, or combination thereof.

At block802, a dependency database706is maintained containing information describing dependencies associated with modules used by an application. For example, programming tool700through its dependency manager704maintains the database706. Typically, the database is initially configured by a developer of one or modules, but it is possible that other entities may have the ability and/or permission to configure the database in certain circumstances.

At block804, information is received from a programmer708(e.g., such as a Web site developer) describing how the programmer desires to use certain modules in an application. For example, the programmer708, through the programming tool700may use the configuration file to configure an object.

At block806, the information entered by the programmer is compared to the information maintained in the database describing the dependencies. For example, the dependency manager704checks whether the information entered by the programmer708“matches” the dependencies (dependency information707) associated with the modules maintained in the database706. “Matches” as used herein does not necessarily mean that information entered by the programmer has to be exactly the same as the dependency information707, so long as the information entered and the dependency information707is consistent with each other.

At decisional block808a decision is made whether the information was entered matches the database or not. If the information entered matches, then according to the YES branch of decisional block808method800proceeds to check whether any additional information entered by the programmer708is correct. If the information entered does not match the dependencies (dependency information707) maintained in the database, then according to NO branch of block808method800proceeds to block810.

According to block810, an error exception notification is displayed to the programmer708, if the information entered by the programmer is incorrect (i.e., it does not match the dependency requirements maintained in the database706). The error notification may detail what information entered by the programmer failed to match the dependency requirements.

Exemplary Computing System and Environment

FIG. 9illustrates an example of a computing environment900within which the applications130including the runtime services, platforms, framework, systems, modules and methods described herein can be either fully or partially implemented. Exemplary computing environment900is only one example of a computing system and is not intended to suggest any limitation as to the scope of use or functionality of the network architectures. Neither should the computing environment900be interpreted as having any dependency or requirement relating to any one or combination of components illustrated in the exemplary computing environment900.

The computer and network architectures can be implemented with numerous other general purpose or special purpose computing system environments or configurations. Examples of well known computing systems, environments, and/or configurations that may be suitable for use include, but are not limited to, personal computers, server computers, thin clients, thick clients, hand-held or laptop devices, multiprocessor systems, microprocessor-based systems, set top boxes, programmable consumer electronics, network PCs, minicomputers, mainframe computers, gaming consoles, distributed computing environments that include any of the above systems or devices, and the like.

The runtime services, systems, platform, framework, modules, and methods described herein may be described in the general context of computer-executable instructions, such as program modules, being executed by a computer. Generally, program modules include routines, programs, objects, components, data structures, etc. that perform particular tasks or implement particular abstract data types. The applications130(including the runtime services, systems, platform, framework, modules, and methods described herein) may also be practiced in distributed computing environments where tasks are performed by remote processing devices that are linked through a communications network. In a distributed computing environment, program modules may be located in both local and remote computer storage media including memory storage devices.

The computing environment900includes a general-purpose computing system in the form of a computer902. The components of computer902can include, but are not limited to, one or more processors or processing units904, a system memory906, and a system bus908that couples various system components including the processor904to the system memory906.

Computer system902typically includes a variety of computer readable media. Such media can be any available media that is accessible by computer902and includes both volatile and non-volatile media, removable and non-removable media. The system memory906includes computer readable media in the form of volatile memory, such as random access memory (RAM)910, and/or non-volatile memory, such as read only memory (ROM)912. A basic input/output system (BIOS)914, containing the basic routines that help to transfer information between elements within computer902, such as during start-up, is stored in ROM912. RAM910typically contains data and/or program modules that are immediately accessible to and/or presently operated on by the processing unit904.

Computer902can also include other removable/non-removable, volatile/non-volatile computer storage media. By way of example,FIG. 9illustrates a hard disk drive916for reading from and writing to a non-removable, non-volatile magnetic media (not shown), a magnetic disk drive918for reading from and writing to a removable, non-volatile magnetic disk920(e.g., a “floppy disk”), and an optical disk drive922for reading from and/or writing to a removable, non-volatile optical disk924such as a CD-ROM, DVD-ROM, or other optical media. The hard disk drive416, magnetic disk drive918, and optical disk drive922are each connected to the system bus908by one or more data media interfaces926. Alternatively, the hard disk drive916, magnetic disk drive918, and optical disk drive922can be connected to the system bus908by a SCSI interface (not shown).

Any number of program modules can be stored on the hard disk916, magnetic disk920, optical disk924, ROM912, and/or RAM910, including by way of example, an operating system926, one or more application programs928, other program modules930, and program data932. Each of such operating system926, one or more application programs928, other program modules930, and program data932(or some combination thereof) may include an embodiment of the applications130(including the runtime services, platforms, framework, systems, modules and methods described herein).

A user can enter commands and information into computer system902via input devices such as a keyboard934and a pointing device936(e.g., a “mouse”). Other input devices938(not shown specifically) may include a microphone, joystick, game pad, satellite dish, serial port, scanner, and/or the like. These and other input devices are connected to the processing unit904via input/output interfaces940that are coupled to the system bus908, but may be connected by other interface and bus structures, such as a parallel port, game port, or a universal serial bus (USB).

A monitor942or other type of display device can also be connected to the system bus908via an interface, such as a video adapter944. In addition to the monitor942, other output peripheral devices can include components such as speakers (not shown) and a printer946which can be connected to computer902via the input/output interfaces940.

Computer902can operate in a networked environment using logical connections to one or more remote computers, such as a remote computing device948. By way of example, the remote computing device948can be a personal computer, portable computer, a server, a router, a network computer, a peer device or other common network node, and the like. The remote computing device948is illustrated as a portable computer that can include many or all of the elements and features described herein relative to computer system902.

Logical connections between computer902and the remote computer948are depicted as a local area network (LAN)950and a general wide area network (WAN)952. Such networking environments are commonplace in offices, enterprise-wide computer networks, intranets, and the Internet. When implemented in a LAN networking environment, the computer902is connected to a local network950via a network interface or adapter954. When implemented in a WAN networking environment, the computer902typically includes a modem956or other means for establishing communications over the wide network952. The modem956, which can be internal or external to computer902, can be connected to the system bus908via the input/output interfaces940or other appropriate mechanisms. It is to be appreciated that the illustrated network connections are exemplary and that other means of establishing communication link(s) between the computers902and948can be employed.

In a networked environment, such as that illustrated with computing environment900, program modules depicted relative to the computer902, or portions thereof, may be stored in a remote memory storage device. By way of example, remote application programs958reside on a memory device of remote computer948. For purposes of illustration, application programs and other executable program components, such as the operating system, are illustrated herein as discrete blocks, although it is recognized that such programs and components reside at various times in different storage components of the computer system902, and are executed by the data processor(s) of the computer.

CONCLUSION