|only for RuBoard|
The objects you construct with VB.NET will live out their lives within the .NET Framework, which is a platform used to develop applications. The platform was designed from the ground up by using open standards and protocols like XML, HTTP, and SOAP. It contains a rich standard library that provides services available to any language running under its protection.
The impetus behind its creation was the desire to develop a platform for building, deploying, and running web-based services. In spite of this goal, the framework is ideal for developing all types of applications, regardless of the design. The .NET Framework makes child's play of some of programming's most sophisticated concepts, giving you the ability to take advantage of today's cutting-edge architectures:
Distributed computing using open Internet standards and protocols such as HTTP, XML, and SOAP
Enterprise services such as object pooling, messaging, security, and transactions
An infrastructure that simplifies the development of reusable cross-language compatible components that can be deployed over the Internet
Simplified web development using open standards
Full language integration that make it possible to inherit from classes, catch exceptions, and debug across different languages
Deployment is made simpler because settings are stored in XML-based configuration files that reside in the application directory; there is no need to go to the registry. Shared DLLs must have a unique hash value, locale, and version, so physical filenames are no longer important once these considerations are met. Not having physical filenames makes it possible to have several different versions of the same DLL in use at the same time, which is known as side-by-side execution. All dependencies and references are stored within the executable in a section called the manifest . In a sense, we're back to the days of DOS because to deploy an application, you only need to xcopy it from one directory to another.
This book explores many aspects of .NET in order to gain a complete understanding of the components you write and the world in which they live. Doing it any other way is impossible . The .NET Framework provides so many services your components will use that discussing one without referring to the other is literally impossiblethey are that closely tied together.
Two major elements of the .NET Framework will be addressed repeatedly throughout this book. The first is the Common Language Runtime (CLR), which provides runtime services for components running under .NET.
The second element is the .NET class library, a vast toolbox containing classes for everything from data access, GUI design, and security to multithreading, networking, and messaging. The library also contains definitions for all primary data types, such as bytes, integers, and strings. All of these types are inherently derived from a base class called System.Object , which you can think of as a "universal" data type; there is no distinction between the types defined by the system and the types you create by writing classes or structures. Everything is an object!
In the past, passing a string from a component written in VB to one written in C++ (or vice versa) could be frustrating. Strings in VB weren't the same as the strings in C++. In fact, under some circumstances, using a component written in C++ from VB was downright impossible because of issues involving data types. VB just doesn't know what to do with an LPSTR ! Every language under .NET uses the same data types defined in the base class library, so interoperability problems of the past are no longer an issue.
This book touches on several major areas of the library and focuses on the development of components using VB.NET. However, if you follow the examples, you might be surprised at just how much you know.
The CLR is the execution engine for the .NET Framework. This runtime manages all code compiled with VB.NET. In fact, code compiled to run under .NET is called managed code to distinguish it from code running outside of the framework.
Besides being responsible for application loading and execution, the CLR provides services that will benefit component developers:
Invocation and termination of threads and processes
Object lifetime and memory management
Code access and role-based security
Exception handling (even across languages)
Deployment and versioning
Interoperation between managed and unmanaged code
Debugging and profiling support (even across languages)
Runtimes are nothing new. Visual Basic has always had some form of a runtime. Visual C++ has a runtime called MSVCRT.DLL . Perl, Python, and SmallTalk also use runtimes. The difference between these runtimes and the CLR is that the CLR is designed to work with multiple programming languages. Every language whose compiler targets the .NET Framework benefits from the services of the CLR as much as any other language.
.NET is also similar to Java. Java uses a runtime called the Java Virtual Machine. It can run only with Java code, so it has the same limitations as the other languages mentioned previously. Another distinction is that the JVM is an interpreter. Although all languages in the .NET environment are initially compiled to a CPU-independent language called Intermediate Language (which is analogous to Java byte code), IL is not interpreted at runtime like Java. When code is initially executed, one of several just-in-time (JIT) compilers translate the IL to native code on a method-by-method basis.
Cross-language integration is one of the major benefits provided by the CLR. If a colleague has written a base class in C#, you can define a class in VB.NET that derives from it. This is known as cross-language inheritance . Also, objects written in different languages can easily interoperate . The two parts of the CLR that make this interoperation possible are the Common Type System and the Common Language Specification.
The Common Type System (CTS) defines rules that a language must adhere to in order to participate in the .NET Framework. It also defines a set of common types and operations that exist across most programming languages and specifies how these types are used and managed within the CLR, how objects expose their functionality, and how they interoperate. The CTS forms the foundation that enables cross-language integration within .NET.
The Common Language Specification (CLS) is a subset of the CTS that describes the basic qualities used by a wide variety of languages. Components that use only the features of the CLS are said to be CLS-compliant. As a result, these components are guaranteed to be accessible from any other programming language that targets .NET. Because VB.NET is a CLS-compliant language, any class, object, or component that you build will be available from any other CLS-compliant programming language in .NET.
VB has always been easy to learn, but the power of simplicity came with a price. The language itself has never gotten the respect it deserves because it always hid so much from the developer; getting under the hood required a sledgehammer. This is no longer true. While VB is still a great language and is relatively painless to learn and use, you are no longer restricted in how "low you can go."
One of the most important concepts behind .NET is that all languages are on a level playing field; the choice of language should be determined more by your style than anything else. This is probably the reason why you prefer VB over other languages: you like the syntax of Visual Basic and appreciate its simplicity. No longer is choice of language a concern, because VB.NET is just as fast as C# and it does a few things, such as event declaration and conditional exception handling, better. But for the most part, any language that runs under .NET will provide you with the tools to develop cutting edge software. Thus, it truly is a matter of style. VB.NET is no more or no less of a language than any other in the .NET Framework.
|only for RuBoard|