Introduction to .Net Framework and Components.....Article 3

.NET Framework and Components


“.NET” COMPONENTS

Base Class Library:
Included with the .NET Framework is a set of .NET Framework Class Library (FCL) assemblies that contains several thousand type definitions, where each type exposes some functionality. All in all, the CLR and the FCL allow developers to build the following kinds of applications:
1. XML Web services Methods that can be accessed over the Internet very easily. XML Web services are, of course, the main thrust of Microsoft’s .NET initiative.
2. Web Forms HTML-based applications (Web sites). Typically, Web Forms applications will make database queries and Web service calls, combine and filter the returned information, and then present that information in a browser using a rich HTML-based user interface. Web Forms provides a Visual Basic 6 and Visual InterDev style development environment for Web applications written in any CLR language.
3. Windows Forms Rich Windows GUI applications. Instead of using a Web Forms page to create our application’s UI, we can use the more powerful, higher performance functionality offered by the Windows desktop. Windows Forms applications can take advantage of controls, menus, and mouse and keyboard events, and they can talk directly to the underlying operating system. Like Web Forms applications, Windows Forms applications also make database queries and call XML Web services. Windows Forms provides a Visual Basic 6Ð like development environment for GUI applications written in any CLR language.
4. Windows console applications For applications with very simple UI demands, a console application provides a quick and easy way to build an application. Compilers, utilities, and tools are typically implemented as console applications.
5. Windows services It is possible to build service applications controllable via the Windows Service Control Manager (SCM) using the .NET Framework.
6. Component library The.NET Framework allows you to build stand-alone components (types) that can be easily incorporated into any of the previously mentioned application types. Because the FCL contains literally thousands of types, a set of related types is presented to the developer within a single namespace. For example, the System namespace contains the Object base type, from which all other types ultimately derive. In addition, the System namespace contains types for integers, characters, strings, exception handling, and console I/O as well as a bunch of utility types that convert safely between data types, format data types, generate random numbers, and perform various math functions. All applications will use types from the System namespace. To access any of the platform’s features, we need to know which namespace contains the types that expose the facilities we’re after. If we want to customize any type’s behavior, we can simply derive our own type from the desired FCL type. The object-oriented nature of the platform is how the .NET Framework presents a consistent programming paradigm to software developers. Also, developers can easily create their own namespaces containing their own types. These namespaces and types merge seamlessly into the programming paradigm. Compared to Win32 programming paradigms, this new approach greatly simplifies software development.
Most of the namespaces in the FCL present types that can be used for any kind of application. Table3 lists some of the more general namespaces and briefly describes what the types in that namespace are used for.

Namespace                  Description of Contents

System                     All the basic types used by every Application
System.Collections         Types for managing collections of objects; includes the
                           popular collection types, such as stacks, queues, hash
                           tables, and so on
System.Diagnostics         Types to help instrument and debug Applications
System.Drawing             Types for manipulating 2-D graphics; typically used for
                           Windows Forms applications and for creating images that
                           are to appear in a Web Forms page
System.EnterpriseServices  Types for managing transactions, queued components,
                           object pooling, JIT activation, security, and other
                           features to make the use of managed code more efficient
                           on the server
System.Globalization       Types for National Language Support (NLS), such as string
                           compares, formatting, and calendars
System.IO                  Types for doing stream I/O, walking directories and files
System.Management          Types used for managing other computers in the enterprise
                           via Windows Management Instrumentation (WMI)
System.Net                 Types that allow for network Communications
System.Reflection          Types that allow the inspection of metadata and late
                           binding to types and their members
System.Resources           Types for manipulating external data Resources
System.Runtime             Types that allow managed code to access unmanaged OS
.InteropServices           platform facilities such as COM components and functions
                           in Win32 DLLs
System.Runtime.Remoting    Types that allow for types to be accessed Remotely
System.Runtime             Types that allow for instances of objects to
.Serialization             be persisted and regenerated from a stream
System.Security            Types used for protecting data and Resources
System.Text                Types to work with text in different encodings, such as
                           ASCII or Unicode
System.Threading           Types used for asynchronous operations and synchronizing
                           access to resources
System.Xml                 Types used for processing XML schemas and data

Table3: General Namespaces

In addition to the more general namespaces, the FCL also offers namespaces whose types are used for building specific application types. Table 4 lists some of the application-specific namespaces in the FCL.

