asp

NET pages, known officially as "web forms", are the main building block for application
development.[8] Web forms are contained in files with an ".aspx" extension; in
programming jargon, these files typically contain static (X)HTML markup, as well as
markup defining server-side Web Controls and User Controls where the developers place
all the required static and dynamic content for the web page. Additionally, dynamic code
which runs on the server can be placed in a page within a block <% -- dynamic code
-- %> which is similar to other web development technologies such as PHP, JSP, and
ASP, but this practice is generally discouraged except for the purposes of data binding
since it requires more calls when rendering the page

It is recommended by Microsoft for dealing with dynamic program code to use the code-
behind model, which places this code in a separate file or in a specially designated script
tag. Code-behind files typically have names like MyPage.aspx.cs or MyPage.aspx.vb
(same filename as the ASPX file, with the final extension denoting the page language).
This practice is automatic in Microsoft Visual Studio and other IDEs. When using this
style of programming, the developer writes code to respond to different events, like the
page being loaded, or a control being clicked, rather than a procedural walk through the
document.

ASP.NET's code-behind model marks a departure from Classic ASP in that it encourages
developers to build applications with separation of presentation and content in mind. In
theory, this would allow a web designer, for example, to focus on the design markup with
less potential for disturbing the programming code that drives it. This is similar to the
separation of the controller from the view in model-view-controller frameworks.

Application state

Application state is a collection of user-defined variables that are shared by an ASP.NET

application. These are set and initialized when the Application_OnStart event fires on
the loading of the first instance of the applications and are available till the last instance
exits. Application state variables are accessed using the Applications collection, which
provides a wrapper for the application state variables. Application state variables are
identified by names.

SqlServer Mode
In this mode, the state variables are stored in a database server, accessible using
SQL. Session variables can be persisted across ASP.NET process shutdowns in
this mode as well. The main advantage of this mode is it would allow the
application to balance load on a server cluster while sharing sessions between
servers. This is the slowest method of session state management in ASP.NET.
C# is the programming language that most directly reflects the underlying Common
Language Infrastructure (CLI). Most of its intrinsic types correspond to value-types
implemented by the CLI framework. However, the language specification does not state
the code generation requirements of the compiler: that is, it does not state that a C#
compiler must target a Common Language Runtime, or generate Common Intermediate
Language (CIL), or generate any other specific format. Theoretically, a C# compiler
could generate machine code like traditional compilers of C++ or FORTRAN. In practice,
all existing compiler implementations target CIL.

Some notable distinguishing features of C# are:

• There are no global variables or functions. All methods and members must be
declared within classes. Static members of public classes can substitute for global
variables and functions.
• Local variables cannot shadow variables of the enclosing block, unlike C and
C++. Variable shadowing is often considered confusing by C++ texts.
• C# supports a strict Boolean datatype, bool. Statements that take conditions, such
as while and if, require an expression of a boolean type. While C++ also has a
boolean type, it can be freely converted to and from integers, and expressions
such as if(a) require only that a is convertible to bool, allowing a to be an int, or
a pointer. C# disallows this "integer meaning true or false" approach on the
grounds that forcing programmers to use expressions that return exactly bool can
prevent certain types of programming mistakes such as if (a = b) (use of =
instead of ==).
• In C#, memory address pointers can only be used within blocks specifically
marked as unsafe, and programs with unsafe code need appropriate permissions to
run. Most object access is done through safe object references, which always
either point to a "live" object or have the well-defined null value; it is impossible
to obtain a reference to a "dead" object (one which has been garbage collected), or
to a random block of memory. An unsafe pointer can point to an instance of a
value-type, array, string, or a block of memory allocated on a stack. Code that is
not marked as unsafe can still store and manipulate pointers through the
System.IntPtr type, but it cannot dereference them.
• Managed memory cannot be explicitly freed; instead, it is automatically garbage
collected. Garbage collection addresses memory leaks by freeing the programmer
of responsibility for releasing memory which is no longer needed. C# also
provides direct support for deterministic finalization with the using statement
(supporting the Resource Acquisition Is Initialization idiom).
• Multiple inheritance is not supported, although a class can implement any number
of interfaces. This was a design decision by the language's lead architect to avoid
complication, avoid dependency hell and simplify architectural requirements
throughout CLI.
• C# is more typesafe than C++. The only implicit conversions by default are those
which are considered safe, such as widening of integers and conversion from a
 derived type to a base type. This is enforced at compile-time, during JIT, and, in
