My home on the web - featuring my real-life persona!

Discuss why the data types are the same across languages in the MSIL.

The data types in the different languages in the Microsoft Intermediate Language (MSIL) to provide compatibility. In .NET, various languages can be used but in the end they have to be able to interface with each other. The .NET compiler compiles the languages into MSIL and it can only do this without problems since the data types are the same. It would be incredibly difficult if each language had its own data types or its own definitions of data types. A string for example is a “group” of characters or digits and every program understands it as such. Now imagine another programming language would define a string only as a group of characters and not consider digits and a combination of characters and digits would be called a word, then the VB string cisp238 would be considered a word in the other languages and the .NET compiler would have to examine all strings to see if they need to be converted to be compatible.

I found a real world examples: In VB.NET, the data type Long is a 64-bit number while in VB6 it was a 32-bit number. So, it would require a lot of care to bring those two languages together and every time one languages uses a data type Long you would have to exactly specify what it means. The rules for the different .NET languages are specified in the Common Language Specification (CLS).

I found an interesting link about how different languages define the primitive data type Boolean: http://en.wikipedia.org/wiki/Boolean_datatype which is a good example of the advantages of uniform data type definitions.

It also seems like MSIL is the great “equalizer”. People used to have arguments about the speed of different programming languages, or better the speed of the applications coded in those languages. The argument was that C++ was faster than VB but in .NET everything is going through the MSIL and that determines the speed.

Compare the HTML Server controls to Web controls (ASP.NET controls).

As I pointed out in the answer to the first question, HTML server controls are HTML controls with the runat attribute set to “server”. They are an easy way to create server-side code when you already know HTML. Unfortunately, since they are based on HTML their abilities are still limited.

Web controls are more advanced and they are not based on HTML anymore but on the Web control class. Some of the Web controls look like old style HTML controls but there are additional controls that include new functions. Web controls have several other advantages, for example they are able to determine the browser client agent. In HTML, you had to figure out a way to be compatible with one browser without breaking the code for another browser. Web controls are able to render their functionality automatically depending on the client agent.

Most Web controls can also fully use themes and templates to match the controls to the look and feel determined by CSS.

Compare the benefits of using HTML Server controls with using HTML controls.

HTML controls are part of the HTML language. You can use and address them in client-side scripting but not from the server side.

From what I understand, almost every HTML control can be converted to a server control by using the <runat=”server”> tag in the HTML code on your ASPX code which signals the server that this control is server-side. On page load, the server control generates the code for the control and sends it to the browser.

HTML server controls have the advantage of retaining status (viewstate) - that means, the server knows if the checkbox is checked or not and if an option is selected or not. This is particularly helpful if you refresh a pages or go back to it. A regular HTML control would be reset to the state in the HTML code. An HTML server control on the other hand checks with the server and the server will tell the page, that the user had selected option B and that the name entered in the text field was Susanne. With an HTML server control, the code for the control and the code behind is executed on the server but it can interact with client-side code.

HTML server controls seem to be the in-between step between old-fashioned HTML controls which don’t do much and are purely client-side and fancier Web controls or ASP.NET controls. The resemble HTML controls and make the transition from a static HTML page to a server driven ASP page easier. ASP.NET controls are not based on HTML anymore and are basically a new programming language that you have to learn.

What do we mean by postback? What is it good for?

In ASP, the predecessor of our ASP.NET version, transmitting and processing data was a lot more cumbersome. If a user entered data, the data had to be passed with POST or GET through one or more interim pages for validation and processing before it could be used. Of course, everytime the data is “touched”, errors can be introduced (think of the children’s game “Telephone”).

In ASP.NET, this has become much easier. Instead of running the controls on the client side, they are run right on the server. The server then posts the data back to itself for validation and processing - and that’s where the name comes from.

The postback function is a function that is automatically generated and included on our HTML page by the ASP.NET engine. In order for this to work correctly, the of the web page needs to include a server-side form that specifies the action to “runat” the “server”.