Inline ASP.Net Tags, Code Render Blocks... (<%$, <%=, <%, <%#, etc.)

Code render blocks define inline code or inline expressions that execute when the page is rendered. There are two styles of code render blocks: inline code and inline expressions.
Use inline expressions as a shortcut for calling the Write method.

<% inline code %>
<%=inline expression %>

thee tags are evaluated during the Render portion of the page load cycle.

• http://msdn.microsoft.com/en-us/library/k6xeyd4z.aspx
• http://msdn.microsoft.com/en-us/library/ms178472.aspx

<% ... %>

The most basic inline tag, basically runs normal code:

<% if (User.IsInRole("admin")) { %> 
You can see this 
<% } else { %> 
You are no admin fool! 
<%} %>

http://msdn2.microsoft.com/en-us/library/ms178135(vs.80).aspx

<%= ... %>

Used for small chunks of information, usually from objects and single pieces of information like a single string or int variable:

The Date is now <%= DateTime.Now.ToShortDateString() %>

The value of string1 is <%= string1 %>

http://msdn2.microsoft.com/en-us/library/6dwsdcf5(VS.71).aspx


*note: <%= is the equivalent of Response.Write().

<%# .. %>

Used for Binding Expressions; such as Eval and Bind, most often found in data controls like GridView, Repeater, etc.:

<asp:Repeater ID="rptMeetings" DataSourceID="meetings" runat="server"> 
<ItemTemplate> 
<%# Eval("MeetingName") %> 
</ItemTemplate> 
</asp:Repeater>

http://msdn2.microsoft.com/en-us/library/ms178366.aspx
<%$ ... %>
Used for expressions, not code; often seen with DataSources:

<asp:SqlDataSource ID="party" runat="server" ConnectionString="<%$ ConnectionStrings:letsParty %>" SelectCommand="SELECT * FROM [table]" />

http://msdn2.microsoft.com/en-us/library/d5bd1tad.aspx

<%@ ... %>

This is for directive syntax; basically the stuff you see at the top your your aspx pages like control registration and page declaration:

<%@ Page Language="C#" MasterPageFile="~/MasterPage.master"
AutoEventWireup="true" CodeFile="Default.aspx.cs" Inherits="_Default" Title="Untitled Page" %> 
<%@ Register TagPrefix="wp" Namespace="CustomWebParts" %>

http://msdn2.microsoft.com/en-us/library/xz702w3e(VS.80).aspx

<%-- ... --%>

This is a server side comment, stuff you don't want anyone without code access to see:

<asp:Label ID="lblAwesome" runat="server" /> 
<%-- sometimes end users make me angry --%> 
<asp:LinkButton ID="lbEdit" Text="Edit" OnClick="Edit_Click" runat="server" />

http://msdn2.microsoft.com/en-us/library/4acf8afk.aspx

What Is C#?

As part of the lineage of C-based languages, C# has incorporated and exploited programming language features with a proven record of success and familiarity. To that end, most syntactic features of C# are borrowed from C/C++, and most of its object-oriented concepts, such as garbage collection, reflection, the root class, and the multiple inheritance of interfaces, are inspired by Java. Improvements in C# over Java, often with syntax simplification, have been applied to iteration, properties, events, metadata, versioning, and the conversion between simple types and objects.

 

In addition to being syntactically familiar, C# is strongly typed, architecturally neutral, portable, safe, and multi-threaded. Type security in C# is supported in a number of ways, including initializing variables before their use, eliminating dangerous explicit type conversions, controlling the limits in arrays, and checking the overflow of type limits during arithmetic operations. Its architecturally neutral intermediate format, implemented as the Common Intermediate Language (CIL) and executed on a virtual machine, makes C# portable and independent aof its running environment.

C# is also safe. It controls access to hardware and memory resources, checks classes at runtime, and does not allow the implicit usage and manipulation of pointers (as C/C++ do). The explicit use of pointers, on the other hand, is restricted to sections of code that have been designated as unsafe. With the support of a garbage collector, frustrating memory leaks and dangling pointers are a non-issue. The C# language also supports multi-threading in order to promote efficient interactive applications such as graphics, input/output, and so on. Other modern features in C# include Just-in-Time (JIT) compilation from bytecode to native code, exceptions for error handling, namespaces for preventing type collisions, and documentation comments.

In order to promote the widespread use and acceptance of C#, Microsoft relinquished its proprietary rights. With the support of Hewlett-Packard and Intel, Microsoft quickly pushed for a standardized version of C#. In December 2001, the first standard was accepted by the European Computer Manufacturer Association (ECMA). The following December, a second standard was adopted by the ECMA, and it was accepted 3 months later by the International Organization for Standardization (ISO). The standardization of C# has three principal benefits:

1.      To support the portability of C# applications across different hardware architectures,

2.      To foster the development of C# compilers among different manufacturers, and

3.      To encourage the emergence of high-quality software tools to support the development of C# applications.

 

The .NET Virtual Machine: Common Language Runtime

The CLR is the .NET virtual machine. It handles the compiling, loading, and execution of a C# application. The compiling process employs a JIT approach that translates the CIL into machine code as required. In addition to a traditional runtime system, it also provides debugging and profiling functionalities. The CLR implements the CTS, which defines types and data. Moreover, C# applications contain a complete description of their types, called metadata, providing code visibility to other applications or tools. With this metadata, the CLR uses reflection in order to resolve library references, link components, and resolve types at runtime. The garbage collector is a subsystem of the CLR that cleans up memory that is no longer needed. It frees developers of the tedious and error-prone responsibility of recovering (deleting or deallocating) memory space allocated during object creation.

 

Intermediate Language -The .NET Virtual Code

The applications written in C# are not traditional Windows programs compiled into machine code. Rather, the C# compiler generates CIL code, often referred to as managed code. This code is dedicated to run safely within the .NET environment. In fact, the CLR takes care of the back-end part of the compilation before execution, allowing the possibility of JIT translation from CIL code into native machine code without compromising security. On the other hand, unmanaged code, such as that generated by C/C++ compilers in the Windows environment, uses native and potentially dangerous instructions (for example, pointers). Like Java bytecode, CIL is also virtual machine code and is therefore completely independent of any underlying processor architecture. It is fully cross-language compatible on the .NET platform, offering at the time of this writing support for many different programming languages. Therefore, all programs implemented in any of these languages and compiled into CIL may share components without any extra effort.

 

The .NET Assemblies: Applications and/or Components

An assembly is the logical unit of deployment in .NET and encompasses two kinds of implementation units: applications (.exe) and components (.dll). Whereas applications represent fully executable C# programs, components represent core reusable objects that provide basic services to build up applications. Indeed, Microsoft prefers to call C# a component-oriented rather than an object-oriented programming language.

Each assembly is either private or public and contains a manifest (a set of metadata)that provides information about its implementation units, such as name, owner, version, security permissions, culture, processor, operating system, public key signature, and all other needed resources (such as bitmaps). Private assemblies are used only by the application that installed them, but public (shared) assemblies are stored in a repository maintained by the .NET Framework called the Global Assembly Cache (GAC).

Finally, because every assembly contains version information, the CLR is able to handle multiple versions of the same component on the same platform.

 

.NET Framework?

The .NET Framework provides a new platform for building applications that are easily

deployed and executed across multiple architectures and operating systems. This portability

is achievable only because of ongoing standardization through the ECMA and ISO

organizations. In this way, the framework offers independence to languages by supplying

an international standard called the Common Language Infrastructure (CLI).

The framework was designed to be installed on top of an operating system and

is divided into two main layers, as shown in Figure 1.1: a runtime environment called

the Common Language Runtime (CLR), similar to the Java Virtual Machine, and a large

library of classes called the Framework Class Library (FCL), which provides the required

services for modern applications.
Applications Development Tools for C#, J#, C++, VB, …

The bottom layer of the .NET Framework contains the CLR. The CLR provides the

runtime services to execute C# programs that have been translated into the CIL. The top

layer encapsulates all services in the FCL for user interface, control, security, data access,

Extensible Markup Language (XML), input/output, threading, and so on. User interface

(UI) services—both Window and Web Forms—support graphic interfaces and server-side

controls, respectively. ASP.NET provides control, security, sessioning, and configuration

for dynamic web pages. Data access by ADO.NET adds XML as an intermediate format for

data and supports connections to datasets using XML caches. The FCL also contains system

classes to manage I/O, execution threads, serialization, reflection, networking, collections,

diagnostics, debugging, and so on.

Applications and development tools are typically layered on top of the .NET Framework.

Visual Studio .NET, in particular, is a good example. It provides an integrated development

environment (IDE) that standardizes support for many programming languages,

including C#, J#, C++, and Visual Basic.

After the standardization of the C# and CLI specifications in December 2001,

Microsoft released the CLR as both a commercial implementation of the CLI runtime

virtual machine and a subset of the FCL. Since then, C# has become the programming

language of choice for developing applications in the .NET Framework. CLR, FCL, and the

C# compiler are all released as part of the .NET Framework Software Development Kit

(SDK), which is freely available from Microsoft at http://msdn.microsoft.com. At the time

of this writing, there are other .NET implementations in progress, such as the open-source

Mono and DotGNU projects. All these implementations include a C# compiler that extends

language availability to platforms other than Windows.

The C# code executed on this framework follows object-oriented development practices

defined by the Common Language Specification (CLS). The CLS defines a collaboration

standard between languages and object development practices. Obviously, some older

traditional programming languages, such as COBOL and Fortran, cannot exploit the full

characteristics offered by the CLS. The Common Type System (CTS) of the .NET Framework

represents a standardized set of basic data types that permit language interoperability.

In other words, the CTS defines the rules implemented in the CLR. The CLS supports

a (common) subset of the CTS in order to allow cross-language integration. Therefore,

a CLS-compliant component can be used by applications written in other languages.

 

Declaring Partial Classes

Although declaring one class per source file is the best-practice policy in the software

industry, a class declaration may grow so large that it becomes unwieldy to store it in

a single file. In that case, the class is better divided among more than one file to ease

development, testing, and maintenance. Using the prefix partial before the class name,

different parts of a class can be distributed across different files. Two key restrictions,

however, must be satisfied. First, all parts of a partial type must be compiled together in

order to be merged at compile-time and second, already compiled types are not allowed

to be extended to include other partial types. As an example, the partial class Parser is

implemented in three separate files (parts) as shown here:

ParserCompilationUnit.cs file (Part 1):

public partial class Parser {

private ILexer lexer;

private IReportable errorReporter;

private ISymbolTable symbolTable;

// ...

// Compilation Unit productions

void ParseCompilationUnit() { ... }

void ParseNamespace() { ... }

// ...

}

ParserClass.cs file (Part 2):

public partial class Parser {

// Class productions

void ParseClassDecl() { ... }

void ParseClassMemberDecl() { ... }

// ...

}

ParserExpr.cs file (Part 3):

public partial class Parser {

// Expression productions

void ParseExpr() { ... }

void ParseExprList() { ... }

// ...

}

When the preceding files are compiled together, the resulting code is the same as if the

class had been written as a single source file Parser.cs:

public class Parser {

private ILexer lexer;

private IReportable errorReporter;

private ISymbolTable symbolTable;

// ...

// Compilation Unit productions

void ParseCompilationUnit() { ... }

void ParseNamespace() { ... }

// ...

// Class productions

void ParseClassDecl() { ... }

void ParseClassMemberDecl() { ... }

// ...

// Expression productions

void ParseExpr() { ... }

void ParseExprList() { ... }

// ...

}

The notion of partial classes also applies to other types, such as structures and interfaces.