Click here to Skip to main content
Click here to Skip to main content

Introduction to .NET

, 13 Feb 2002
Rate this:
Please Sign up or sign in to vote.
The article introduces Microsoft's .NET framework and compares it to Sun's J2EE

Introduction

Microsoft and Sun's Confrontation

It's new - it's powerful - it solves lots of problems - and it is threatening to a vast community of Java worshippers, and best (or worst) of all it's from Microsoft. You guessed it right; I am talking about .NET. 

Around 1995, Java was generating the same vigor as is generated by .NET today. May be I am being a bit unfair; actually Sun's Java was a much bigger event than .NET. My intention is not to belittle .NET's arrival; but what's true is true! Sun's Java introduced a revolutionary approach of software development. Previously you had developers specializing in either Visual C++, or  VB or Tcl/Tk (for UNIX based platforms). Finding an individual who is conversant in various competing languages was next to impossible. With Sun's Java - all that the programmers needed to know was a single language - namely Java; thus Java provided the programmer's with a unique tool that solved their ages long problem of platform independence. 

Sun furthered their service to the Computer Industry by tackling the issue of web development with applets, JSP (Java Serve Pages) and Servlets. Then came Sun's EJBs (Enterprise Java Beans). EJB brought an end to the painful era of distributed application development. All this time when Sun was winning our admiration; Microsoft was trying their level best to match up to Sun's tools. Although many of the technologies that J2EE use, were introduced by Microsoft (e.g. OLE/COM was present before EJB, ASP was developed before JSP etc.), but Sun's J2EE better many of these technologies and popularized them with their Java platform independence approach (with .NET Microsoft has done the same - namely - improved not only upon their existing technologies but on J2EE as well)

But Sun was uncatchable. Sun's unique approach of  "distributing  it free" helped them in gaining popularity amongst developers. Sun addressed industry's needs by developing or by enhancing tools like JSP, Servlets, EJB, JMS, JNDI, JNI etc. Sun stuffed these excellent tools under one umbrella - the Java2 Enterprise Edition (J2EE). Microsoft's equivalent to J2EE was Microsoft's Windows DNA programming model. DNA's popularity was marred by Microsoft's proprietary approach; while J2EE are a set of specifications, DNA is a Microsoft's propritery implementation. With the world depending more and more on the Internet - and Sun's tools becoming the foremost media for the web applications, Microsoft seemed to be loosing the battle. But Microsoft has a wonderful history of starting late but catching up quickly (Windows vs. Macintosh, Internet Explorer vs. Netscape ). So Microsoft put their best men at work and started calling the project as  Next Generation Windows Services (NGWS). The outcome of the project is what we now know as .NET. .NET has borrowed most of it's ideas from Sun's J2EE; but this time Microsoft has really outdone themselves. .NET strengthen many of the features of J2EE, and it also makes up for most of Microsoft's mistakes. 

