Beruflich Dokumente
Kultur Dokumente
NET
ASP.NET is more than the next version of Active Server Pages (ASP); it
provides a unified Web development model that includes the services
necessary for developers to build enterprise-class Web applications. While
ASP.NET is largely syntax compatible with ASP, it also provides a new
programming model and infrastructure for more scalable and stable
applications that help provide greater protection. You can feel free to
augment your existing ASP applications by incrementally adding ASP.NET
functionality to them.
Developers can use Web Forms or XML Web services when creating an
ASP.NET application, or combine these in any way they see fit. Each is
supported by the same infrastructure that allows you to use authentication
schemes, cache frequently used data, or customize your application's
configuration, to name only a few possibilities.
• Web Forms allow you to build powerful forms-based Web pages.
When building these pages, you can use ASP.NET server controls to
create common UI elements, and program them for common tasks.
These controls allow you to rapidly build a Web Form out of reusable
built-in or custom components, simplifying the code of a page. For
more information, see Web Forms Pages. For information on how to
develop ASP.NET server controls, see Developing ASP.NET Server
Controls.
• An XML Web service provides the means to access server
functionality remotely. Using XML Web services, businesses can
expose programmatic interfaces to their data or business logic, which
in turn can be obtained and manipulated by client and server
applications. XML Web services enable the exchange of data in
client-server or server-server scenarios, using standards like HTTP
and XML messaging to move data across firewalls. XML Web
services are not tied to a particular component technology or object-
calling convention. As a result, programs written in any language,
using any component model, and running on any operating system can
access XML Web services. For more information, see XML Web
Services Created Using ASP.NET and XML Web Service Clients.
Each of these models can take full advantage of all ASP.NET features, as well as the power of
the .NET Framework and .NET Framework common language runtime. These features and how
you can use them are outlined as follows:
• If you have ASP development skills, the new ASP.NET programming model will seem
very familiar to you. However, the ASP.NET object model has changed significantly
from ASP, making it more structured and object-oriented. Unfortunately this means
that ASP.NET is not fully backward compatible; almost all existing ASP pages will have
to be modified to some extent in order to run under ASP.NET. In addition, major
changes to Visual Basic .NET mean that existing ASP pages written with Visual Basic
Scripting Edition typically will not port directly to ASP.NET. In most cases, though, the
necessary changes will involve only a few lines of code. For more information, see
Migrating from ASP to ASP.NET.
• ASP.NET provides a simple model that enables Web developers to write logic that runs
at the application level. Developers can write this code in the Global.asax text file or in
a compiled class deployed as an assembly. This logic can include application-level
events, but developers can easily extend this model to suit the needs of their Web
application. For more information, see ASP.NET Applications.
• ASP.NET provides easy-to-use application and session-state facilities that are familiar
to ASP developers and are readily compatible with all other .NET Framework APIs. For
more information, see ASP.NET State Management.
• For advanced developers who want to use APIs as powerful as the ISAPI programming
interfaces that were included with previous versions of ASP, ASP.NET offers the
IHttpHandler and IHttpModule interfaces. Implementing the IHttpHandler interface
gives you a means of interacting with the low-level request and response services of
the IIS Web server and provides functionality much like ISAPI extensions, but with a
simpler programming model. Implementing the IHttpModule interface allows you to
include custom events that participate in every request made to your application. For
more information, see HTTP Runtime Support.
• Writing custom debug statements to your Web page can help immensely in
troubleshooting your application's code. However, they can cause embarrassment if
they are not removed. The problem is that removing the debug statements from your
pages when your application is ready to be ported to a production server can require
significant effort. ASP.NET offers the TraceContext class, which allows you to write
custom debug statements to your pages as you develop them. They appear only when
you have enabled tracing for a page or entire application. Enabling tracing also
appends details about a request to the page, or, if you so specify, to a custom trace
viewer that is stored in the root directory of your application. For more information,
see ASP.NET Trace.
• The .NET Framework and ASP.NET provide default authorization and authentication
schemes for Web applications. You can easily remove, add to, or replace these
schemes, depending upon the needs of your application. For more information, see
Securing ASP.NET Web Applications.
• ASP.NET configuration settings are stored in XML-based files, which are human
readable and writable. Each of your applications can have a distinct configuration file
and you can extend the configuration scheme to suit your requirements. For more
information, see ASP.NET Configuration.
• Applications are said to be running side by side when they are installed on the same
computer but use different versions of the .NET Framework. To learn how to use
different versions of ASP.NET for separate applications on your server, see Side-by-
Side Support in ASP.NET.
• IIS 6.0 uses a new process model called worker process isolation mode, which is
different from the process model used in previous versions of IIS. ASP.NET uses this
process model by default when running on Windows Server 2003. For information
about how to migrate ASP.NET process model settings to worker process isolation
mode, see IIS 6.0 Application Isolation Modes.
History of Asp.net
History of ASP.NET Web Application Development
• In order to understand why there are different types of Web
applications, a brief history lesson in
Visual Studio .NET is required.
• Visual Studio.NET 2002/2003 required the developer to use Internet
Information Server (IIS) when
building ASP.NET projects.
• Typically, IIS was installed on the local development machine. Front
Page Server Extensions (FPSE)
had to be installed on IIS in order for Visual Studio to create and modify
Web sites.
• Creating a new Web application project involved creating a new IIS
virtual directory, which the IDE
would create at the root of an IIS Web site.
• You could also optionally connect to an existing IIS virtual directory
by creating a new “empty Web
project”.
• This dependency on IIS was problematic in many situations:
• Many IT shops preferred not to deploy IIS to workstations in the
enterprise because it is a security
risk to expose many unnecessary IIS Web servers.
• If there was a mismatch between the project declaration and the IIS
configuration on the local machine,
the project would simply fail to load.
• Every time a code-behind file was changed, the entire Web project had
to be recompiled and its
Dynamic Link Library (DLL) had to be redeployed to the /bin/ folder on the
Web server.
• Some IT shops required all developers to use one installation of IIS on
a dedicated server that all
developers had to share, which required developers to “take turns” attaching
to the IIS process to debug the
Web site!
• Acknowledging the problems above, Microsoft released Visual Studio
2005 with ASP.NET 2.0.
• Microsoft altered the development architecture by changing Visual
Studio “Web Application Projects”
to Visual Studio “Web Sites”.
• A “Web Site” allows you to develop your Web site on a local file
directory – IIS does not even have to
be installed.
• A “Web Site” allows each Web page to be “Just in Time” (JIT)
compiled as they are requested.
Changes to a Web page do not require a complete recompilation and
deployment of the Web site!
• Web page requests were handled by a light weight development Web
server that shipped with ASP.
NET 2.0.
• The Web server (called WebDev.WebServer.exe) was automatically
started when you launched a new
debugging session in Visual Studio 2005.
• This lightweight server only handled a limited number of requests and
ran silently in the notification
area (tray).
• It automatically chose a port number that was unused on the local
machine.
Overview of XML
What Is XML?
Extensible Markup Language (XML) is a markup language used to describe the content
and structure of data in a document. It is a simplified version of Standard Generalized
Markup Language (SGML). XML is an industry standard for delivering content on the
Internet. Because it provides a facility to define new tags, XML is also extensible.
Like HTML, XML uses tags to describe content. However, rather than focusing on the
presentation of content, the tags in XML describe the meaning and hierarchical structure
of data. This functionality allows for the sophisticated data types that are required for
efficient data interchange between different programs and systems. Further, because
XML enables separation of content and presentation, the content, or data, is portable
across heterogeneous systems.
The XML syntax uses matching start and end tags (such as <name> and </name>) to mark
up information. Information delimited by tags is called an element. Every XML
document has a single root element, which is the top-level element that contains all the
other elements. Elements that are contained by other elements are often referred to as
sub-elements. An element can optionally have attributes, structured as name-value pairs,
that are part of the element and are used to further define it.
The following sample XML file describes the contents of an address book:
<?xml version="1.0"?>
<address_book>
<person gender="f">
<name>Jane Doe</name>
<address>
<street>123 Main St.</street>
<city>San Francisco</city>
<state>CA</state>
<zip>94117</zip>
</address>
<phone area_code=415>555-1212</phone>
</person>
<person gender="m">
<name>John Smith</name>
<phone area_code=510>555-1234</phone>
<email>johnsmith@somewhere.com</email>
</person>
</address_book>
The root element of the XML file is address_book. The address book currently contains
two entries in the form of person elements: Jane Doe and John Smith. Jane Doe's entry
includes her address and phone number; John Smith's includes his phone and email
address. Note that the structure of the XML document defines the phone element as
storing the area code using the area_code attribute rather than a sub-element in the body
of the element. Also note that not all sub-elements are required for the person element.
What's a Document?
The number of applications currently being developed that are based on, or make use of,
XML documents is truly amazing (particularly when you consider that XML is not yet a
year old)! For our purposes, the word "document" refers not only to traditional
documents, like this one, but also to the myriad of other XML "data formats". These
include vector graphics, e-commerce transactions, mathematical equations, object meta-
data, server APIs, and a thousand other kinds of structured information.
Why XML?
In order to appreciate XML, it is important to understand why it was created. XML was
created so that richly structured documents could be used over the web. The only viable
alternatives, HTML and SGML, are not practical for this purpose.
HTML, as we've already discussed, comes bound with a set of semantics and does not
provide arbitrary structure.
SGML provides arbitrary structure, but is too difficult to implement just for a web
browser. Full SGML systems solve large, complex problems that justify their expense.
Viewing structured documents sent over the web rarely carries such justification.
This is not to say that XML can be expected to completely replace SGML. While XML is
being designed to deliver structured content over the web, some of the very features it
lacks to make this practical, make SGML a more satisfactory solution for the creation and
long-time storage of complex documents. In many organizations, filtering SGML to
XML will be the standard procedure for web delivery.
XML Development Goals
The XML specification sets out the following goals for XML: [Section 1.1] (In this
article, citations of the form [Section 1.1], these are references to the W3C
Recommendation Extensible Markup Language (XML) 1.0. If you are interested in more
technical detail about a particular topic, please consult the specification)
1. It shall be straightforward to use XML over the Internet. Users must be able to
view XML documents as quickly and easily as HTML documents. In practice,
this will only be possible when XML browsers are as robust and widely available
as HTML browsers, but the principle remains.
2. XML shall support a wide variety of applications. XML should be beneficial to a
wide variety of diverse applications: authoring, browsing, content analysis, etc.
Although the initial focus is on serving structured documents over the web, it is
not meant to narrowly define XML.
3. XML shall be compatible with SGML. Most of the people involved in the XML
effort come from organizations that have a large, in some cases staggering,
amount of material in SGML. XML was designed pragmatically, to be compatible
with existing standards while solving the relatively new problem of sending richly
structured documents over the web.
4. It shall be easy to write programs that process XML documents. The colloquial
way of expressing this goal while the spec was being developed was that it ought
to take about two weeks for a competent computer science graduate student to
build a program that can process XML documents.
5. The number of optional features in XML is to be kept to an absolute minimum,
ideally zero. Optional features inevitably raise compatibility problems when users
want to share documents and sometimes lead to confusion and frustration.
6. XML documents should be human-legible and reasonably clear. If you don't have
an XML browser and you've received a hunk of XML from somewhere, you
ought to be able to look at it in your favorite text editor and actually figure out
what the content means.
7. The XML design should be prepared quickly. Standards efforts are notoriously
slow. XML was needed immediately and was developed as quickly as possible.
8. The design of XML shall be formal and concise. In many ways a corollary to rule
4, it essentially means that XML must be expressed in EBNF and must be
amenable to modern compiler tools and techniques.
There are a number of technical reasons why the SGML grammar cannot be
expressed in EBNF. Writing a proper SGML parser requires handling a variety of
rarely used and difficult to parse language features. XML does not.
9. XML documents shall be easy to create. Although there will eventually be
sophisticated editors to create and edit XML content, they won't appear
immediately. In the interim, it must be possible to create XML documents in other
ways: directly in a text editor, with simple shell and Perl scripts, etc.
10. Terseness in XML markup is of minimal importance. Several SGML language
features were designed to minimize the amount of typing required to manually
key in SGML documents. These features are not supported in XML. From an
abstract point of view, these documents are indistinguishable from their more
fully specified forms, but supporting these features adds a considerable burden to
the SGML parser (or the person writing it, anyway). In addition, most modern
editors offer better facilities to define shortcuts when entering text.
Like HTML, XML makes use of tags (words bracketed by '<' and
'>') and attributes (of the form name="value"). While HTML specifies what each
tag and attribute means, and often how the text between them will look in a
browser, XML uses the tags only to delimit pieces of data, and leaves the
interpretation of the data completely to the application that reads it. In other
words, if you see "<p>" in an XML file, do not assume it is a paragraph.
Depending on the context, it may be a price, a parameter, a person, a p... (and
who says it has to be a word with a "p"?).
Since XML is a text format and it uses tags to delimit the data, XML
files are nearly always larger than comparable binary formats. That was a
conscious decision by the designers of XML. The advantages of a text format are
evident (see point 3), and the disadvantages can usually be compensated at a
different level. Disk space is less expensive than it used to be, and compression
programs like zip and gzip can compress files very well and very fast. In addition,
communication protocols such as modem protocols and HTTP/1.1, the core
protocol of the Web, can compress data on the fly, saving bandwidth as
effectively as a binary format.
5. XML is a family of technologies
8. XML is modular
What is XML?
XML is extensible
The tags used to markup HTML documents and the structure of HTML documents are predefined. The
author of HTML documents can only use tags that are defined in the HTML standard.
XML allows the author to define his own tags and his own document structure.
XML is a complement to HTML
It is important to understand that XML is not a replacement for HTML. In the future development of the
Web it is most likely that XML will be used to structure and describe the Web data, while HTML will be used
to format and display the same data.
<?xml version="1.0"?>
The next line defines the first element of the document (the root element):
<note>
The next lines defines 4 child elements of the root (to, from, heading, and body):
<to>Tove</to>
<from>Jani</from>
<heading>Reminder</heading>
<body>Don't forget me this weekend!</body>
The last line defines the end of the root element:
</note>
<p>This is a paragraph
<p>This is another paragraph
In XML all elements must have a closing tag like this:
<p>This is a paragraph</p>
<p>This is another paragraph</p>
<Message>This is incorrect</message>
<message>This is correct</message>
<root>
<child>
<subchild>
</subchild>
</child>
</root>
<?xml version="1.0"?>
<note date="12/11/99">
<to>Tove</to>
<from>Jani</from>
<heading>Reminder</heading>
<body>Don't forget me this weekend!</body>
</note>
XML Attributes
XML attributes are normally used to describe XML elements, or to provide additional information about
elements. From HTML you can remember this construct: <IMG SRC="computer.gif">. In this HTML example
SRC is an attribute to the IMG element. The SRC attribute provides additional information about the
element.
Attributes are always contained within the start tag of an element. Here are some examples:
HTML examples:
<img src="computer.gif">
<a href="demo.asp">
XML examples:
<file type="gif">
<person id="3344">
Usually, or most common, attributes are used to provide information that is not a part of the content of the
XML document. Did you understand that? Here is another way to express that: Often attribute data is more
important to the XML parser than to the reader. Did you understand it now? Anyway, in the example above,
the person id is a counter value that is irrelevant to the reader, but important to software that wants to
manipulate the person element.
<person sex="female">
<firstname>Anna</firstname>
<lastname>Smith</lastname>
</person>
<person>
<sex>female</sex>
<firstname>Anna</firstname>
<lastname>Smith</lastname>
</person>
In the first example sex is an attribute. In the last example sex is an element. Both examples provides the
same information to the reader.
There are no fixed rules about when to use attributes to describe data, and when to use elements. My
experience is however; that attributes are handy in HTML, but in XML you should try to avoid them, as long
as the same information can be expressed using elements.
Here is another example, demonstrating how elements can be used instead of attributes. The following three
XML documents contain exactly the same information. A date attribute is used in the first, a date element is
used in the second, and an expanded date element is used in the third:
<?xml version="1.0"?>
<note date="12/11/99">
<to>Tove</to>
<from>Jani</from>
<heading>Reminder</heading>
<body>Don't forget me this weekend!</body>
</note>
<?xml version="1.0"?>
<note>
<date>12/11/99</date>
<to>Tove</to>
<from>Jani</from>
<heading>Reminder</heading>
<body>Don't forget me this weekend!</body>
</note>
<?xml version="1.0"?>
<note>
<date>
<day>12</day>
<month>11</month>
<year>99</year>
</date>
<to>Tove</to>
<from>Jani</from>
<heading>Reminder</heading>
<body>Don't forget me this weekend!</body>
</note>
If you start using attributes as containers for XML data, you might end up with documents that are both
difficult to maintain and to manipulate. What I'm trying to say is that you should use elements to describe
your data. Use attributes only to provide information that is not relevant to the reader. Please don't end up
like this:
<?xml version="1.0"?>
<note day="12" month="11" year="99"
to="Tove" from="Jani" heading="Reminder"
body="Don't forget me this weekend!">
</note>
This don't look much like XML. Got the point?
<?xml version="1.0"?>
<messages>
<note ID="501">
<to>Tove</to>
<from>Jani</from>
<heading>Reminder</heading>
<body>Don't forget me this weekend!</body>
</note>
<note ID="502">
<to>Jani</to>
<from>Tove</from>
<heading>Re: Reminder</heading>
<body>I will not!</body>
</note>
</messages>
The ID in these examples is just a counter, or a unique identifier, to identify the different notes in the XML
file.
<?xml version="1.0"?>
<note>
<to>Tove</to>
<from>Jani</from>
<heading>Reminder</heading>
<body>Don't forget me this weekend!</body>
</note>
The purpose of a DTD is to define the legal building blocks of an XML document. It defines the document
structure with a list of legal elements. A DTD can be declared inline in your XML document, or as an external
reference.
Internal DTD
This is an XML document with a Document Type Definition: (Open it in IE5, and select view source)
<?xml version="1.0"?>
<!DOCTYPE note [
<!ELEMENT note (to,from,heading,body)>
<!ELEMENT to (#PCDATA)>
<!ELEMENT from (#PCDATA)>
<!ELEMENT heading (#PCDATA)>
<!ELEMENT body (#PCDATA)>
]>
<note>
<to>Tove</to>
<from>Jani</from>
<heading>Reminder</heading>
<body>Don't forget me this weekend!</body>
</note>
The DTD is interpreted like this:
!ELEMENT note (in line 2) defines the element "note" as having four elements: "to,from,heading,body".
!ELEMENT to (in line 3) defines the "to" element to be of the type "CDATA".
!ELEMENT from (in line 4) defines the "from" element to be of the type "CDATA"
and so on.....
External DTD
This is the same XML document with an external DTD: (Open it in IE5, and select view source)
<?xml version="1.0"?>
<!DOCTYPE note SYSTEM "note.dtd">
<note>
<to>Tove</to>
<from>Jani</from>
<heading>Reminder</heading>
<body>Don't forget me this weekend!</body>
</note>
This is a copy of the file "note.dtd" containing the Document Type Definition:
<?xml version="1.0"?>
<!ELEMENT note (to,from,heading,body)>
<!ELEMENT to (#PCDATA)>
<!ELEMENT from (#PCDATA)>
<!ELEMENT heading (#PCDATA)>
<!ELEMENT body (#PCDATA)>
• Web publishing: XML allows you to create interactive pages, allows the
customer to customize those pages, and makes creating e-commerce applications
more intuitive. With XML, you store the data once and then render that content
for different viewers or devices based on style sheet processing using an
Extensible Style Language (XSL)/XSL Transformation (XSLT) processor.
• Web searching and automating Web tasks: XML defines the type of
information contained in a document, making it easier to return useful results
when searching the Web:
For example, using HTML to search for books authored by Tom Brown is likely
to return instances of the term 'brown' outside of the context of author. Using
XML restricts the search to the proper context (for example, the information
contained in the <author> tag) and returns only the desired type of information.
By using XML, Web agents and robots (programs that automate Web searches or
other tasks) are more efficient and produce more useful results.
Elements
Elements are the main building blocks of both XML and HTML documents.
Examples of HTML elements are "body" and "table". Examples of XML elements could be "note" and
"message". Elements can contain text, other elements, or be empty. Examples of empty HTML elements are
"hr", "br" and "img".
Tags
Tags are used to markup elements.
A starting tag like <element_name> mark up the beginning of an element, and an ending tag like
</element_name> mark up the end of an element.
Examples:
A body element: <body>body text in between</body>.
A message element: <message>some message in between</message>
Attributes
Attributes provide extra information about elements.
Attributes are placed inside the start tag of an element. Attributes come in name/value pairs. The following
"img" element has an additional information about a source file:
PCDATA
PCDATA means parsed character data.
Think of character data as the text found between the start tag and the end tag of an XML element.
PCDATA is text that will be parsed by a parser. Tags inside the text will be treated as markup and entities
will be expanded.
CDATA
CDATA also means character data.
CDATA is text that will NOT be parsed by a parser. Tags inside the text will NOT be treated as markup and
entities will not be expanded.
Entities
Entities as variables used to define common text. Entity references are references to entities.
Most of you will known the HTML entity reference: " " that is used to insert an extra space in an
HTML document. Entities are expanded when a document is parsed by an XML parser.
The following entities are predefined in XML:
Entity References Character
< <
> >
& &
" "
' '