Author: José Antonio González Seco full course available in DOC and PDF formats on the author's web
. INTRODUCTION TO MICROSOFT.NET
Microsoft.NET Common Language Runtime (CLR)
Metadata Assemblies Base Class Library (BCL) Common Type System (CTS) Common Language Specification (CLS)
Microsoft.NET
Microsoft.NET is a set of new technologies that Microsoft has been working in recent years in order to get a platform simple and powerful way to distribute the software as services that can be provided remotely and can communicate with each other and combine completely independent of platform, programming language and model of components that have been developed. This is called
. NET platform
, as previously mentioned services are called Web services .
To create applications for the platform. NET, Web services and applications, both traditional (console applications, Windows applications, Windows NT services, etc..) Microsoft has released the so-called software development kit called
. NET Framework SDK, which includes the necessary tools for development and for distribution and implementation, and Visual Studio.NET
-
- consistent programming model:
-
simple programming model: - With the CLR away many complexities included in current operating systems (Windows registry, GUIDs, HRESULTS, IUnknown, etc..) The CLR is not that abstracts the programmer from these concepts, but are concepts that do not exist. NET platform
- Elimination of the "hell of the DLL" on the platform. NET removes the problem known as "hell of the DLL" given current operating systems of Windows family, problem is that by replacing older versions of DLLs can be shared by new versions that applications that were designed to be run using the old stop working if the news is not 100% compatible with above. On the platform. NET newer versions of the DLLs can coexist with the old, so that applications designed to run using the old may continue using them after installing the new. This obviously greatly simplifies the installation and uninstallation of software. Implementation
- platform: The CLR acts as a virtual machine, taking care to run applications designed for. NET platform. That is, any platform for which there is a version of the CLR can run any. NET application. Microsoft has developed versions of the CLR for most versions of Windows: Windows 95, Windows 98, Windows ME, Windows NT 4.0, Windows 2000, Windows XP and Windows CE (which can be used on CPUs other than x86 family ) On the other hand Microsoft has signed an agreement with Corel to port the CLR to Linux and there are others which are independently developed freeware versions of the CLR for Linux. Also, because the architecture of the CLR is completely open, it is possible that in future design versions of the same for other operating systems.
- Integration Language:
from any language for which there is a compiler that generates code for the platform. NET generated code can be used for the same using any other language as if the first code written using it were . Microsoft has developed a C # compiler generates such code, as well as versions of its compilers for Visual Basic (Visual Basic.NET) and C + + (C + + with extensions managed) that also generate and a version of the JScript interpreter (JScript . NET) that can interpret it. Language integration is such that it is possible to write a C # class that inherits from one written in Visual Basic.NET that, in turn, inherit from one written in C + + with managed extensions. -
Memory management: - The CLR includes a garbage collector which prevents the developer to consider when to destroy the objects that no longer be useful. This collection is an application that is activated when you create a new object is detected that there is free memory to do so, if the collector runs in dynamic memory associated with the application, which detects objects in it that can not be accessed by the application code, and removed to clear the memory of "objects rubbish "and allow the creation of new ones. Thanks to this collection avoids common programming errors such as attempts to erase and deleted objects, memory exhaustion by forgetting or elimination of useless objects to access request object members and destroyed.
- Type safety: The CLR facilitates the detection of programming errors difficult to track by checking that all type conversion is performed during the execution of an application. NET is made so that the source and destination types are compatible .
All services and facilities offered by the CLR is accessed in the same way: through a model of object-oriented programming. This is a major difference on how to access services offered by some current operating systems (for example, family Windows), in which some services are accessed through calls to global functions defined in and other DLLs by objects (COM objects in the case of the Windows family) -
Process Isolation: The CLR ensures that from code belonging to a particular process can not access code or data belonging to another, avoiding programming errors very frequent and prevents some processes to attack others. This is achieved thanks to the previously discussed type safety, it prevents an object can be converted at a rate larger than his own, and that when treated as an object of larger size could be accessed in memory space outside it could belong to another process. Also be achieved by having not allowed to access arbitrary memory locations. Exception handling: The CLR any errors that may occur during the execution of an application spread the same way: using exceptions. This is very different from what was being done on Windows systems to the emergence of the platform. NET, in which certain errors are transmitted using error codes in Win32 format, others by HRESULTS and other means of derogations.
The CLR allows code exceptions thrown. NET written in a certain language can be captured using code written in another language, including debugging mechanisms that can jump from code written for. NET in a particular language code written in any other. For example, you can traverse the call stack of an exception but it includes other methods defined in modules using other languages. Support multithreading : The CLR is able to work with applications that span multiple threads of execution that may evolve separately in parallel or interleaved, depending on the number of processors on the machine on which to run. Applications can launch new threads, destroy, suspend them for a while or until they get a notice, send notifications, syncing, etc.
transparent Distribution: The CLR provides the infrastructure to create remote objects and access them in a completely transparent to its actual location, as if they were in the machine that uses them.
Advanced Security:
The CLR provides mechanisms to restrict the execution of certain codes or permits assigned to them according to their procedendecia or the user that run. That is, can not afford the same level of confidence from the Internet code that code installed locally or from a local network may not be the same permissions to code from a particular manufacturer that other code, and can not given the same permissions to the same codes as the user who is running or as the role it plays. This allows a system administrator code that is running can not jeopardize the integrity of files, the Windows registry, etc.
interoperability with old code:
The CLR includes the necessary mechanisms to access from code written for the platform. NET code written before the appearance of it and therefore not ready to be executed within it. These mechanisms allow both access to COM objects such as access to pre-existing DLLs loose functions (such as Win32 API)
As can be deduced from the mentioned characteristics, the CLR it does is manage the implementation of applications designed for . NET platform. For this reason, the code of these applications is often called managed
code and the unwritten code to be executed directly on the platform. NET is often referred unmanaged code.
Microsoft Intermediate Language (MSIL)
- None of the compilers that generate code for the platform. NET produces machine code for x86 CPUs or for any other specific CPU, but also generate code written in intermediate language called Microsoft Intermediate Language (MSIL
) The CLR gives applications the feeling that they are running on a virtual machine, and just MSIL is the machine code of the virtual machine. That is, MSIL is the only code that is able to interpret the CLR, and therefore when we say that a compiler generates code for the platform. NET what is being said is that it generates MSIL. - MSIL has been created by Microsoft after consultation with numerous experts in the writing of compilers and languages \u200b\u200bof both the academic and business world. It is a language of a level of abstraction much higher than most CPU machine codes exist, and includes instructions for working directly with objects (create, destroy, initialize, call virtual methods, etc.), tables, and exceptions (throw, catch them and treat them)
already said that the C # compiler compiles directly to the source code to MSIL, Microsoft has developed new versions of their languages Visual Basic (Visual Basic.NET) and C + + (C + + with managed extensions), whose compilers generate MSIL, and has developed a JScript interpreter (JScript.NET) that generates MSIL code. Well, there are also numerous third parties who have announced to be made for the platform versions. NET languages \u200b\u200bsuch as APL, CAML, Cobol, Eiffel, Fortran, Haskell, Java (J #), Mercury, ML, Mondrian, Oberon, Oz, Pascal, Perl, Python, RPG, Scheme and Smalltalk.
- The main advantage of MSIL is that it facilitates the implementation platform and language integration to be independent of the CPU and provide a common format for the machine code generated by all compilers that generate code for. NET. However, since the CPUs can not run directly MSIL, before running to be converted to native code of the CPU on which they take place. This is accomplished by a component known as the CLR JIT compiler (Just-In-Time) or jitter that is dynamically converting MSIL to native code to execute as needed. This jitter is divided into three versions
- normal jitter: which is often used by default, and only compiles the MSIL code to native code as it is still necessary because it saves time and memory to avoid unnecessarily having to compile code never run. To achieve this, the CLR class loader initially replaces method calls of new classes to be charged for calls to functions (stubs) to be responsible for compiling the actual method code. Once compiled, the call to the stub is replaced by a direct call to the compiled code, so that subsequent calls to it do not need compilation.
- economic jitter: works similarly to normal jitter just did not perform any optimization of code to compile, but that translates each instruction MSIL by equivalent machine code on the run. It is specially designed for use in embedded devices that have low power CPU and little memory, for even more inefficient code generated is less time and memory required to compile. Moreover, to save memory this jitter can be downloaded and compiled code that takes some time without running back and replaced by the appropriate stub. For these reasons, this is the jitter used by default in Windows CE operating system is usually included in the above embedded devices.
Another use of economic jitter is that it facilitates the adaptation of the platform. NET to new systems because it is much easier to implement than normal. In this way, because it is possible to quickly develop a version of the CLR-managed applications that can run even from a less efficient, and once developed it is possible to focus on developing the normal jitter to optimize their execution.
- prejitter: is distributed as a command line application called
ngen.exe - by which to compile complete any executable or library (any general assembly, although this concept is discussed below) that contains managed code and convert it to native code, so that subsequent executions of the same will be using this version already compiled and does not waste time making dynamic compilation. The jitter performance for the execution of a managed application can give the feeling of making it run slower because you have to invest time in dynamic compilation. This is true, but be aware that it is a much more efficient than that used in other platforms such as Java, as in. NET each code is not interpreted each time it runs but only compiled the first time you call the method to which it belongs. Moreover, the fact that the compilation is done dynamically allows the jitter has access to much more information about the machine that will run the application would have any traditional compilers, which can optimize the code it generated (for example, using special instructions from the Pentium III machine if they are supported, using extra registers, including inline code
, etc.) Furthermore, as the garbage collector. NET keeps dynamic memory compacted memory reserves will be faster, especially in applications that do not cover the memory and therefore do not require a garbage collection. For these reasons, engineers at Microsoft think that future versions of their jitters may even get managed code to run faster than unmanaged.
-
- Metadata
on the platform. NET are two types of
- compiled code modules: executable (extension .
- ( extension. dll generally) are files containing both data type definitions, and the difference between them is that only the former have a special method that serves as entry point from which to execute the code contained on a call from the command line operating system. Both types of modules are often referred
portable executable (PE), because your code can run on any operating systems Windows family for which there is some version of CLR. - The contents of a module is not only MSIL, it also has two other important areas: the CLR header and metadata: The header
CLR is a small block of information that indicates that it is managed and indicates a module is the CLR version you need, what is your digital signature, what is your point of entry (if an executable, etc.). - The
Table
Description
ModuleDef
- Define the characteristics of the module. It consists of a single element that stores a version identifier module (GUID created by the compiler) and the file name given to the module to compile (and this name is always available, even rename the file)
-
- TypeDef
- MethodDef
ParamDef
Define the characteristics of the parameters defined in the module. Of each parameter is saved your name and modifiers. FieldDef
Define the characteristics of the fields defined in the module. Each stores information about what their name, type and modifiers.
-
PropertyDef
-
Define the characteristics of the properties defined in the module. Each indicating its name, type, modifiers, and references to items in the table MethodDef methods for set / get.
| EventDef | Sets the characteristics of the events defined in the module. Of each is its name, type, modifiers. and references to items in the table for their methods MethodDef add / remove.
| AssemblyRef
| also identifies the external assemblies that are referenced in the module. Each one tells you what the filename (without extension), version, language and mark public key. |
| ModuleRef
| also identifies the other modules of the same assembly that references to the module. Each one tells you what the file name. |
| TypeRef
| also identifies the external types which are referenced in the module. From each, it will list your name and depending on where they are defined, a reference to the proper position on the chart or table AssemblyRef ModuleRef. |
| MemberRef
| indicate which members externally defined reference to which the module. These members may be fields, methods, properties or events, and each is stored information its name and symbol, and a reference to the position of TypeRef table that stores information about the type of which is a member. |
|
| Table 1 : Main metadata tables | Note that the significance of the metadata is similar to other pre technologies. NET platform such as IDL files. However, the metadata has two important advantages over these: contains more information and always stored embedded in the module they describe, making it impossible to separate the two. Moreover, as discussed below, may well refer to the metadata of any module through classes System.Reflection namespace of the BCL as add additional information by |
|
| Assemblies A |
| All assembly contains a manifest , which are metadata about the features of the assembly. This manifest can be stored in any of the modules forming the assembly or one specifically created for this purpose, the latter being necessary when only contains resources (satellite assembly ) | The main tables in the manifest are as follows:
|
| Table |
|
| Description
|
| AssemblyDef
| Sets the characteristics of the assembly. It consists of a single item that stores the name of the assembly without extension, version, language, public key and algorithm used to find dispersion dispersion values \u200b\u200bFileDef table. |
| FileDef
| Sets which are the files that make up the assembly. Of each is given its name and hash value. Note that only the module containing the manifest will know what files make up the assembly, but the rest of the file will not know whether or not they belong to an assembly (not contain metadata that tells them if they belong to an assembly) |
| ManifestResourceDef
Define the characteristics of the resources included in the module. Each showing his name, access modifiers. If an embedded resource indicated in the PE where you start that contains it, and if a separate file indicates which element FileDef table for that file. ExportedTypesDef
also identifies the types defined in the assembly and accessible from outside. To save space only capture those who do not belong to the module which includes the manifest, and each stated his name, position in the table FileDef of the file where it is implemented and TypeDef table position corresponding to its definition.
AssemblyProccesorDef
Indicates which processor You can run the assembly, which may be useful to know if the assembly contains modules with native code (it could be done using C + + with extensions managed) are usually empty, indicating that can run on any processor, but if it is full, each item indicate a supported processor type identifier in the format of the file processor Winnt.h included with Visual Studio.NET (for example, 586 = Pentium, 2200 = IA64 architecture, etc.).
AssemblyOSDef
Indicates under what operating systems can run the assembly, which can be useful if it contains modules with types or methods available only in certain systems. Is usually empty, indicating that can run on any processor, but if it were full, indicating the identifier of each of the supported systems following the format of Visual Studio.NET Winnt.h (eg, 0 = Windows family 9X, 1 = Windows NT family, etc..) and the version number of the same from which it accepts.
|
| Table 2 : Main boards a manifesto To ensure that no information has been altered in any assembly is uses the RSA public key cryptosystem. What is done is to calculate the dispersion code SHA-1 module containing the manifest and include both the value encrypted with RSA ( |
| also to ensure that the contents of other files that form an assembly has not been altered so do is calculate the dispersion code to encrypt them before the assembly and save it for each file element in the table FileDef the manifest. The encryption algorithm used by default is SHA-1, although in this case also gives the possibility of using MD5. In both cases, each time you access the file to access a resource type or recalculate the hash value and verify that it matches the one stored in FileDef. Since public keys are values \u200b\u200bthat occupy many bytes (2048 bits), which is done to prevent the metadata is too large is not to include references to external assemblies AssemblyRef table keys such public assemblies, but only the 64 last bits obtained by applying a dispersion algorithm to those keys. A cut this value is called public key mark. | There are two types of assemblies: private assemblies and shared assemblies |
| global assembly cache (GAC) and can use anyone who has been compiled referenced. The figures have shared with RSA and identifies what is in the GAC is his name (Without extension) plus your public key, which allows the GAC can be installed multiple assemblies with the same name and different public keys. That is, it's as if the public key part of the name of the assembly, why the assembly and called encrypted strong name assemblies. This policy allows you to resolve any disputes that attempt to install on one computer shared multiple assemblies with the same name but from different companies, because they have different public keys. | also to avoid problems in the GAC can keep multiple versions of the same assembly. Thus, if an application was compiled using a certain version of a particular shared assembly, when running only be able to use that version of the assembly and not from any other art that had been installed in the GAC. This will solve the problem of DLL Hell mentioned at the beginning of the topic. |
| .
| Base Class Library (BCL) |
| The Base Class Library (BCL) is a library included in the . NET Framework comprises hundreds of types of data that allows access the services offered by the CLR and the most frequently used features when writing programs. In addition, from these classes prefabricated programmer can create new classes by inheritance to extend their functionality and integrate seamlessly with the rest of the BCL classes. For example, implementing certain interfaces can create new types of collections that will be treated exactly like any of the collections included in the BCL. This library is written in MSIL, so it can be used from any language whose compiler generates MSIL. Through classes provided it is possible to develop any type of application, from traditional windows applications, console or Windows NT service to the novel Web services and ASP.NET pages. Such is the wealth of services offered is even possible to create languages \u200b\u200bthat lack their own class library and is only based on the BCL-like C #. | Given the breadth of the BCL, it was necessary to organize lessons in it included in namespaces that group classes with similar functionality. For example, the namespaces used are: |
|
| Namespace |
| Utility data types containing |
| System
very frequently used types, such as basic types, tablas, excepciones, fechas, números aleatorios, recolector de basura, entrada/salida en consola, etc. System.Collections
Colecciones de datos de uso común como pilas, colas, listas, diccionarios, etc.
System.Data Manipulación de bases de datos. Forman la denominada arquitectura ADO.NET
.
System.IO
System.Net
Performing network communications.
System.Reflection
| System.Runtime.Remoting | access remote objects. |
| access security policy on which the CLR. |
|
| Thread handling. |
|
| Creating user interfaces based on windows for web applications. |
| System.Windows.Forms
| Creating user interfaces based on windows for standard applications. |
| System.XML
| Data Access in XML format. |
|
| : Namespaces the most frequently used BCL |
|
| Common Type System (CTS) The | Common Type System (CTS) and Common Type System is a set of rules to be followed by the definitions of data types that the CLR will accept them. That is, although each language has managed its own syntax for defining data types in the MSIL resulting from the compilation of source code must comply with the rules of the CTS. Some examples of these rules are:
|
| can not have multiple inheritance, and all kinds of data must inherit directly or indirectly from System.Object | . |
|
|
| Modifier
|
| Code from which the member is accessible
|
| public Any code |
|
| private | same code of data |
family code same datatype or his sons.
assembly same assembly code
- family and assembly code
- same or his sons located in the same assembly
- family or assembly code
| Table 4 | : member access modifiers supported by the CTS |
| Common Language Specification (CLS) | The Common Language Specification (CLS) and Common Language Specification is a set of rules to be followed by the type definitions are made using a particular language managed if they are to be accessible from any other managed language. Obviously, you only need to follow these rules in the definitions of types and members that are accessible externally and not those of the private. Also, if it does not matter language interoperability is not necessary to follow them. Listed below are some significant rule CLS: |
| basic data types supported are bool, char | , |
| byte, short , int | , |
| , float, double | , |
| and as Note that not all languages \u200b\u200bhave reason support the basic types unsigned integers or decimal type | as does C #. |
| tables must have one or more dimensions, and the number of dimensions of each table has to be fixed. They must also indexed starting counting from 0. abstract types can be defined and sealed types. Sealed types can not be abstract members. | Exceptions must derive from System.Exception |
, enumerations System.Enum , and value types that are not enumerations of System.ValueType
.
access methods to properties that translate the definitions get / set of these are named the way get_X and
set_X respectively, where X is the name of the property, the indexer access must be translated into methods
get_Item
and
- set_Item and in the case of events, definitions, add / remove methods to be translated into add_X and remove_X . The only attribute definitions enumeration or data used for the following types: System.Type, string , char , bool , byte, short , int , long
- ,
- float, double
- and
- object. In the same area can not define multiple identifiers whose names differ only in the capitalization used. This will avoid problems when accessed using non-sensitive languages to uppercase. Enumerations can not implement interfaces, and all fields must be static and the same type. The type of the fields in a list can only be one of four basic types: byte, short
- , int or long . (C) 2001 Jos? Antonio Gonz? Lez Seco
0 comments:
Post a Comment