some cases, at runtime. There are no implicit conversions between booleans and
integers, nor between enumeration members and integers (except for literal 0,
which can be implicitly converted to any enumerated type). Any user-defined
conversion must be explicitly marked as explicit or implicit, unlike C++ copy
constructors and conversion operators, which are both implicit by default.
• Enumeration members are placed in their own scope.

Language Compatibility

Visual Basic and Visual Basic .NET are completely different languages and are not
backwards-compatible. Visual Basic .NET shares only syntax similarities with Visual
Basic. However some features of Visual Basic have been ported over to Visual Basic
.NET and are not available to other .NET languages.

C# shares syntax similarities with Java. Both C# and Visual Basic .NET share structural
similarities with other modern high level languages such as Java and C++. However the
differences between Java and .NET are numerous, as can be seen in Comparison of Java
and C Sharp.

[edit] Runtime multi-language support

One of the main goals of .NET has been its multi-language support. The intent of the
design was that all of the various Microsoft languages should have the same level of
access to all OS features, and should be able to expose the same level of power and
usability.

In implementation, all .NET programming languages share the same runtime engine,
uniform Abstract syntax tree, and Common Intermediate Language. Additionally all
.NET languages have access to platform features including garbage collection, cross
language inheritance, exception handling, and debugging. This allows the same output
binary to be produced from any .NET programming language.

[edit] Development environment

Visual Studio provides minor differences in the development environment for C# and
VB.Net. With each subsequent release of Visual Studio, the differences between
development environments for these languages have been reduced. For instance early
versions of Visual Studio had poor support for Intellisense in C# compared to Visual
Basic .NET, and did not offer background compilation for C#[1]. Currently, the main
differences in the development environments are additional features for Visual Basic
.NET that originated in VB6, including:

• The default namespace is hidden (but can be disabled)

• Certain project files are hidden (the user can show them)
• The auto-generated My.* namespaces contain many commonly-used shortcuts
brought over from VB6, such as methods for operating on the registry and
application configuration file

[edit] Background Compiler

Background compilation is a feature of the Visual Studio IDE whereby code is compiled
as it is written by the programmer with the purpose of identifying compilation errors
without requiring the solution to be built. This feature has been available for Visual Basic
since .NET 1.1 and was present in early versions of Visual Studio for Visual Basic .NET.
However, background compilation is a relatively new concept for Visual C# and is
available with service pack 1 for Visual Studio 2008 Standard Edition and above. A
distinct disadvantage for C# is that the Error List panel does not update until the solution
is rebuilt. Refactoring large projects is made more difficult by the need to frequently
rebuild the solution order to highlight compilation errors. Such is not the case with Visual
Basic because the Error List panel is synchronised with the background compiler.

Background Compilation is less demanding on system resources and results in faster

build cycles. This is a particular advantage with large projects and can significantly
reduce the time required to start debugging since the Intermediate Language code is
always ready to run.

[edit] Language features

The bulk of the differences between C# and VB.NET from a technical perspective are
syntactic sugar. That is, most of the features are in both languages, but some things are
easier to do in one language than another. Many of the differences between the two
languages are actually centered around the IDE.

[edit] Features of Visual Basic .NET not found in C#

• Variables can be declared using the WithEvents construct. This construct is

