The Microsoft .NET Framework is a software component that can be added to, or is included as part of, the Microsoft Windows operating system.
It provides a large body of pre-coded solutions to common program requirements, and manages the execution of programs written specifically for the framework. The .NET Framework is a key Microsoft offering, and is intended to be used by most new applications created for the Windows platform.
Programs written for the .NET Framework execute in a software environment that manages the program's runtime requirements. This runtime environment, which is also a part of the .NET Framework, is known as the Common Language Runtime (CLR), the CLR provides the appearance of an application virtual machine, so that programmers need not consider the capabilities of the specific CPU that will execute the program.
The CLR also provides other important services such as security mechanisms, memory management, and exception handling. The class library and the CLR together compose the .NET Framework. The framework is intended to make it easier to develop computer applications and to reduce the vulnerability of applications and computers to security threats.
It is included with Windows Server 2003 and Windows Vista and later versions of Windows, and can be installed on most older versions of Windows.
Product Component | OS Type | Versioning | Pattern Depth |
---|---|---|---|
Microsoft .Net Runtime | Windows | Package | Deep (due to nature/architecture of product) |
Due to the nature of the product the only supported platform is Windows.
Trigger Node | Attribute | Condition | Argument |
---|---|---|---|
Host | os_class | equals | Windows |
Due to the embeded nature of the .Net runtime we are unable to trigger on a single process, as such we trigger on a Host node where the Operating System is Windows based. From there we can perform additional checks to see if the host has a .Net Runtime Environment installed upon it.
There are no supporting/related processes for which Simple Identifiers have been defined.
Currently pattern supports, package and registry versioning.
As we already have the package we need to acquire the version information from, identified during the additional steps of the Software Identification process, we do not have to query the package management system again.
Pattern checks the registry in order to determine .Net installations present on the host. As uninstalled .Net installations leave their mark within the Registry, confirmation is sort by comparing such versions with packages present on the host.
Thanks to the documentation available and the functionality available with the pattern language we are able to map a rather obscure internal version number to the specific version, service pack and build versions.
To provide this functionality we create a table with mappings from the internal version number to the product, service pack and build version number, we then use the internal version as the "Full Version" and map this to the product (marketing) version, service pack and revision
If the internal version does not map to a specific set of product versions then we simply take the first two sets of digits, separated by periods, and assign it as the product version.
As mentioned in the description the Microsoft .Net Runtime is embedded deep into the core Windows Operating System as such there is no true structure, it is simply a set of libraries and OS calls used to assist in the development and deployment of applications.
As such it is simply deemed to be "deployed" on a host system and if the installed version matches or exceeds the required version specified by the application then it can be deployed and executed.
Due to the embeded nature of the .Net runtime we are unable to trigger on a single process, as such we trigger on a Host node where the Operating System is Windows based. From there we can perform additional checks to see if the host has a .Net Runtime Environment installed upon it.
To check if Microsoft .Net is installed we query the Windows installation manager with a regex that identifies all installations of Microsoft .Net.
Package Regex:
This regex will almost always return more than one package, due in part to the numbering scheme Microsoft have used for the release of bug fixes and Service Packs and the fact that you can have more than one major version of .Net installed on the same machine.
Once we have our list of installed Microsoft .Net packages we then iterate through it to identify which versions of the Runtime are installed, see section Microsoft .NET#Product Mappings for more information.
The Pattern creates a single Runtime Environment node for each identified installation of .Net Runtime on a single host.
We define each separate installation by its full version and Atrium Discovery creates a separate Runtime Environment node for each version .Net installed on the host.
A version change (e.g. update via a patch) will cause a new Runtime Environment node to be created to represent this version while the Runtime Environment node for the old version is removed by the system.
There is no relationship creation involved in the software model.
No SME feedback has been required during the development of this product pattern
This pattern has been tested against a variety of Windows platforms with a number of different .Net environments installed.
framework Wikipedia was used for the product description and the initial list of known versions.
The official .Net website was use to expand on this information.
There are no open issues with the pattern.
Created by: Rebecca Shalfield 11 July 2008
Updated by: Nikola Vukovljak 11 Jun 2013