This article is designed for those you desire to learn a little bit concerning the .Net framework. Not merely will it explain you how .Net operates, it will explain where ASP.NET fits in. What is .NET, though? If you check out Microsoft's .NET Page, it is described as "Microsoft's platform for XML Web services." Microsoft too describes .NET as a mode of delivering software services.

Though, these pitches are now looking at one little facet of .NET, and seems at it from a business or corporate viewpoint. For developers, .NET is a completely new design pattern. In this article we will inspect this new pattern in easy-to-understand terms and we'll seem at how ASP.NET fits in!

Programs written meant for Windows are compiled down straightly into machine code; fairly, they are interpreted to use the Win32 libraries, which are a put of hundreds of Windows-specific functions. These functions converse straightly with Windows, which in revolve knows how to communicate with the lower-level hardware. So when you write a Visual Basic program to simply display a message box, this entire process doesn't begin until you compile the project creates an executable. Once this process in complete, you will have an executable file (.exe), which can be run on a few Windows box by simply double-clicking the icon – Visual Basic is not wanted. In spirit, the Visual Basic compiler has curved your high-level instructions into amazing the Windows operating system can appreciate, which, in turn, is interpreted down into instructions the real computer can understand.

Thankfully, all of those translations are hidden from you, the developer. You can concentrate on simply writing your programs using your high-level language of choice. It is then the compiler's job to do all of the necessary translations, resulting in a final executable file.

There are, however, some fundamental problems with this approach:

1. It is very platform accurate meaning that when you write a program using Visual Basic it will simply run on computers that utilize Microsoft Windows.
2. There is no promise that any two executable programs written in dissimilar programming languages will hold similar low-level code, making it next to impossible for dissimilar programming languages to share libraries of functions.
3. The Win32 APIs are nothing in excess of a veer of functions. These functions hold cryptic descriptions and calling parameters. Since there are period in a VB or Visual C++ program where you may wish to call a Win32 API function directly, finding the right Win32 API function call you require to create can be a pain.

The 2nd problem is one of the most reflective as programs turn into more advanced. Preferably, we'd like to be capable to share any purpose libraries or components written in one language through another impeccably. This task is infuriated owing to the fact that different programming languages may describe prehistoric data types differently. For example, Visual Basic allows developers to make arrays by any lower bound, whereas Visual C++ forces arrays to have a lower bound of zero.