available so that a programmer may select an object from the Class Name drop
down list and then select a method from the Declarations drop down list to have
the Method signature automatically inserted
• Auto-wireup of events, VB.NET has the Handles syntax for events
• Support for optional variables (this will also be available in C# beginning in
version 4.0[2]). This is typically used to provide easy interoperability with native
code
• Marshalling an object for multiple actions using an unqualified dot reference. This
is done using the With ... End With structure
 • IsNumeric evaluates whether a string can be cast into a numeric value (the
equivalent for C# requires using int.TryParse)
• XML Literals[3]
• Inline date declarations by using #1/1/2000# syntax.

[edit] Features of C# not found in Visual Basic .NET

• Allows blocks of unsafe code (like C++/CLI) via the unsafe keyword
• Partial Interfaces
• Iterators and the yield keyword
• Multi-line comments (note that the Visual Studio IDE supports multi-line
commenting for Visual Basic .NET)
• Static classes (Classes which cannot contain any non-static members, although
VB's Modules are essentially sealed static classes with additional semantics)
• Can use checked and unchecked contexts for fine-grained control of
overflow/underflow checking
• Auto-Implemented Properties (as of C# 3.0[4])
• Implicitly Typed Arrays

[edit] Other characteristics of Visual Basic .NET not applicable to C#

• Conversion of Boolean value True to Integer may yield -1 or 1 depending on the

conversion used
• Assigning and comparing variables uses the same token, =. Whereas C# has
separate tokens, == for comparison and = to assign a value.
• VB.NET is case-insensitive.
• Type checking is less strict by default. If the default is left in place, It will auto
convert type without notifying programmer, for example:

Dim i As Integer = 1
Dim j As String = "1"
If i = j Then
MessageBox.Show("Bad comparison")
End If

It should be noted that changing this default (known as 'Option Strict') is widely
considered best practice for VB development.

[edit] Other characteristics of C# not applicable to Visual Basic .NET

• By default, numeric operations are not checked. This results in slightly faster
code, at the risk that numeric overflows will not be detected. However, the
programmer can place arithmetic operations into a checked context to activate
overflow checking.
• Addition and string concatenation use the same token, +. Whereas Visual Basic
.NET has separate tokens, + for addition, and & for concatenation.
 • In Visual Basic .NET property methods may take parameters
• C# is case-sensitive.
• C# does not allow optional parameters (this will be available in C# beginning in
version 4.0[2]).

[edit] Syntax comparisons

Visual Basic .NET terminates a block of code with End BlockName statements (or Next
statements, for a for loop) which are more familiar for programmers with experience
using T-SQL. In C#, the braces, {}, are use to delimit blocks, which is more familiar to
programmers with experience in other widely-deployed languages such as C++ and Java.
Additionally, in C# if a block consists of only a single statement, the braces may be
omitted.

C# is case sensitive while Visual Basic .NET is not. Thus in C# it is possible to have two
variables with the same name, for example variable1 and Variable1. Visual Studio
will correct the case of variables as they are typed in VB.NET. In many cases however,
case sensitivity can be useful. C# programmers typically capitalize type names and leave
member and variable names lowercase. This allows, for example, fairly natural naming of
method arguments: public int CalculateOrders(Customer customer). Of course,
this can cause problems for those converting C# code to a case-insensitive language, such
as Visual Basic, or to those unaccustomed to reading a case sensitive language.

[edit] Keywords

Keywords are very different between the two languages.

• Me vs this - a self-reference to the current object instance

• MyBase vs base - for referring to the base class from which the current class is
derived
• Shared vs static - for declaring methods that do not require an explicit instance
of an object
• NotInheritable vs sealed - for declaring classes that may not be inherited
• NotOverridable vs sealed - for declaring methods that may not be overridden
by derived classes
• MustInherit vs abstract - prevents a class from being directly instantiated, and
forces consumers to create object references to only derived classes
• MustOverride vs abstract - for forcing derived classes to override this method
• Overridable vs virtual - declares a method as being able to be overridden in
derived classes

Some C# keywords such as sealed represent different things when applied to methods as
opposed to when they are applied to class definitions. VB.NET, on the other hand, uses
different keywords for different contexts.