Namespace                  Application Type
System.Web.Services        Types used to build XML Web services
System.Web.UI              Types used to build Web Forms
System.Windows.Forms       Types used to build Windows GUI applications controllable
                           by the SCM
System.ServiceProcess      Types used to build a Windows service

Table4: Application Specific Namespaces

The Common Type System:
Types expose functionality to our applications and components. Types are the mechanism by which code written in one programming language can talk to code written in a different programming language. Because types are at the root of the CLR, Microsoft created a formal specification—the Common Type System (CTS)—that describes how types are defined and how they behave. The CTS specification states that a type can contain zero or more members.
1. Field: A data variable that is part of the object’s state. Fields are identified by their name and type.
2. Method: A function that performs an operation on the object, often changing the object’s state. Methods have a name, a signature, and modifiers. The signature specifies the calling convention, the number of parameters (and their sequence), the types of the parameters, and the type of value returned by the method.
3. Property: To the caller, this member looks like a field. But to the type implementer, it looks like a method (or two). Properties allow an implementer to validate input parameters and object state before accessing the value and/or calculate a value only when necessary. They also allow a user of the type to have simplified syntax. Finally, properties allow you to create read-only or write-only “fields.”
4. Event: An event allows a notification mechanism between an object and other interested objects. For example, a button could offer an event that notifies other objects when the button is clicked.
The CTS also specifies the rules for type visibility and for access to the members of a type.For example, marking a type as public (called public) exports the type, making it visible and accessible to any assembly. On the other hand, marking a type as assembly (called internal in C#) makes the type visible and accessible to code within the same assembly only. Thus, the CTS establishes the rules by which assemblies form a boundary of visibility for a type, and the CLR enforces the visibility rules. Regardless of whether a type is visible to a caller, the type gets to control whether the caller has access to its members.

The following list shows the valid options for controlling access to a method or a field:
1. Private: The method is callable only by other methods in the same class type.
2. Family: The method is callable by derived types, regardless of whether they are within the same assembly. Note that many languages (such as C++ and C#) refer to family as protected.
3. Family and assembly: The method is callable by derived types, but only if the derived type is defined in the same assembly. Many languages (such as C# and Visual Basic) don’t offer this access control. Of course, IL Assembly language makes it available.
4. Assembly: The method is callable by any code in the same assembly. Many languages refer to assembly as internal.
5. Family or assembly: The method is callable by derived types in any assembly. The method is also callable by any types in the same assembly. C# refers to family or assembly as protected internal.
6. Public: The method is callable by any code in any assembly. In addition, the CTS defines the rules governing type inheritance, virtual functions, object lifetime, and so on. These rules have been designed to accommodate the semantics expressible in modern-day programming languages. In fact, we won’t even need to learn the CTS rules , since the language you choose will expose its own language syntax and type rules in the same way we’re familiar with today and will map the language-specific syntax into the “language” of the CLR when it emits the managed module.

The Common Language Specification:
.net framework admirably supports language interoperability .Common language Specification means “many languages for one platform (In contrast to Java i.e. “one language for many platforms”). For now it may be true that Windows is a only operating system but for the programmers of the many languages that support .net, CLS is a maior breakthrough.
By writing “CLS-compliant” code we construct classes and components that can be used by any language and its respective IDEs and development tools, without the need for complex COM and activeX interfaces and registration details.
The CLS is really a subset of the common type system. All the rules specified by the Common ype System in the Runtime environment such as type safety, determine how the CLS governs compliance at the code construction and compilation levels. The CTS protects the integrity of code by ensuring type safety; code constructs that risk type safety are excluded from the CLS. As long as we produce CLS compliant code it will be verified by CTS.
Following table5 provides an abridged list of software development features that must meet CLS compliance rules and indicates whether the feature applies to both developers and compilers or only to compilers.

Feature           Application          CLS compliance

General           All                  Visibility and exposure; types that are
                                       exposed need to be compliant,but global
                                       static fields and methods do not
Naming            All                  Characters and casing. Keywords names must be
                                       unique and signatures muat ensire that return
                                       and parameter types are compliant.
Types             All                  Fundamental types such as integer, Boolean,
                                       double and so on.
Type members      All                  Overloading, uniqueness and conversion
                                       operations.
Methods           All                  Accessibility and calling conventions and
                                       parameter lists.
Properties        All                  Accesser  metadata, accessibility,
                                       modification, naming and parameters
Events            All                  Event methods and metadata,
                                       accessibility,modification, naming and
                                       parameters
Pointers          All                  Pointers are not compliant.
Reference types   All                  Construction and invocation.
(objects)
Class types       All                  Inheritance from atleast one compliant class
Arrays            All                  Elements, dimensions and bounds
Enumerations      All                  Underlying types, the flags attributes and
                                       field members
Exceptions        All                  Must derive from the base system.exception
                                       class
Custom attributes All                  Value encoding
Metadata          Compilers            Compliance marking
Interfaces        All                  Signatures and modification

Table5: Abridged Version of the CLS

The CLS includes the language constructs that are needed by developers of all .net languages. That may seem impossible, but the specification is not too big or complex for a .net language to support. After all, many of the languages at the source code level are far different for instance Smalltalk, Pascal, C# etc. Following are some of the benefits of CLS:
1. Classes produced in one language can be inherited by ones used in other language.
2. Objects instantiated from the classes of a sender return in one language can be passed to the methods of receiver objects whose classes were created in other languages. The receiving objects accept our arguments and process them as if they were written in the same language as the receiver.
3. Exception handling, tracing and profiling are language agnostic; we can debug across languages and even across processes. Exceptions can be raised in an object from one language and understand by an object created in another language.

The Common Language Runtime:
As its name suggests, the common language runtime (CLR) is a runtime that is usable by different and varied programming languages. The features of the CLR are available to any and all programming languages that target it—period. If the runtime uses exceptions to report errors, then all languages get errors reported via exceptions. If the runtime allows you to create a thread, then any language can create a thread. In fact, at runtime, the CLR has no idea which programming language the developer used for the source code. This means that any programming language that allows us to implement and develop our application i.e. we can develop our code in any programming language we desire as long as the compiler we use to compile your code targets the CLR.
Figure2 shows the process of compiling source code files. As the figure shows, you can create source code files using any programming language that supports the CLR. Then you use the corresponding compiler to check the syntax and analyze the source code. Regardless of which compiler you use, the result is a managed module. A managed module is a standard Windows portable executable (PE) file that requires the CLR to execute. In the future, other operating systems may use the PE file format as well.



Figure2: Compiling source code into managed modules


Table6 describes the parts of a managed module.

Part                 Description

PE header            The standard Windows PE file header, which is similar to the
                     Common Object File Format (COFF) header. This header indicates
                     the type of file: GUI, CUI, or DLL, and it also has a timestamp
                     indicating when the file was built. For modules that contain
                     only IL code, the bulk of the information in the PE header is
                     ignored. For modules that contain native CPU code, this header
                     contains information about the native CPU code.
CLR header           Contains the information (interpreted by the CLR and utilities)
                     that makes this a managed module. The header includes the
                     version of the CLR required, some flags, the MethodDef metadata
                     token of the managed module’s entry point method (Main method),
                     and the location/size of the module’s metadata, resources,
                     strong name, some flags, and other less interesting stuff.
Metadata             Every managed module contains metadata tables. There are two
                     main types of tables: tables that describe the types and
                     members defined in your source code and tables that describe
                     the types and members referenced by your source code.
Intermediate         Code that the compiler produced as it compiled the source code.
language (IL)        The CLR later compiles the IL into native CPU instructions.
Code

Table6: Parts of Managed Modules

Metadata:
Most compilers of the past produced code targeted to a specific CPU architecture, such as x86, IA64, Alpha, or PowerPC. All CLR-compliant compilers produce IL code instead. IL code is sometimes referred to as managed code because the CLR manages its lifetime and execution.
In addition to emitting IL, every compiler targeting the CLR is required to emit full metadata into every managed module. In brief, metadata is simply a set of data tables that describe what is defined in the module, such as types and their members. In addition, metadata also has tables indicating what the managed module references, such as imported types and their members. Thus, metadata is nothing but data about the data. Metadata is a superset of older technologies such as type libraries and interface definition language (IDL) files. The important thing to note is that CLR metadata is far more complete. And, unlike type libraries and IDL, metadata is always associated with the file that contains the IL code. In fact, the metadata is always embedded in the same EXE/DLL as the code, making it impossible to separate the two. Because the compiler produces the metadata and the code at the same time and binds them into the resulting managed module, the metadata and the IL code it describes are never out of sync with one another. Metadata has many uses. Here are some of them:
1. Metadata removes the need for header and library files when compiling since all the information about the referenced types/members is contained in the file that has the IL that implements the type/members. Compilers can read metadata directly from managed modules.
2. Visual Studio .NET uses metadata to help us write code. Its IntelliSense feature parses metadata to tell us what methods a type offers and what parameters that method expects.
3. The CLR’s code verification process uses metadata to ensure that your code performs only “safe” operations.
4. Metadata allows an object’s fields to be serialized into a memory block, remoted to another machine, and then deserialized, re-creating the object and its state on the remote machine.
5. Metadata allows the garbage collector to track the lifetime of objects. For any object, the garbage collector can determine the type of the object and, from the metadata, know which fields within that object refer to other objects. Thus, a programmer is relieved from the overhead of memory management and checking memory leakage.

Combining Managed Modules into Assemblies:
The CLR doesn’t actually work with modules; it works with assemblies. An assembly is an abstract concept that can be difficult to grasp initially. First, an assembly is a logical grouping of one or more managed modules or resource files. Second, an assembly is the smallest unit of reuse, security, and versioning. Depending on the choices we make with our compilers or tools, we can produce a single-file or a multifile assembly.
Figure3 should help explain what assemblies are about. In this figure, some managed modules and resource (or data) files are being processed by a tool. This tool produces a single PE file that represents the logical grouping of files. What happens is that this PE file contains a block of data called the manifest. The manifest is simply another set of metadata tables. These tables describe the files that make up the assembly, the publicly exported types implemented by the files in the assembly, and the resource or data files that are associated with the assembly.



Figure3: Combining managed modules into assemblies

By default, compilers actually do the work of turning the emitted managed module into an assembly; An assembly allows you to decouple the logical and physical notions of a reusable, deployable, versionable component. Assemblies allow you to break up the deployment of the files while still treating all the files as a single collection. An assembly’s modules also include information, including version numbers, about referenced assemblies. This information makes an assembly self-describing. In other words, the CLR knows everything about what an assembly needs in order to execute. No additional information is required in the registry or in Active Directory. Because no additional information is needed, deploying assemblies is much easier than deploying unmanaged components.

Executing Assembly’s Code:
As mentioned earlier, managed modules contain both metadata and intermediate language (IL). IL is a CPU-independent machine language created by Microsoft. IL is much higher level than most CPU machine languages. IL understands object types and has instructions that create and initialize objects, call virtual methods on objects, and manipulate array elements directly. It even has instructions that throw and catch exceptions for error handling. IL can be considered as an object-oriented machine language. Usually, developers will program in a high-level language, such as C# or Visual Basic. The compilers for these high-level languages produce IL. However, like any other machine language, IL can be written in assembly language, and Microsoft does provide an IL Assembler, ILAsm.exe. Microsoft also provides an IL Disassembler, ILDasm.exe.

IL and Protection of Intellectual Property:
It is often doubted that IL doesn’t offer enough intellectual property protection for algorithms. In other words, any one can easily reverse engineer our managed module by using tool, such as IL Disassembler.
Yes, it’s true that IL code is higher level than most other assembly languages and that, in general, reverse engineering IL code is relatively simple. However, when implementing an XML Web service or a Web Forms application, our managed module resides on our server. Because no one except us can access the module, no one can use any tool to see the IL—our intellectual property is completely safe.
If we’re concerned about any of the managed modules that we distribute, we can obtain an obfuscator utility from a third-party vendor. These utilities “scramble” the names of all the private symbols in our managed module’s metadata. It will be difficult for someone to “unscramble” the names and understand the purpose of each method. Note that these obfuscators can only provide a little protection since the IL must be available at some point in order for the CLR to process it. If we don’t feel that an obfuscator offers the kind of intellectual property protection that we desire, we can consider implementing our more sensitive algorithms in some unmanaged module that will contain native CPU instructions instead of IL and metadata.Then we can use the CLR’s interoperability features to communicate between the managed and unmanaged portions of our application. Of course, this assumes that we’re not worried about people reverse engineering the native CPU instructions in our unmanaged code.

JIT Compiler:
Even though today’s CPUs can’t execute IL instructions directly, CPUs of the future might have this capability. To execute a method, its IL must first be converted to native CPU instructions. This is the job of the CLR’s JIT (just-in-time) compiler. Figure 4 shows what happens the first time a method is called.



Figure4 : Calling a method for the first time
Just before the Main method executes, the CLR detects all the types that are referenced by Main’s code. This causes the CLR to allocate an internal data structure that is used to manage access to the referenced type. In Figure 1-4, the Main method refers to a single type, Console, causing the CLR to allocate a single internal structure. This internal data structure contains an entry for each method defined by the type. Each entry holds the address where the method’s implementation can be found. When initializing this structure,
the CLR sets each entry to an internal, undocumented function contained inside the CLR itself. This function is called JIT Compiler. When Main makes its first call to WriteLine, the JIT Compiler function is called. The JIT Compiler function is responsible for compiling a method’s IL code into native CPU
instructions. Because the IL is being compiled "just in time," this component of the CLR is frequently referred to as a JITter or a JIT compiler. When called, the JIT Compiler function knows what method is being called and what type defines this method. The JIT Compiler function then searches the defining assembly’s metadata for the called method’s IL. JIT Compiler next verifies and compiles the IL code into
native CPU instructions. The native CPU instructions are saved in a dynamically allocated block of memory. Then, JIT Compiler goes back to the type’s internal data structure and replaces the address of the called method with the address of the block of memory containing the native CPU instructions. Finally, JIT Compiler jumps to the code in the memory block. This code is the implementation of the WriteLine method (the version that takes a String parameter). When this code returns, it returns to the code in Main, which continues execution as normal.
Main now calls WriteLine a second time. This time, the code for WriteLine has already been verified and compiled. So the call goes directly to the block of memory, skipping the JIT Compiler function entirely. After the WriteLine method executes, it returns to Main. Figure5 shows what the situation looks like when WriteLine is called the second time. A performance hit is incurred only the first time a method is called. All subsequent calls to the method execute at the full speed of the native code: verification and compilation to native code are not performed again.



Figure5 : Calling a method for the second time

We should also be aware that the CLR’s JIT compiler optimizes the native code just as the back-end of an unmanaged C++ compiler does. Again, it may take more time to produce the optimized code, but the code will execute with much better performance than if it hadn’t been optimized.
Many people think that managed applications could actually outperform unmanaged applications. There are many reasons to believe this. For example, when the JIT compiler compiles the IL code into native code at run time, the compiler knows more about the execution environment than an unmanaged compiler would know.
Here are some ways that managed code could outperform unmanaged code:
1. A JIT compiler could detect that the application is running on a Pentium 4 and produce native code that takes advantage of any special instructions offered by the Pentium 4.
Usually, unmanaged applications are compiled for the lowest-common-denominator CPU and avoid using special instructions that would give the application a performance boost over newer CPUs.
2. A JIT compiler could detect that a certain test is always false on the machine that it is running on. For example, consider a method with code like this:
§if (numberOfCPUs > 1) {
?
}
This code could cause the JIT compiler not to generate any CPU instructions if the host machine has only one CPU. In this case, the native code has been fine-tuned for the host machine: the code is smaller and executes faster.
3. The CLR could profile the code’s execution and recompile the IL into native code while the application runs. The recompiled code could be reorganized to reduce incorrect branch predictions depending on the observed execution patterns. These are only a few of the reasons why future managed code can execute better than today’s unmanaged code. The performance is currently quite good for most applications, and it promises to improve as time goes on.
If our experiments show that the CLR’s JIT compiler doesn’t offer our application the kind of performance it requires, we may want to take advantage of the NGen.exe tool that ships with the .NET Framework SDK. This tool compiles all assembly’s IL code into native code and saves the resulting native code to a file on disk. At run time, when an assembly is loaded, the CLR automatically checks to see whether a precompiled version of the assembly also exists, and if it does, the CLR loads the precompiled code so that no compilation at run time is required.

References

THE COMPLETE REFERENCE VISUAL BASIC .NET- By Jeffery R. Shapiro
INTRODUCING .NET- By Wrox publication
COURSE MATERIAL ON .NET- By KICIT
LEARN TO PROGRAM WITH VISUAL BASIC .NET –By John Smiley

Introduction to .NET Framework and Components.....Article 2

.NET Framework and Components

“.Net” FRAMEWORK:

The .NET Framework consists of two parts: the common language runtime (CLR) and the Framework Class Library (FCL). The .NET Framework is the part of the initiative that makes developing services and applications really easy. And, most important, this is what this paper is all about: developing applications and XML Web services for the .NET Framework.
Almost all programmers are familiar with runtimes and class libraries such as the C-runtime library, the standard template library (STL), the Microsoft Foundation Class library (MFC), the Active Template Library (ATL), the VisualBasic runtime library, or the Java virtual machine. In fact, the Windows operating system itself can be thought of as a runtime engine and library. Runtime engines and libraries offer services to applications, and we programmers love them because they save us from reinventing the same algorithms over and over again.
The .NET Framework allows developers to leverage technologies more than any earlier Microsoft development platform did. Specifically, the .NET Framework provides on code reuse, code specialization, resource management, multilanguage development,security, deployment, and administration. It also overcomes some of the deficiencies of the current Windows platform.
The following section summarise what the CLR and the FCL provide.


Features of .Net Framework
1. Consistent programming model: Unlike today, where some operating system facilities are accessed via dynamic-link library (DLL) functions and other facilities are accessed via COM objects, all application services are offered via a common object-oriented programming model.
2. Simplified programming model: The CLR seeks to greatly simplify the plumbing and arcane constructs required by Win32 and COM. Specifically, the CLR now frees the developer from having to understand any of the following concepts: the registry, globally unique identifiers (GUIDs), IUnknown, AddRef, Release , HRESULTs, and so on. The CLR doesn’t just abstract these concepts away from the developer; these concepts simply don’t exist, in any form, in the CLR. Of course, if you want to write a .NET Framework application that interoperates with existing, non-.NET code, you must still be aware of these concepts.
3. Run once, run always: All Windows developers are familiar with “DLL hell” versioning problems. This situation occurs when components being installed for a new application overwrite components of an old application, causing the old application to exhibit strange behavior or stop functioning altogether. The architecture of the .NET Framework now isolates application components so that an application always loads the components that it was built and tested with. If the application runs after installation, then the application should always run. This slams shut the gates of “DLL hell.”
4. Simplified deployment: Today, Windows applications are incredibly difficult to set up and deploy. Several files, registry settings, and shortcuts usually need to be created. In addition, completely uninstalling an application is nearly impossible. With Windows 2000, Microsoft introduced a new installation engine that helps with all these issues, but it’s still possible that a company authoring a Microsoft installer package might fail to do everything correctly. The .NET Framework seeks to banish these issues into history. The .NET Framework components (known simply as types) are not referenced by the registry. In fact, installing most .NET Framework applications requires no more than copying the files to a directory and adding a shortcut to the Start menu, desktop, or Quick Launch bar. Uninstalling the application is as simple as deleting the files.
5. Wide platform reach: When compiling source code for the .NET Framework, the compilers produce common intermediate language (CIL) instead of the more traditional CPU instructions. At run time, the CLR translates the CIL into native CPU instructions. Because the translation to native CPU instructions is done at run time, the translation is done for the host CPU. This means that you can deploy your .NET Framework application on any machine that has an ECMA-compliant version of the CLR and FCL running on it. These machines can be x86, IA64, Alpha, PowerPC, and so on. This feature is very important if we change our computing hardware or operating system.
6. Programming language integration: COM allows different programming languages to interoperate with one another. The .NET Framework allows languages to be integrated with one another so that you can use types of another language as if they are your own. For example, the CLR makes it possible to create a class in C++ that derives from a class implemented in Visual Basic. The CLR allows this because it defines and provides a Common Type System (CTS) that all programming languages that target the CLR must use. The Common Language Specification (CLS) describes what compiler implementers must do in order for their languages to integrate well with other languages. Microsoft is itself providing several compilers that produce code targeting the runtime: C++ with Managed Extensions, C#, Visual Basic .NET (which now
subsumes Visual Basic Scripting Edition, or VBScript, and Visual Basic for Applications, or VBA), and JScript. In addition, companies other than Microsoft and academic institutions are producing compilers for other languages that also target the CLR.
7. Simplified code reuse: Using the mechanisms described earlier, you can create your own classes that offer services to third-party applications. This makes it extremely simple to reuse code and also creates a large market for component (type) vendors.
8. Automatic memory and management (garbage collection): Programming requires great skill and discipline, especially when it comes to managing the use of resources such as files, memory, screen space, network connections, database resources, and so on. One of the most common bugs is neglecting to free one of these resources, ultimately causing the application to perform improperly at some unpredictable time. The CLR automatically tracks resource usage, guaranteeing that your application never leaks resources. In fact, there is no way to explicitly “free” memory.
9. Type-safe verification: The CLR can verify that all your code is type-safe. Type safety ensures that allocated objects are always accessed in compatible ways. Hence, if a method input parameter is declared as accepting a 4-byte value, the CLR will detect and trap attempts to access the parameter as an 8-byte value. Similarly, if an object occupies 10 bytes in memory, the application can’t coerce the object into a form that will allow more than 10 bytes to be read. Type safety also means that execution flow will transfer only to well-known locations (that is, method entry points). There is no way to construct an arbitrary reference to a memory location and cause code at that location to start executing. Together, these measures ensure type safety eliminating many common programming errors and classic system attacks (for example, exploiting buffer overruns).
10. Rich debugging support: Because the CLR is used for many programming languages, it is now much easier to implement portions of our application using the language best suited to a particular task. The CLR fully supports debugging applications that cross language boundaries.
11. Consistent method failure paradigm: One of the most aggravating aspects of Windows programming is the inconsistent style that functions use to report failures. Some functions return Win32 status codes, some functions return HRESULTs, and some functions throw exceptions. In the CLR, all failures are reported via exceptions—period. Exceptions allow the developer to isolate the failure recovery code from the code required to get the work done. This separation greatly simplifies writing, reading, and maintaining code. In addition, exceptions work across module and programming language boundaries. And, unlike status codes and HRESULTs, exceptions can’t be ignored. The CLR also provides built-in stack-walking facilities, making it much easier to locate any bugs and failures.
12. Security: Traditional operating system security provides isolation and access control based on user accounts. This model has proven useful, but at its core assumes that all code is equally trustworthy. This assumption was justified when all code was installed from physical media (for example, CD-ROM) or trusted corporate servers. But with the increasing reliance on mobile code such as Web scripts, applications downloaded over the Internet, and e-mail attachments, we need ways to control the behavior of applications in a more code-centric manner. Code access security provides a means to do this.
13. Interoperability: Developers already have an enormous amount of existing code and components. Rewriting all this code to take full advantage of the.NET Framework platform is a huge undertaking and prevents the speedy adoption of this platform. So the .NET Framework fully supports the ability for the developer to access their existing COM components as well as call Win32 functions in existing DLLs.


References

THE COMPLETE REFERENCE VISUAL BASIC .NET- By Jeffery R. Shapiro
INTRODUCING .NET- By Wrox publication
COURSE MATERIAL ON .NET- By KICIT
LEARN TO PROGRAM WITH VISUAL BASIC .NET –By John Smiley

Introduction to.NET Framework and componets....Article 1

.NET Framework and Components

ABSTRACT:
Amongst the leading technologies in software world the most prominent and developing is the “.Net”, released in February, 2001. “.Net” is a framework that covers all the layers of software development right form the operating system. It provides the richest level of integration among presentation technologies, component technologies and data technologies ever seen on Microsoft platform.
The main goal behind the development of “.net” was to make development of internet applications as easy as desktop applications.
The .net framework is actually a wrapper around the operating system. The major components of the .net framework are CLR and FCL.
The paper gives an idea about .net and its capabilities. It covers all the details about .net framework, its features and its components such as FCL, CTS, CLS, CLR etc.
.Net presently works excellently on Windows platform. But it is not operable on other operating systems such as Linux, Unix, etc. Project “Mono” heads in the same direction. At the end, we present a overview of the Mono project.
Keywords:
.Net
.Net Framework
Base Class Libraries
Common Type System (CTS)
Common Language Specification (CLS)
Common Language Runtime (CLR)
Metadata
JIT Compiler

1. INTRODUCTION TO “.NET”

1.1 What is .Net?

.Net is a framework consisting of common language runtime and a set of .net base classes which allow us to build distributed, secure, scaleable, robust, easily deployable and maintainable applications in a language independent object-oriented web enabled managed way using rich level of integration amongst present technologies.

1.2 Features of .Net at a Glance:

· Properties, events and delegates are first class citizens.
· Assemblies eliminate “DLL hell”.
· API is object oriented.
· Same libraries for all languages.
· Cross language inheritance.
· Cross language debugging.
· ADO.net is better than ADO.
· ASP.net is better than ASP.
· Garbage collection.
· Application domain improves exe to exe communication.
· Common language runtime provides a secure environment for the code.
· Deployment is as simple as simple as xcopy.
· No, HRESULTS, no GUIDs and no type libraries.

1.3 Major Concerns in Today’s Scenario:

The current development model, types of applications that one creates today and the present status of intelligence has major concerns is as below:
1. Too many languages: We are required to learn different languages to accomplish different types of jobs. For example for creating windows applications we need VC++ and VB, for Web applications we need VBScript and for creating mobile applications we have to opt for eVC++ or eVB.
2. Language interoperability: There is no interoperability amongst the code written in different languages. This is because languages have no common datatype system. Also not all languages in use are object oriented.
3. No cross language inheritance and debugging: Microsoft offered a solution to language interoperability in the form of COM. This technology suggested the usage oif data types that represent the lowest common denominator ( means the ones that all languages can understand). However the usage of these data types was intimidating.
Though COM was a big step forward from the point of view of interoperability it still did not support concepts like cross language debugging and cross language exception handelling.
4. Inconsistent programming models and different developing environment: The next major problem is that of the different types of programming models that are still in existence. For example, windows applications are event driven whereas web applications are not. Also we have to learn usage of different IDEs to create different types of applications in different languages.
5. Deployment nightmares: The developer also faces the hurdle of deployment. While installing DLLS there is always a risk of overwriting the older version of it bearing one with the same name. On doing so the older clients are likely to break. COM addressed this problem of “DLL hell” by making it possible to use a component independent of its location in directory. However while deploying a COM component it was necessary to maintain a component ID, a type library and the actual component in synchronization. Moreover when the CCOM component is uninstalled all the three entities must be deleted. This was not a very clean way of installing/ uninstalling components.
6. Difficult OS usage: The function calls are very long and have very little organization such as Windows API functions.
7. Messy runtimes: Exceptions in windows based program occur through memory leaks, dangling pointers, exceeding array bounds or some other bug in the program. At such times the application abruptly terminates. This shows that Windows runtime does not provide any facility for automatic destruction of unreferenced memory or informing the applications about the exceptions.
8. Proprietary protocol: To develop an internet application that allows to communicate vital information with each other across existing communication lines, using Microsoft technologies we would need HTML, DHTML and JavaScript in front-tier; VBScript, ASP, MTS, C++, VB, COM in the middle tier and SQL, ADO in the back-tier. Sun’s solution to this could be to use Java applets and servlets in the front-tier, Enterprise Java Beans (EJB) or CORBA or RMI in the middle-tier and JDBC and a suitable database in the back-tier. The overall process would need a big infrastructure with different computers, different operating systems, different languages used for development. Secondly, the interoperability would be difficult.

1.4 Possible Solutions:

Technology           Microsoft Solution           Sun Solution

Client               Win Applications             Java applications

                     ActiveX Controls             Java Applets

Server               ASP                          Java Servlets

                     COM+/Win DNA                 Enterprise Java Beans

Mobile               eVC++ / eVB                  Java Midlets

Table1: Possible solutions to major concerns in present scenario.

The table1lists the solution provided by Microsoft and Sun for creating various types of applications.
Microsoft Solution: Though some of the solutions are commendable in solutions provided by Microsoft there is a smell of adhocism. They appear to more of patchwork attempting to solve the current problem rather than a well throughout design.
Sun Solution: Sun solutions are also good but have a major drawback. Sun says that one can create all types of applications easily and consistently if one uses only one language Java. However, it is too much to expect that all programmers would be willing to learn Java. What about those who have mastered other languages and what about the existing code written in languages other than Java.

1.5 .Net Solution:

.NET Framework       CLR, Base Classes, ASP.NET

Development Tools    VS.NET

.NET  Servers        SQL, BizTalk, Commerce, Exchange, Mobile IIS

.NET My Services     Presence, Location, Calender, Allert, Contacts, Passport, Inbox,

                     Documents, Wallet, Appplication settings, Favourites, Profiles

Table2: .Net solutions to major concerns in present scenario.

1.6 Common Development Model:

References

THE COMPLETE REFERENCE VISUAL BASIC .NET- By Jeffery R. Shapiro
INTRODUCING .NET- By Wrox publication
COURSE MATERIAL ON .NET- By KICIT
LEARN TO PROGRAM WITH VISUAL BASIC .NET –By John Smiley