A few months back when the hype of .Net (and C#) started, I rejected the hype since I am more of a Java and Visual C++ lover. When it comes to Web development or distributed application development I prefer Sun's Java, Servlets, JSP and EJBs. And when it comes to Windows application, Microsoft's Visual C++ is the tool of my choice. So my immediate reaction was - "Hmmm, yet another of Microsoft's gimmick; I won't fall for this at all !!!". But then I started reading about it and the more I read, the more I liked. It was as if for the first time in Microsoft's history they have actually listened to our cries. With .Net Microsoft isn't telling us how to do our job, but it is the outcome of a thorough consideration of developer's  feedback.

Programming in Visual C++ has always made be feel proud of myself. Those of you who have used Visual C++ to develop OLE, COM, COM+, ActiveX applications would know what I mean. Every time I make an ActiveX client/serve or an ActiveX control, I get up from my computer fully satisfied and content. But making a Java Bean never gives me that satisfaction - simply because it's so damn easy !!!. With .NET Microsoft has made lots of things even easier not only in comparison to their previous technologies but even in comparison to Java.

When I started reading about .NET, I almost always came across biased or one sided views. So rather than being swayed by Microsoft or Sun's  claims I decided to make my own opinion - and that is the prime reason of writing this article.

The rest of this article delves deeply in .NET. The article concludes with the future predictions made by the IT pundits.

.NET - a framework 

The most important question is What is .NET ?, and the simplest answer is : it is a Framework in which Windows applications may be developed and run. I agree that this answer does not tell much. In order to understand .NET we must go back in time and follow the development of Windows and the advent of Windows programming. 

Let's see how a traditional windows application works. 

Windows provide the programmers with various functions - called API. Starting from the very first time Windows enter the commercial market to the latest version of WindowsXP, APIs are the basic tool to let the Windows know what you want it to do. If you want to create a Dialog Box you must call a specific API provided to you by Windows. Making a button requires another API call. And the list goes on. As new GUIs appear on the seen, new APIs are introduced in Windows. But using these native APIs was a very challenging task. Making a simple Window that prints "Hello World" could take more than hundred lines. Compare this to 5 lines of "Hello World" program in DOS. Due to this difficulty, Windows programming was considered something better left to the experts. Microsoft and other commercial organization's realized this and started marketing Visual Tools that made the programmer's life easy. Using Visual C++, Visual Basic, Borland's C++ and other such IDEs, it became simpler to make Windows programs. 

Various vendors develop their own "Wrapper classes"  that wrapped the Windows APIs in an Object-Oriented way. The Microsoft Foundation Classes (MFC) that are used in Visual C++, is an example of Wrapper classes. The MFC equivalent of Visual Basic is VBRun; and for Visual J++ it is WFC. These Wrapper Classes, along with the Visual GUI tools made it very convenient to make windows programs. 

Microsoft realized that applications need a solid way to talk to each other. And this resulted in the introduction of Object Linking and Embedding (OLE). OLE was an extremely useful concept, but it had two major flaws : It was notoriously difficult to program, and it was very limited in its scope - i.e. it only did a few things like drag and drop, clipboard sharing, OLE client, OLE server etc. Microsoft addressed (or at least tried to address) both these problems. They upgraded OLE to COM. COM  was much more capable than OLE, and it introduced new concept like ActiveX controls which directly competed with Java Applets. As for the difficulty of programming OLE/COM; Microsoft expanded the MFC and VBRun to take care of most of the dirty job. Although making an ActiveX application still was slightly tricky in Visual C++, but developing an ActiveX application in Visual Basic was extremely easy; and hence Visual Basic became the foremost ActiveX development media.

The Internet revolution posed new problems and challenges. C/C++ which was the tool of champions was not suited/ready for Web Development. Microsoft tried expanding MFC, and included several network oriented classes - like CSocket, CASyncSocket, and several HTTP based classes. Using these classes a programmer could very develop a distributed application - although not without considerable effort. But these applications were always customized and targeted to the specific task. The developers had to take care of the gory network communication details themselves. By now object-oriented analysis and development had started becoming ubiquitous. Although technologies like Remote Procedure Call (RPC) was a great help to the programmers; but it was limited in its scope. With programmers following the Object-Oriented development RPC was not much help at all; since RPC did not allow passing objects as parameters. This major issue was addressed by introduction of industry's agreed upon standards like CORBA, IIOP, RMI, DCOM etc. All these standards used customized protocol to transmit an object over the network, and they required a tight coupling between the server and the client - i.e. the client needed to be fully aware of how to talk to the server. Due to this tight client-server coupling all these protocols needed considerable deployment efforts in order for distributed applications to function properly. Sun did come up with another layer on top of RMI - the famous Enterprise Java Beans (EJB). The EJB container provided lot of services for free - all that a programmer had to do was to extend (inherit) from an appropriate EJB base class and there you have it - a fully functional distributed application. EJB made programmer's life extremely easy; but it did not eradicate the client-server coupling issue. 

While all this was happening - Microsoft was still not facing the writing on the wall - MICROSOFT NEEDED SOMETHING RADICALLY NEW TO  MATCH UP TO THE CHANGING TIMES AND CHANGING DEMANDS. Microsoft soon realized that upgrading their existing technologies would not work - what they needed was a complete change in their philosophy. OLE was upgraded to COM - and it was welcomed by all. COM was then upgraded to COM+. Microsoft addressed the distributed programming issue with the introduction of DCOM. Although COM/COM+/DCOM were all good technologies but these technologies required significant learning curve. Sun on the other hand was making things easier and hence a majority of developers were turning towards Java based technologies for distributed enterprise applications.

Microsoft - after the cold treatment faced by DNA - got their gurus together and asked them to reflect back on DNA and to come up with a future vision. This group came up with so many new and great ideas which made Microsoft realized that no amount of up gradation or extension in MFC/VBRun/WFC, COM/COM+/DCOM, ASP, APIs etc. would even come closer to realizing this new vision. So they made a radical but correct decision - and this was the decision of coming up with something big, something new, and something that lets Microsoft make up for their lapses - this was called the .NET Framework

The remaining portion of this article discusses a few of the main features and components of .NET framework. After having introduced .NET in brief I'll conclude this article by answering the million dollar question - "What is .NET ?" 

This article assumes that the reader has a solid programming experience. IT also assumes some experience of JAVA. Although experience of RMI, EJB, ActiveX, VC, VB is not required but having an introductory knowledge of these tools would help appreciate .NET better. 

go to top 

Major Components of .NET 

The diagram given below describes various components of .NET Framework[3]

Now we explain these components briefly...

The .NET framework can only be exploited by languages that are compliant with .NET. Most of Microsoft languages have been made to fully comply with .NET.

.NET also introduces Web Forms, Web Services and Windows Forms. The reason why they have been shown separately and not as a part of a particular language is that these technologies can be used by any .NET compliant language. For example Windows Forms is used by VC, VB.NET, C# all as a mode of providing GUI.

The next component of .NET is the .NET Framework Base Classes. These are the common class libraries (much like Java packages) that can be used by any .NET compliant language. These classes provide the programmers with a high degree of functionality that they can use in their programs. For example their are classes to handle reading, writing and manipulating XML documents, enhanced ADOs etc.

The bottom most layer is the CLR - the common runtime language. The CLR is discussed  in detail in [7].

go to top 

What is "Common Language Specification" (CLS)

One of the obvious themes of .NET is unification and interoperability between various programming languages. In order to achieve this; certain rules must be laid and all the languages must follow these rules. In other words we can not have languages running around creating their own extensions and their own fancy new data types. CLS is the collection of the rules and constraints that every language (that seeks to achieve .NET compatibility) must follow. Microsoft have defined three level of CLS compatibility/compliance. The goals and objectives of each compliance level has been set aside. Given below are the three compliance levels with their brief description:

COMPLIANT PRODUCER

The component developed in this type of language can be used by any other language.

CONSUMER

The language in this category can use classes produced in any other language. In simple words this means that the language can instantiate classes developed in other language. This is similar to how COM components can be instantiated by your ASP code. 

EXTENDER

Languages in this category can not just use the classes as in CONSUMER category; but can also extend classes using inheritance.

Languages that come with Microsoft Visual Studio namely Visual C++, Visual Basic and C#; all satisfy the above three categories. Vendors can select any of the above categories as the targeted compliance level(s) for their languages.

go to top 

What is "Common Language Runtime" (CLR)

CLR is .NET equivalent of Java Virtual Machine (JVM). It is the runtime that converts a MSIL code into the host machine language code, which is then executed appropriately. [7] gives a detailed description of CLR. 

go to top 

What is "Microsoft Intermediate Language" (MSIL)

A .NET programming language (C#, VB.NET, J# etc.) does not compile into executable code; instead it compiles into an intermediate code called Microsoft Intermediate Language (MSIL). As a programmer one need not worry about the syntax of MSIL - since our source code in automatically converted to MSIL. Complete specifications of MSIL can be found at http://msdn.microsoft.com/net/ecma/part_3_IL_inst_set.pdf . The MSIL code is then send to the CLR (Common Language Runtime) that converts the code to machine language which is then run on the host machine[7]. MSIL is similar to Java Byte code. A Java program is compiled into Java Byte code (the .class file) by a Java compiler, the class file is then sent to JVM which interprets it and runs it on the host machine.

go to top 

What is "Common Type System" (CTS)

All this time we have been talking about language interoperability, and .NET Class Framework. None of this is possible without all the language sharing the same data types. What this means is that an int should mean the same in VB, VC++, C# and all other .NET compliant languages. Same goes for all the other data types. This is achieved through introduction of Common Type System (CTS). CTS, much like Java, defines every data type as a Class. Every .NET compliant language must stick to this definition. Since CTS defines every data type as a class; this means that only Object-Oriented (or Object-Based) languages can achieve .NET compliance. Given below is a list of CTS supported data types: 

 

Data Type Description
System.Byte 1-byte unsigned integer between 0-255
System.Int16 2-bytes signed integer in the following range:
32,678 to 32,767
System.Int32 4-byte signed integer containing a value in the following range:
-2,147,483,648   to   2,147,483,647
System.Int64 8-byte signed integer containing a value from 
-9,223,372,036,854,775,808 to 9,223,372,036,854,775,807
System.Single 4-byte floating point. The value limits are:
for negative values:
-3.402823E38  to - 1.401298E-45 
for positive values:
1.401298E-45 TO 30402823E38 
System.Double 8-bytes wide floating point. The value limits are:
for negative values:
-1.79769313486231E308 to - 4.964065645841247E-324
for positive values:
4.964065645841247E-324 to 1.79769313486232E308
System.Object 4-bytes address reference to an object
System.Char 2-bytes single Unicode Character.
System.String string of up to 2 billion Unicode characters.
System.Decimal 12-bytes signed integer that can have 28 digits on either side of decimal. 
System.Boolean 4-Bytes number that contains true(1) or false (0)

go to top 

.NET Framework Base Classes

Lets look at the following Visual C++ code extract.:

CView myView;
myView.MessageBox("Hello World", ".Net Article", MB_OK);
::MessageBeep(MB_ICONHAND);

The code above first creates an object of CView. u is a built in MFC class. In second line the code calls CView method MessageBox() to show a dialog box containing an OK button and a "Hello World" message. The caption of the dialog box is ".Net Article". In the third line the program makes a direct call to a windows API, the scope resolution symbol "::" before a method indicates that it is a direct API call. MessageBeep() uses a system defined wave file "MB_ICONHAND" to play the appropriate sound. The above three lines uses two different types of functions - one that the MFC provides and the other that the Operating System provides. Remember that MFC is nothing but a group of wrapper classes that encapsulate APIs. You can totally bypass MFC and develop an application solely using APIs. How about writing the same code in Visual Basic ?. The MFC equivalent of Visual Basic is VBrun. Although you may be able to  use the MessageBeep() API in VB; but the Class CView does not exist in VBRun. You will have to learn VBRun in order to use an equivalent of CView. The same holds for other programming languages; and to further complicate the situation various vendors have their own names and hierarchy of the wrapper classes. What this means is that MFC is Microsoft wrapper classes for C++; Borland has their own wrapper classes. Same goes for Java. Microsoft provides a powerful wrapper classes package named  WFC to be used with Visual J++, other vendors have their own wrapper classes. 

In addition to this, if your application uses a COM component then you code would look radically different in different languages - this is because different languages have different implementation of COM, and have different data types. Given below is an extract of a COM component code (this has been taken out from SMTP.Server application). The code below returns a String. But in the world of COM, there is no string data type; instead the equivalent is "BSTR". The MFC implementation of string is the class CString (very similar to String class in Java). CString provides a function AllocSysString() that does the necessary conversion to BSTR

BSTR CServer::GetCcTo() 
{
   return m_strCcTo.AllocSysString();
}

Now if a COM component was to be developed in VB. The above code would need to go through serious changes. Based on the above discussion we come to the following conclusion :

Every Windows application language has their own implementation and interfaces for the following:

  1. COM Components,

  2. Operating System Specific APIs (e.g. Win32API, Win16 API, Windows CE APIs)

  3. Wrapper Classes (e.g. MFC, VBRun, WFC)

The above mentioned  differences create unnecessary work for a programmer; and hamper interoperability between various languages. 

Many Visual C++ programmers are reluctant to learn Visual Basic despite the fact that VB is much easier than VC. Although VC applications are faster, and this may be the reason why programmers may prefer VC, but in case of a simple COM component the increased productivity in VB more than make up for a slight penalty in speed. Personally I prefer to stick to VC, mainly because of the fact that I will have to learn VBRun, VB specific data types, and VB specific COM implementation. It would be great if VB and VC had  common data types, and if MFC was also present in VB. This would reduce my learning curve to almost none, and would encourage thousands of programmers like me to embrace VB.

There is another problem with existing COM implementation. While a COM component can be used in many languages irrespective of how they were developed. These components can not be extended/inherited from. I have always fancied the very idea if being able to inherit/extend from a COM component. Unfortunately it is not (at least up till now) possible unless you have an access to the source code of the component. So the need of the hour is :

  • A Common wrapper class implementation

  • A Common Data Type system 

  • Ability to inherit/extend from COM Components.

And the solution to all this is - .NET Class Framework. Those of you who are familiar with MFC/VBRun/WFC can look at this framework as a group of wrapper classes that are shared across VC, VB, and any other .NET compliant language (a language that follows the Common Language Specifications "CLS"  - set forth by Microsoft). So now we all have to learn only one Class Framework and can use it whether we are working in VB or in VC or in any other CLS compliant language.  An important terminology related to .NET Framework is Namespace. Since you would frequently come across this term in any .NET article; its good if we formally define it. Namespace is a logical grouping of related interfaces, structures and classes. Java programmers are familiar with the package concept. The namespace is very similar to the package concept. A Namespace may contain further namespaces. This would result in a tree like hierarchical structure. .Net Class Framework is nothing but a hierarchical structure of namespaces. In .NET Class Framework "System" is the starting namespace. A few other namespaces within System are System.Security, System.Data, System.Console, System.WinForms etc. 

If you want to program a .NET application you will have to learn .NET Class Framework; just as a Java programmer learns the basic package hierarchy (e.g. java.util, java.lang, javax.servlet etc.).

go to top 

Web Services 

Web services is an extension of ActiveX. Those of you who have used ASP and JSP both, know the apparent shortcomings of ASP. JSP has been enriched with the concepts of Beans and Tags. ASP equivalent for Beans and Tags was ActiveX Controls and ActiveX automation servers. Let me take a minute to explain this point a bit further. Web Services is NOT a Microsoft proprietary standard. It is a W3Consortium standard, and has been developed by Microsoft, IBM and many other big names of the industry.

Functions are of two types. The ASP built-in functions, and the programmer defined/implemented functions . In order to use the built-in functions you just need to pass the appropriate parameters and make a simple call to these functions. The functions are implemented by the ASP itself. The string manipulation functions, Number conversion functions are an example of built in functions. 

The programmer defined functions are the functions that are defined and implemented by the programmer. A programmer can either write these functions in the same asp file or can write them in another file. If the function code resides in the same asp file then the programmer can directly call that function. In case the function resides in another file , say "func.asp"; then the programmer needs to include that file by writing a statement like <!-- #include file="func.asp" -->; and now the programmer can use the function. The programmers can also make ActiveX automation servers, and call various function of these ActiveX servers. But one limitation is very obvious -- no matter which type of function you use, the function MUST physically reside on the same machine. For example your ActiveX automation server must be implemented either as a .dll or as an .exe and then must also be registered in Windows Registry before an asp code can call its functions. (you may download SMTP.Server - an ActiveX component developed by the author - to get a better idea of how to use an ActiveX component from you ASP/VC/VB code.) In a world where the Internet has become not only a necessity but also a way of life - it is obvious that this limitation is a strong one. Microsoft's answer to this problem is "Web Services". The idea goes something like this :

  1. The Web service provider develops a useful function(s), and publish/advertise it. The Web Service provider uses Web Service Description Language (WSDL) standard to describe the interface of the function(s). This is much like the Type Libraries (TLB) and Object Description Language files (ODL) that needs to be generated with the ActiveX automation servers.

  2. The programmer/client who needs the function does a lookup by using a process called - Web Service Discovery or SOAP Discovery (also called DISCO for Web Service DISCOvery)

  3. The Actual communication between the client program and the web service takes place through a protocol called Simple Object Access Protocol (SOAP) - SOAP is an XML based light weight protocol used for communication in a decentralized distributed environment. 

As is evident from the above discussion that at the heart of all the communication is XML. Both SOAP, WSDL leverage on XML. 

We have all either used or at least heard of  network communication protocols like RPC (Remote Procedure Call); RMI (Remote Method Invocation), CORBA, DCOM, IIOP. All these technologies have the same purpose - to enable calling a function/Object on a remote machine. So how is Web Service (or SOAP) any different than these existing technologies ? . The main difference is that SOAP uses HTTP/HTTPS protocol; unlike all the other technologies that uses specialized protocols for distributed communication. Microsoft, with this simplified approach has tried to bring sanity and unification to the world of distributed programming. Distributed applications are heavily dependent on JNDI lookups, RMI, CORBA, IIOP, Serializability and other intricacies. With Web Service and .NET development tools ; Microsoft have provided us with a much simpler way of developing distributed applications. So what is the catch ?. The obvious catch is that this is an ASP.NET specific technology (at least for now); but with time SOAP, WSDL, DISCO will most certainly gain wider acceptance.  

According to Microsoft's tests an application developed ASP.NET using ADO.NET and Web Services,  is many times more efficient than an equivalent application developed in JAVA, JSP, Servlets and  EJBs. [1]

Note that .NET has no direct equivalent of EJBs. So considering Web Services as an equivalent to EJB will be in correct. However some of the functionality of an EJB can be provided by Web Services.

With .NET, Microsoft has followed one guiding principle - make it as simple as possible. And Web Services is no exception to this ideology. See the example below and judge for yourself as to how easy it is to develop a Web Service. And compare this with how "EASY ?" it was to develop an ActiveX automation server; or how "easy ?" it is to develop an EJB.

Web Service Example

Open any text editor and type in the following Visual Basic code, and save the file under ".asmx" extension.

Imports System
Imports System.Web.Services
Imports Microsoft.VisualBasic
Public Class HelloWorld : Inherits WebService
    Public Function <WebMethod()> GreetTheUser(strUserName as String)  as String
        Select Case strUserName
            Case "Kashif Manzoor"
                return "Hello Author"
            Case "Amna Kashif"
                return "Hello Ms. Amna Kashif"
            Case "Ahmed Luqman"
                return "Hello little Ahmed"
            Case Else
                return "Hello Stranger"
        End Select
    End Function
End Class

The first three lines import needed Classes. Import is similar to the import used in Java or the #include in C/C++. The rest of the code is self explanatory. Notice that the Class extends/inherits from the built in Web Service class; this is mandatory. Also notice that the Function is declared with the key word <WebMethod()> this indicates that this function can be invoked from the web across the Internet. You may add other private functions in your class but those functions will not be accessible to outside word. 

So that's it !!! you have successfully made your first  Web Service. Although the service simply takes in a name and returns a greeting; but it is enough to give you a flavor of Web Services. This Web Service can now be accessed from your ASP.NET code. This article does not intend to explain either ASP.NET or Web Services in details , the interested reader should consult ASP.NET manual or visit MSDN site for more details. 

Deploy your ".asmx" file on Web Service aware Application Server like IIS. And open up a Web Service aware browser like IE. Type in the appropriate URL for the file. If the file is in the default web application folder then the URL would be "http://localhost/HelloWorld.asmx". What do you think would happen ?. You will see a well formatted web page, giving you the details of the GreetTheUser() method. And at the bottom of the page you will be given an edit box, where you can enter the "strUserName" and then press a button beside the edit box. Once you do that, you will receive the greeting string as an XML document. This is a new and a wonderful feature.  

Lets not be unfair with Sun's technologies here. Making an EJB (at least a stateless and stateful EJB) is no more difficult than the above example. What makes EJBs tricky is the deployment, the JNDI lookups, the Stubs and the application servers that support EJBs. With Microsoft's "click and ready to go" approach and easy to use utilities that come with Visual Studio.NET, deploying any of .NET application is extremely easy. 

In conclusion Web Services is an evolutionary idea as opposed to being a revolutionary idea, its just an other distributed development tool - which happens to be  extremely simple to use. Incorporation of Web Services in ASP.NET, has taken ASP to a new level of respectability. Web Services has already started gaining popularity and is also incorporated in the Java platform. Visit http://java.sun.com to get the latest on Web Services support in Java platform.

go to top 

Web Forms 

Just as the Win Forms provide a unified way of developing GUI for desktop application, the Web Forms provide similar tool for web applications. Web Forms has been introduced in .NET as a part of ASP.NET. Web Forms are a forms engine, that provide a browser-based user interface. 

To appreciate Web Forms you may consider how GUI is rendered in current Web applications. The GUI is rendered by using HTML tags. (e.g. <input type=text name=editbox1 maxlength=10 size=10 >, will draw an edit box on the web page) Web Forms can also have the intelligence to use HTML, DHTML,WML etc. to draw the controls on the web page based on the browser's capabilities. Web Forms can also incorporate the logic behind these controls. Its like hooking up the code to a GUI control. Just like in your VB application, you can associate a code with a button on the web page, this code will be run on the server when the button is pressed. This is in contrast to the scripts that run on the clients when a button is pressed. This approach is different to the Java approach. In Java a programmer can simulate this functionality through JavaScript and Servlets. But with Web forms this is done transparently. A Java programmer may consider as if each HTML control has its dedicated "Servlet" running in the background. Every time the control receives any event of interest (e.g. button pressed, selection changed etc.) this specific "Servlet" is called. This results in much cleaner code and an excellent logic separation between presentation and business logic  layers.

Web Forms consist of two parts - a template, which contains HTML-based layout information for all the GUI elements and a Component which contains all the logic to be hooked to the controls or GUI elements. This provides a neat presentation layer and application logic layer separation.

The GUI will be rendered on the client side, while the code that has been hooked to the GUI elements will run on the server side (very much like a button being pressed on a JSP and a Servlet being called in response. But with Win Forms this has been made extremely easy). The incorporation of Web Forms in ASP.NET is an attempt to take ASP to a new level where it can seriously challenge JSP. 

Another good feature of Web Forms is that it can be built to have enough intelligence to support a vast variety of browsers. The same ASP page would render itself using DHTML, if the browser is IE 5.5. but if  the browser is Netscape the web page  will be rendered using HTML tags; if the page is being accessed through a WAP device the same page will render itself using WML tags.

One of the obvious disadvantage of ASP over Java was that there was that an ASP code was a maintenance nightmare. While a Java programmer can use Java Beans, Tags and also Servlets to achieve presentation and business layer separation - no such mechanism was present to a ASP programmer. With ASP.NET Microsoft has provided such presentation-business layer separation - by introducing the concept of Web Forms: 

  1. ASP.NET Web Forms provide an easy and powerful way to build dynamic Web UI.
  2. ASP.NET Web Forms pages can target any browser client (there are no script library or cookie requirements).
  3. ASP.NET Web Forms pages provide syntax compatibility with existing ASP pages.
  4. ASP.NET server controls provide an easy way to encapsulate common functionality.
  5. ASP.NET ships with 45 built-in server controls. Developers can also use controls built by third parties.
  6. ASP.NET templates provide an easy way to customize the look and feel of list server controls.
  7. ASP.NET validation controls provide an easy way to do declarative client or server data validation.

 For those of you (like me) who turned to Java for web development mainly due to spaghetti code of ASP- ASP.NET is worth exploring. Since it introduces some exciting new ways to write clean code (Personally I find Web Forms an exciting new concept - that does not have a direct equivalence in Java platform)

go to top 

Windows Forms

Windows forms (also called Win Forms) are used to create GUI for Windows desktop applications. The idea of Win Form has been borrowed from Windows Foundation Classes (WFC) which were used for Visual J++. Win Form provide an integrated and  unified way of developing GUI. It has a rich variety of Windows controls and user interface support. 

Numerous classes and functions were used by programmers to handle GUI. MFC in VC++, direct API in C++ and VB Forms Engine in VB are just a few examples of different ways of handling GUI. 

Simply put - Win Form is just another group of wrapper classes that deal specifically with GUI. Win Form classes encapsulate the Windows Graphical APIs. Now the programmers would not need to use the Windows Graphical APIs directly; and since Win Form has been made a part of .NET Class Framework; all the programming languages would use the same Win Form classes. This would rid the programmers of the need to learn different GUI classes/tools. Win Forms in the part of the namespace System.Winforms

With Win Forms we can make a single user interface, and use it in VC++, VB, C#. Using Visual Studio.NET simply design the GUI, by dragging the controls on a form (something that all VC++ and VB programmers are well familiar with). Now you can use the same form either in VB, VC++ or in C#. And this is all made possible because Visual Studio.NET uses the  System.Winforms namespace to draw the GUI. And any language that has the appropriate CLS compliance can use this form directly. 

go to top 

Various .NET Languages - VB.Net, ASP.NET, C#, J#, VC.NET

Sun intended to present JVM - as a single language virtual Machine. Meaning that only a Java program can be converted to a byte code (.class file) and then presented to JVM, which interprets the programs and runs it on the host machine. Although In concept, any language can be compiled to Java Byte code and then fed to JVM; but Sun did not encourage such approaches. Despite Sun's lack of initiative in this regard many researchers and companies have developed languages following this approach. Sun's vision of Java being "One language fits all" has both its advocates and its critics[5] 

With CLR, Microsoft has adopted a much liberal policy. Microsoft has themselves evolved/developed/modified many of their programming language to be compliant with .NET CLR. 

Although Visual C++ (VC++) , has undergone changes to incorporate .NET; yet VC++ also maintain its status as being a platform dependent programming. Many new MFC classes have been added; a programmer can choose between using MFC and compiling the program into a platform specific executable file; or using .NET framework classes and compile into platform independent MISL file. A programmer can also specify (via directives) when ever he uses "un-safe" (the code that by passes CLR - e.g. the use of pointers) code.

ASP, is another language that has been improved markedly. Most programmers know that ASP did not measure upto JSP; Microsoft has tried to turned the tables by introducing ASP.NET. ASP.NET makes extensive use of Web-Services. Web-Services is an open standard and JSP can use Web-services (Sun's official web site gives a detail on Web services and how that are being incorporated in Java platform). There are many other features that have been introduced in ASP.NET, to make it an ideal distributed programming tool and to measure up against JSP. ASP code within <% %> tag, is compiled into .NET Framework (similar to JSP code being compiled into a servlet). This approach is different than how the <% %> was handled in ASP ASP.NET has been enhanced by Microsoft. 

Out of ALL .NET languages, Visual Basic.NET (VB.NET) is one language that has probably undergone the most changes. Now VB.NET may be considered a complete Object-Oriented Language (as opposed to its previous "Half Object Based and Half Object Oriented" status). 

Microsoft has also developed a brand new programming language C# (C Sharp). This language makes full use of .NET. It is a pure object oriented language. A Java programmer may find most aspects of this language to be identical to Java. If you are a new comer to Microsoft Technologies - this language is the easiest way to get on the .NET band wagon. While VC++, and VB enthusiast would stick to VC.NET and VB.NET; they would probably increase their productivity by switching to C#. C# is developed to make full use of all the intricacies of .NET. The learning curve of C# for a Java programmer is minimal. Microsoft has also come up with a The Microsoft Java Language Conversion Assistant - which is a tool that automatically converts existing Java-language source code into C# for developers who want to move their existing applications to the Microsoft .NET Framework.

Microsoft has also developed J# (Java Sharp). C# may be similar to Java, but it is not entirely identical. It is for this reason that Microsoft has developed J# - the syntax of J# is identical to Visual J++. Microsoft's growing legal battle with Sun over Visual J++ - forced Microsoft to discontinue Visual J++. So J# is Microsoft's indirect continuation of Visual J++. It has been reported that porting a medium sized Visual J++ project, entirely to J# takes only a few days of effort. 

Microsoft encourages third party vendors to make use of Visual Studio.Net (launched on Feb 13, 2002). Third party vendors can write compilers for different languages - that compile the language to MSIL (Microsoft Intermediate Language). These vendors need not develop their own development environment. They can easily use Visual Studio.NET as an IDE for their .NET compliant language. A vendor has already produced COBOL.NET that integrates with Visual Studio.NET and compiles into MSIL[3]. Theoretically it would then be possible to come up with Java compiler that compiles into MSIL instead of Java Byte code; and uses CLR instead of JVM. However Microsoft has not pursued this due to possible legal action by Sun.

go to top 

What has future in store for us ?

Although the Beta of Visual Studio.Net has been around for over two years; it was officially launched on Feb 13, 2002. The future of .NET is very promising. With .NET Microsoft has diverged from their age-old philosophy of "proprietorship". Microsoft has always been coming up with good tools - which unfortunately have used proprietary technologies. One reason of unpopularity of DNA, COM, DCOM was that they were all based on proprietary Microsoft binary format. Microsoft has learned from its mistakes; .NET has a foundation of ASCII based XML. Microsoft submitted C#, and CLI for standardization to ECMA which on December 13, 2001, ratified the C# and Common Language Infrastructure (CLI) specifications into international standards. The ECMA standards will be known as ECMA-334 (C#) and ECMA-335 (the CLI). There is also a technical report on the CLI which will be known as ECMA TR84. In addition, ECMA approved the fast-track motion of these specifications to ISO. This is a huge step toward the Microsoft .NET Framework being widely accepted by the industry.

As of now, CLR is only available on Windows platform. .NET can only challenge Java, when the CLR becomes available for other platforms. Corel is working on a "Port Project" - that aims to port .NET framework to LINUX. Another company by the name of XIMIAN is also working on a similar project named - "Mono". With third party projects like these - we would soon have .NET versions for various non-Windows platforms.

In future we would probably see J2EE and .NET chasing each other with no single technology ever being able to replace the other. Historically Microsoft platform is considered  inappropriate for enterprise solutions - whereas it is considered perfect tool for standalone applications. Java platform on the other hand, has always been considered suitable for Enterprise applications, and has been considered slow and at times inefficient for standalone applications. With the healthy competition between Java and .NET we would probably see much better application platforms. As a programmer - we stand to loose nothing. Whether .NET gains more acceptance than J2EE or vice versa - the programming aspects remain the same. Whether you program in C# or, Java or J# - the syntax (essentially) remain the same - and with the similarity between the .NET and Java framework classes it would take an average programmer only a month or so to switch from one to another. 

It is the author's opinion that .NET should be treated as a valuable addition to a programmer's toolbox. In .NET we have another tool at our disposal, how we use it, and when we use it is subject to our discretion. 

go to top

References:

 The author would love to hear your comments/suggestions/criticisms regarding this article. Products and technology names used in this article are registered trademarks of the respective developers/owners.

License

This article has no explicit license attached to it but may contain usage terms in the article text or the download files themselves. If in doubt please contact the author via the discussion board below.

A list of licenses authors might use can be found here

Share

About the Author

Kashif Manzoor
Web Developer
United Kingdom United Kingdom
I have 8 years of industry experience and am currently pursuing my graduate studies at University of Illinois at Urbana Champaign.

Comments and Discussions

 
SuggestionMessage Automatically Removed PinmemberAyesha Sharma27-Mar-14 0:29 
Generalgood Pinmemberyasser salehabadi27-Feb-11 19:52 
It's a good article
GeneralGood!!! Pinmembersidbaruah3-Jul-07 2:58 
GeneralGreat PinmemberPankaj Paul15-Jun-07 23:16 
GeneralThanks for the article....But!! PinmemberMutyala Rao1-Jan-05 0:01 
GeneralMicrosoft Just too keen to be monopolistic Pinmemberdibur8-Nov-04 8:19 
GeneralRe: Microsoft Just too keen to be monopolistic PinmemberKashif Manzoor8-Nov-04 16:17 
GeneralRe: Microsoft Just too keen to be monopolistic Pinmemberdibur10-Nov-04 9:17 
GeneralRe: Microsoft Just too keen to be monopolistic PinmemberKashif Manzoor11-Nov-04 5:30 
GeneralRe: Microsoft Just too keen to be monopolistic PinsussAnonymous13-Nov-04 8:23 
GeneralRe: Microsoft Just too keen to be monopolistic PinmemberKashif Manzoor14-Nov-04 23:29 
Generalgood article PinsussAnonymous2-Mar-04 10:00 
Generalvb.net component tutorial help Pinmembersiobi10-Feb-04 16:47 
GeneralExcellent Article summarising .NET PinsussAnonymous6-Dec-03 9:24 
GeneralVery good article Pinsussmalkrish22-Jul-03 3:06 
GeneralRe: Very good article PinsussAnonymous24-Dec-03 2:18 
GeneralAutomation Server using VB.NET Pinsussde fender14-Nov-02 5:39 
General.Net For Masochists PinsussDestroyer11-Sep-02 18:04 
GeneralRe: .Net For Masochists PinmemberEvilDoctorSmith17-Nov-02 20:22 
GeneralQuestion on Automation. Pinsussbanfah9-Sep-02 1:06 
GeneralAbout Article PinmemberPrakash C S5-Jul-02 23:49 
GeneralThanks for the article Pinmembervaithsr13-Jun-02 15:41 
QuestionIs MSVC++ dead? PinmemberThe_B21-May-02 1:04 
AnswerRe: Is MSVC++ dead? PinmemberKashif Manzoor21-May-02 3:58 
GeneralRe: Is MSVC++ dead? Pinmembervaithsr14-Jun-02 8:42 

General General    News News    Suggestion Suggestion    Question Question    Bug Bug    Answer Answer    Joke Joke    Rant Rant    Admin Admin   

Use Ctrl+Left/Right to switch messages, Ctrl+Up/Down to switch threads, Ctrl+Shift+Left/Right to switch pages.

| Advertise | Privacy | Terms of Use | Mobile
Web03 | 2.8.1411023.1 | Last Updated 14 Feb 2002
Article Copyright 2002 by Kashif Manzoor
Everything else Copyright © CodeProject, 1999-2014
Layout: fixed | fluid