An Architectural Introduction to Web
Parts and ASP.NET
A Microsoft® Office FrontPage® 2003 White Paper
This white paper discusses the technology behind Web Parts. The paper begins by discussing
ASP.NET and describes the fundamentals of a Web Forms page. This discussion segues into
a high-level overview of building a Web Part using Visual Studio.NET 2003 including mention
of the interfaces that a Web Part needs to expose in order to be connectable to other Web
Parts.
Note: The instructions, screenshots, and behavior discussed in this white paper are based
on Microsoft Internet Explorer version 5.5 or above. The user experience with prior
versions of Microsoft Internet Explorer and with other browsers is going to be different – in
general, the same level of features may not be available.
The examples in this white paper assume that Windows SharePoint Services is installed
on a server named myserver1024. This server also has Microsoft SQL Server with the
Northwind sample database installed on it
Requires a familiarity with the basics of C# language and the .NET framework.
Published: November 2003
For the latest information, please see http://www.microsoft.com/url/
Contents
Introduction .................................................................................................................................1
Web Part Framework ..................................................................................................................2
What Are Web Parts? ............................................................................................................2
Web Parts and Windows SharePoint Services .....................................................................2
Composition of a Web Part....................................................................................................3
Brief Overview of ASP.NET ........................................................................................................4
ASP.NET Web Applications ..................................................................................................4
Web Forms Pages and Server Controls ................................................................................4
ASP.NET Custom Controls....................................................................................................7
Creating Custom Web Parts .....................................................................................................11
Installing the Web Part Library Template ............................................................................11
Creating and Deploying Web Part .......................................................................................12
Example: A Sample Web Part .............................................................................................12
Creating a Web Part Description File (dwp) ........................................................................14
Deploying the Web Part .......................................................................................................15
Deploying in a Windows SharePoint Services Library ....................................................15
Importing the Web Part into a Specific Page..................................................................16
Using the Web Part in FrontPage 2003 ...............................................................................16
Conclusion (Style = Heading 1).................................................................................................21
References ................................................................................................................................21
Introduction
The Web Part Framework in Windows SharePoint Services provides a powerful and easy to
use platform for developing data driven web sites. Microsoft FrontPage 2003 integrates closely
with Windows SharePoint Services and is the easiest and the most powerful web site design
tool that enables creation of a new category of collaborative, scalable, data driven web sites.
The Web Part Framework in Windows SharePoint Services is used by three categories of
users:

End users personalize a Web Part Page to simplify and focus on the information that is
most relevant to them. They do this by customizing web part properties

Web Page Authors use Web Parts to build custom solutions based on Windows
SharePoint Services.

.NET developers extend Windows SharePoint Services by encapsulating web services
and enterprise data as Web Parts.
The goal of this document is to enable Web Page Authors to make more efficient use of the
Web Part Framework by illustrating how .NET developers write Web Parts.
An Architectural Introduction to Web Parts and ASP.NET
1
Web Part Framework
The Web Part Framework is the basis for extensibility in Windows SharePoint Services. It
allows developers to write custom components that plug into the SharePoint infrastructure by
encapsulating web services and enterprise data as Web Parts.
Windows SharePoint Services as a whole is based heavily on .NET technologies:

ASP.NET instead of ISAPI for base page execution

CLR based server object model for programmatic access to SharePoint data

XML Web services-based access of SharePoint data from remote machines
In keeping with this investment in .NET technologies, the Web Parts Framework is also based
entirely on ASP.NET:

Web Part pages are ASP.NET pages.

Web Parts are ASP.NET custom controls.
The fundamental notion in the Web Part Framework is that of a Web Part Page. A Web Part
Page is essentially a scalable version of the Digital Dashboard. It is a container of Web Parts.
A Web Part Page uses Windows SharePoint Services to store per-user views of the page,
which enables powerful customizations on a user-by-user basis.
What Are Web Parts?
Web Parts are customizable plug and play components that empower information workers to
create personalized user interfaces by simply dragging and dropping them onto a web page.
Web parts allow customization at both design time and at run time. In fact, Web Parts blur the
distinction between design time and run time:

Web page authors use FrontPage 2003 to work with Web Parts by dragging and dropping
them to a Web Part Page, and then customizing them using the developer enabled
properties. In this sense, Web Parts are similar to design time controls.

Web Parts also enable web page authors to use the browser as their authoring platform.
Windows SharePoint Services provides a browser-based interface to design a SharePoint
based site.

The end user can customize a Web Part Page at run time by modifying the properties of
each individual web part. The page author can designate which web parts can be
customized or not by grouping them into “zones” and setting the appropriate properties on
the zone using FrontPage 2003.
From the point of view of a developer, a web part is simply a specialized ASP.NET server
control. To create a new Web Part, you create an ASP.NET custom control. However, unlike
standard ASP.NET controls, which developers add to Web form pages at design time, Web
Parts are intended to be added to Web Part Pages either by authors at design time, or by
users at run time.
Note: Developers can also use Web Parts in “regular” ASP.NET pages, but in doing so,
the developer loses the advantages of integration with Windows SharePoint Services.
Web Parts and Windows SharePoint Services
Web Parts rely heavily on Windows SharePoint Services to support:
An Architectural Introduction to Web Parts and ASP.NET
2

Creation of new sites and new pages

Management of the user roster for a site

Storage of Web Part customizations, including shared and personal property settings

Administration of site backups and storage limits

A scalable architecture that can handle thousands of sites and millions of users

Assignment of users to customizable site groups
In turn, SharePoint Products and Technologies rely on Web Parts to provide configurable and
extensible user interfaces.
Composition of a Web Part
A Web Part is composed of the following entities:

The Web Part description file (.dwp) is a portable container of default and personalized
property values for the Web Part.

The Web Part assembly file (.dll) contains the logic and code for the Web Part, and is
installed on the server running Windows SharePoint Services.

Resource files that support the Web Part; these are also stored on the server.

Tables in the Windows SharePoint Services database are used to store current values of
the Web Part properties.
Windows SharePoint Services has been designed from the ground-up to be a powerful
collaborative platform. It is possible and indeed commonplace for your web site to contain
multiple instances of the same Web Part. Each instance would conceivably have a different
set of properties.
Regardless of the number of instances of the Web Part, there is only one Web Part assembly
file. Any instance-specific customizations are stored in the .dwp file and there exist as many
.dwp files for a Web Part as there are instances of that part.
An Architectural Introduction to Web Parts and ASP.NET
3
Brief Overview of ASP.NET
As we noted in the Introduction, the Web Part infrastructure is based on .NET technologies,
specifically ASP.NET. Web Parts themselves are specialized ASP.NET custom controls and
they reside on a Web Part Page, which is a specialized ASP.NET web forms page.
For readers that may not be familiar with these technologies, this section gives a very brief
overview the main concepts. The reader should refer to many excellent books and articles on
this topic.
ASP.NET Web Applications
ASP.NET is part of the .NET Framework and is the core technology for developing web
applications and XML Web Services. ASP.NET pages run on the server and generate markup
such as HTML, WML, or XML that is sent to a desktop or mobile browser. ASP.NET pages
use a compiled, event-driven programming model that improves performance and enables
separating the application logic and user interface. ASP.NET pages and ASP.NET XML Web
services files contain server-side logic (as opposed to client-side logic) written in Visual Basic
.NET, C# .NET, or any .NET-compatible language. Web applications and XML Web services
take advantage of the features of the common language runtime, such as type safety,
inheritance, language interoperability, versioning, and integrated security.
An ASP.NET web application is defined as all files, pages, handlers, modules, and executable
code that you can invoke or run in the scope of a given virtual directory (and its subdirectories)
on an IIS server. Typical ASP.NET applications consist of the following:

One or more web forms pages – which are text files with an .aspx extension. These pages
typically consist of HTML markup which declares the controls on the page and specifies
their formatting and layout attributes.

One or more code files; you can developed in develop code C#, Visual Basic, J#, Jscript,
etc. The code files contain the web application’s logic, including control event handling,
postback handling, etc. The code files are tightly bound to the aspx files and are referred
to as “code behind”.

A Global.asx file to deal with session and application startup and clean-up logic. This file is
optional.

A Web.config file used to store configuration settings. This file is optional, and is new for
ASP.NET
Web Forms Pages and Server Controls
Let’s look at a web forms page in more detail. In doing so, we will gain an understanding of
ASP.NET server controls and code behind files.
Note This section provides a walkthrough for building an ASP.NET web application so that the
reader can gain an understanding of the platform technologies that form the basis for web part
pages. However, it is not possible to run arbitrary ASP.NET code within a web part page;
specifically, you cannot insert the code presented in this section inside a web part page.
Web forms are ASP.NET pages which use ASP.NET server controls. Server controls are a set
of built-in controls which are similar to Microsoft Visual Basic controls – essentially, prewritten
pieces of code which you can drag and drop into your application. Just like Visual Basic
controls, ASP.NET server controls are event driven; the developer’s task is to write code that
An Architectural Introduction to Web Parts and ASP.NET
4
handles events raised by the controls. This code appears in the code-behind file of the
corresponding aspx file.
ASP.NET provides two sets of built-in server controls:

HTML controls, which provide a 1-1 mapping to HTML elements

Web controls, which provide prepackaged UI functionality such as text boxes, data grids,
labels, etc. In addition, a class of Web controls, called Validation controls, are used to
validate user input on a form (usually avoiding a round-trip to the server)
Let us now examine a sample web application. Below is a screenshot of the application:
The user types his name into the text box and clicks on the button labeled ClickMe. The
application displays the text: “Hello World! This is <name>”.
Apart from the configuration files (global.asx, web.config), this application consists of 2 main
files: Webform1.aspx – which is the web forms file, and WebForm1.aspx.cs, which is the code
behind file.
Shown below is the WebForm1.aspx file:
File WebForm1.aspx
1. <%@ Page language="c#" Codebehind="WebForm1.aspx.cs"
AutoEventWireup="false" Inherits="TestWebApp.WebForm1" %>
2. <!DOCTYPE HTML PUBLIC "-//W3C//DTD HTML 4.0 Transitional//EN" >
3. <HTML>
4. <HEAD>
5. <title>WebForm1</title>
6.
<meta name="GENERATOR" Content="Microsoft Visual Studio .NET
7.1">
An Architectural Introduction to Web Parts and ASP.NET
5
7.
8.
9.
10.
11.
12.
13.
14.
15.
16.
17.
18.
19.
20.
21.
22.
23.
24.
<meta name="CODE_LANGUAGE" Content="C#">
<meta name="vs_defaultClientScript" content="JavaScript">
<meta name="vs_targetSchema"
content="http://schemas.microsoft.com/intellisense/ie5">
</HEAD>
<body MS_POSITIONING="GridLayout">
<form id="Form1" method="post" runat="server">
<asp:TextBox id="TextBox1" style="Z-INDEX: 101; LEFT: 192px;
POSITION: absolute; TOP: 72px" runat="server">
</asp:TextBox>
<asp:Label id="Label1" style="Z-INDEX: 102; LEFT: 128px;
POSITION: absolute; TOP: 72px" runat="server">
Name
</asp:Label>
<asp:Button id="Button1" style="Z-INDEX: 103; LEFT: 224px;
POSITION: absolute; TOP: 120px" runat="server"
Text="ClickMe">
</asp:Button>
<asp:Label id="Label2" style="Z-INDEX: 104; LEFT: 120px;
POSITION: absolute; TOP: 184px" runat="server"
Width="272px">
</asp:Label>
</form>
</body>
</HTML>
This form is strictly markup and no code. All the code required for processing the form
appears in a separate file, called the “code-behind” file. This is one of the major innovations in
ASP.NET; it separates the presentation from the logic, thus solving one of the major problems
with ASP – ASP code was hard to maintain because it was interspersed with HTML markup.

Line 1 identifies the code behind file to be webform1.aspx.cs. With this directive, the
framework knows where to look for when it needs event handlers to process the aspx file.

Line 12 begins the <form> tag, but with the runat attribute set to “server”.

Lines 13, 15, 18, and 20 declare the Web controls used on this page. They are,
respectively, a text box, a label, a button, and another label.
For each control, its id is declared, as are some style and layout parameters.
Shown below is the Code-Behind file for this form:
File: WebForm1.aspx.cs
1.
2.
3.
4.
5.
6.
7.
8.
9.
10.
using
using
using
using
using
using
using
using
using
using
System;
System.Collections;
System.ComponentModel;
System.Data;
System.Drawing;
System.Web;
System.Web.SessionState;
System.Web.UI;
System.Web.UI.WebControls;
System.Web.UI.HtmlControls;
11. namespace TestWebApp
12. {
13. public class WebForm1 : System.Web.UI.Page
14. {
An Architectural Introduction to Web Parts and ASP.NET
6
15.
16.
17.
18.
protected
protected
protected
protected
System.Web.UI.WebControls.TextBox TextBox1;
System.Web.UI.WebControls.Label Label1;
System.Web.UI.WebControls.Button Button1;
System.Web.UI.WebControls.Label Label2;
19.
20.
21.
22.
private void Page_Load(object sender, System.EventArgs e)
{
// Put user code to initialize the page here
}
23.
24.
25.
26.
27.
override protected void OnInit(EventArgs e)
{
InitializeComponent();
base.OnInit(e);
}
28.
29.
30.
31.
32.
33.
private void InitializeComponent()
{
this.Button1.Click += new
System.EventHandler(this.Button1_Click);
this.Load += new System.EventHandler(this.Page_Load);
}
34.
private void Button1_Click(object sender, System.EventArgs e)
35.
{
36.
string Temp;
37.
Temp = "Hello World!" + "This is " + TextBox1.Text;
38.
Label2.Text = Temp;
39.
}
40. }
41. }
The form is represented by the class WebForm1, which is derived from the Page class in the
System.Web.UI namespace. The “Inherits” of the @Page directive (in line 1 of
WebForm1.aspx file) establishes the binding between WebFrom1 class and the aspx page.

Lines 15 – 18 declares the controls used in the form.
Note that from the perspective of code, these server controls are simply C# classes; these
classes appear in the System.Web.UI.WebControls namespace.

Lines 28 – 33 declares the WebForms1::InitializeComponent method to add a new event
handler for handling “click” events on Button1.

Line 33 adds another event handler for the Load event for this page.

Lines 34 – 39 declares the Button1_Click() method that contains the real logic in our web
application. This method builds the output string by taking the text from TextBox1 inline 38
and setting this string to be the text of Label2. Since Button1_Click() method has been
designated as the event handler for the “click” event on Button1 in line 32, this code gets
invoked when the user clicks the button.
ASP.NET Custom Controls
The ASP.NET server control infrastructure essentially provides a code-reuse mechanism. It
enables the writing of reusable UI entities which you can incorporate in a page. At runtime, the
control provides ASP.NET with HTML describing its appearance.
ASP.NET ships with a rich library of server controls. These controls address the needs of
many common web design tasks. Rich as the control library is, there are still cases where a
An Architectural Introduction to Web Parts and ASP.NET
7
web developer is unable to find a control that precisely suits her purposes. It is desirable
therefore, there be a way to create custom, reusable UI objects that developers can use in
Web Forms.
To address such situations, ASP.NET provides the ability to write your own controls. They fall
into two broad categories:

User Controls provide a simple and fast method for reusing your presentation code. They
are simply HTML or ASP.NET code saved in a file with an .ascx extension. However, you
cannot directly call a user control (as .aspx pages can). You have to include them within
an aspx page. User controls can contain almost any element that a web forms page can
contain. User controls are an evolution of Server Side Includes (SSI) in ASP.

Custom Controls are .NET components which can produce HTML to render themselves
in Web Forms.
This section will focus on the Custom Controls. This is because a Web Part is an ASP.NET
custom control.
An ASP.NET server control is a class that derives directly or indirectly from
System.Web.UI.Control. The following two classes are the base classes for ASP.NET server
controls:

System.Web.UI.Control: This class defines the properties, methods, and events common
to all ASP.NET server controls. It does not have any user interface (UI) specific features.

System.Web.UI.WebControls.WebControl: This class derives from Control and provides
additional properties and methods for UI functionality (such as ForeColor, BackColor,
Font, BorderStyle, etc). In fact, most of the built in ASP.Net server controls derive from
this class.
Shown below is the code for a simple ASP.NET custom control.
1.
2.
3.
4.
using
using
using
using
System;
System.Web.UI;
System.Web.UI.WebControls;
System.ComponentModel;
5. namespace MyCustomControls
6. {
7.
[DefaultProperty("Greeting"),
ToolboxData("<{0}:ComputerName
runat=server></{0}:ComputerName>")]
8.
public class ComputerName : System.Web.UI.WebControls.WebControl
9.
{
10.
private string _Greeting;
11.
[Bindable(true),
Category("Appearance"), DefaultValue("")]
12.
public string Greeting
13.
{
14.
get
15.
{
16.
return _Greeting;
17.
}
18.
set
19.
{
20.
_Greeting = value;
21.
}
22.
}
23.
protected override void Render(HtmlTextWriter output)
24.
{
25.
output.Write("<font> "+ this.Greeting + "<br>" +
An Architectural Introduction to Web Parts and ASP.NET
8
"The name of this server is " +
System.Windows.Forms.SystemInformation.ComputerName
+
"</font>");
26.
}
27.
}
28. }
The name of the control is “ComputerName”; this control has one property, called Greeting.
The control gets the name of the server and appends it to the Greeting, and produces HTML
to display this text. For example, if the server name is “MyServer” and Greeting is set to the
string “Hello”, then it produces the text: “Hello. The name of this server is MyServer”

Line 5 declares the namespace, “MyCustomControls”. Every control (indeed, every .NET
component) belongs to a namespace.

Line 7 defines the design-time and run-time metadata for the control, required for (among
other things) displaying the control at design time, data binding, displaying property
sheets, etc.

Line 8 declares the class named “ComputerName” for our control. A custom control is
implemented as a class. This class is typically derived from the WebControl class
provided by the framework.

Line 11 defines the properties for the control. At design time, the property sheet editor in
Visual Studio.net 2003 requires metadata for the property, such as its category, default
value, etc.

Lines 12 – 22 define the accessors for the Greeting property of our control.

Lines 23 – 26 declares the Render method (which is an overridden method of the
WebControl class) used to produce HTML.

Line 25 uses an HtmlTextWriter object called “output” to produce HTML tags. This method
takes the “Greeting” property and concatenates it with the ComputerName property of the
SystemInformation class and produces this string, along with some HTML tags.
Below is an aspx page that uses this control; since this control doesn’t expose any events,
there is no need for writing event handlers in the code-behind file.
1. <%@ Page language="c#" Codebehind="WebForm1.aspx.cs"
AutoEventWireup="false" Inherits="TestWebApp.WebForm1" %>
2. <%@ Register TagPrefix="cc1" Namespace="MyCustomControls"
Assembly="MyCustomControls" %>
3. <!DOCTYPE HTML PUBLIC "-//W3C//DTD HTML 4.0 Transitional//EN" >
4. <HTML>
5.
<HEAD>
6.
<title>WebForm1</title>
7.
<meta content="Microsoft Visual Studio .NET 7.1"
name="GENERATOR">
8.
<meta content="C#" name="CODE_LANGUAGE">
9.
<meta content="JavaScript" name="vs_defaultClientScript">
10.
<meta content="http://schemas.microsoft.com/intellisense/ie5"
name="vs_targetSchema">
11. </HEAD>
12. <body MS_POSITIONING="GridLayout">
13.
<form id="Form1" method="post" runat="server">
14.
<cc1:ComputerName id="ComputerName1" style="Z-INDEX: 105;
LEFT: 160px; POSITION: absolute; TOP: 248px"
runat="server" Height="22px" Greeting="Welcome">
15.
</cc1:ComputerName></form>
An Architectural Introduction to Web Parts and ASP.NET
9
16. </body>
17. </HTML>

Line 2 uses the @Register directive. This contains the namespace and assembly name
for the custom control. It uses the TagPrefix attribute to prevent name collisions. For
instance, if somebody else creates a control whose name is also “ComputerName”, then
these two controls are distinguished by the different tag prefixes (such as cc1 and cc2).

Line 14 contains the markup for inserting the control into the page. The syntax and
semantics of this markup is the same for a custom control and a built-in control (see the
previous section for details).
When you run this page with the Greeting property set to “Welcome”, the output looks like this:
An Architectural Introduction to Web Parts and ASP.NET
10
Creating Custom Web Parts
As mentioned before in this document, Web Parts are ASP.NET custom controls. Microsoft
Visual Studio.net 2003 is an excellent environment for building and debugging ASP.NET
custom controls. Developers can use it for building Web Parts as well.
There are two project templates you can use when building a Web Part using Microsoft Visual
Studio.net 2003:

Use the Web Control Library project: This project template comes with Microsoft Visual
Studio.net 2003 which developers can use for building any ASP.NET controls, including
Web Parts.

Use the Web Part Library project: This project template is available as a free download
from Microsoft that is optimized for building Web Parts.
In the rest of this section, we will use the Web Part Library project template. There are several
advantages to using the Web Part Library template:

Automatically adds a reference to the Microsoft.SharePoint.dll file, which is the assembly
that contains the set of classes required to build Web Parts.

Creates a Web Part class file.

Creates a Web Part description (.dwp) file.

Creates a Web Part manifest file, which is an XML file containing metadata used by
stsadm.exe during the deployment of Web Parts.

Adds new instances of the above files to the project by a simple right click; you can also
add consumer and provider Web Part files and Tool Part files to the project.
Note: each of the above should be manually accomplished when using the Web Control
Library project.
Installing the Web Part Library Template
The Web Part Library template is available for download at
http://microsoft.com/downloads/details.aspx?FamilyId=14D5D92F-C3A6-407C-AAD7B8C41A4991BE&displaylang=en.
To add the Web Part Library template to your Microsoft Visual Studio.net 2003 installation,
follow these steps:
1. Download the Web Part Library templates and run the executable.
2. The Setup Wizard starts. Click Next to install the package.
3. Select the programming languages for which you want to install the templates and
then click Next.
4. In the text box provided, type the location of the Windows SharePoint Services
assembly in the file system and click Next.
5. The Confirm Installation page appears. Click Next to continue.
6. The Installation Complete page appears. Click Close to close the Setup Wizard.
An Architectural Introduction to Web Parts and ASP.NET
11
Creating and Deploying a Web Part
To create a basic Web Part, follow these steps:
1. Create a new project in Microsoft Visual Studio.net 2003 based on the Web Part
Library template.
2. Write code for the Web Part.
3. Strongly name the Web Part.
4. Create a Web Part description file (dwp).
5. Copy the Web Part assembly and the dwp file into the web application directory on the
machine running Windows SharePoint Services.
6. Identify the Web Part as a safe control.
7. Import the Web Part into a Web Part Page or put the Web Part into the virtual server
library.
The details of each of these steps are beyond the scope of this paper; we refer the reader to
the following white papers:

“A Developer’s Introduction To Web Parts”

“Packaging and Deploying Web Parts for Windows SharePoint Services”
Both are available for download at
http://msdn.microsoft.com/library/default.asp?url=/downloads/list/SharePoint.asp.
In this paper, we will examine the sample code for a simple Web Part and look at a dwp file
that will accompany it.
Example: A Sample Web Part
The following code illustrates a simple Web Part which has a text box and a button; when you
click on the button, the string in the text box is appended to the title of the Web Part.
1.
2.
3.
4.
5.
6.
7.
8.
9.
10.
using
using
using
using
using
using
using
using
using
using
System;
System.ComponentModel;
System.Web.UI;
System.Web.UI.WebControls;
System.Xml.Serialization;
Microsoft.SharePoint;
Microsoft.SharePoint.Utilities;
Microsoft.SharePoint.WebPartPages;
System.Web.UI.HtmlControls;
System.Runtime.InteropServices;
11. namespace WebPartLibrary1
12. {
13.
[DefaultProperty("Text"),
ToolboxData("<{0}:WebPart1 runat=server></{0}:WebPart1>"),
XmlRoot(Namespace="WebPartLibrary1")]
14.
public class WebPart1 :
Microsoft.SharePoint.WebPartPages.WebPart
15.
{
16.
private const string defaultText = "New Web Part";
17.
private string text=defaultText;
18.
19.
20.
// declare HTML controls used by this web part
HtmlButton _myButton;
HtmlInputText _myTextBox;
An Architectural Introduction to Web Parts and ASP.NET
12
21.
// Event handler for _myButton control; it gets the string in
// the text box & appends it to the custom property "Text" &
// sets this as the title of the web part
public void _myButton_Click (object sender, EventArgs e)
{
this.Title = _myTextBox.Value + "'s " + this.Text;
}
22.
23.
24.
25.
26.
27.
28.
29.
30.
31.
32.
33.
34.
35.
36.
37.
[Browsable(true),Category("Miscellaneous"),
DefaultValue(defaultText),
WebPartStorage(Storage.Personal),
FriendlyName("Text"),Description("Text Property")]
public string Text
{
get
{
return text;
}
set
{
text = value;
}
}
38.
39.
40.
41.
42.
43.
44.
45.
46.
47.
48.
49.
// override Web.UI.Controls.CreateChildControls method
protected override void CreateChildControls()
{
// create _myButton control and add event handler
_myButton = new HtmlButton();
_myButton.InnerText = "Add your Name to title";
_myButton.ServerClick += new EventHandler(_myButton_Click);
Controls.Add(_myButton);
_myTextBox = new HtmlInputText();
_myTextBox.Value = "";
Controls.Add(_myTextBox);
}
50.
51.
52.
53.
54.
55.
56.
}
57. }
/// Render this Web Part to the output parameter specified.
protected override void RenderWebPart(HtmlTextWriter output)
{
_myTextBox.RenderControl(output);
_myButton.RenderControl(output);
}
You may notice that this code looks like the code shown for ASP.NET the custom control in a
previous section. This should come as no surprise because Web Parts are ASP.NET custom
controls.
However, there exist several differences.
The first is in Line 14:

The Web Part class derives from Microsoft.SharePoint.WebPartPages.WebPart class, as
opposed to a stock ASP.NET control, which derives from one of System.Web.UI.Control
or System.Web.UI.WebControls.WebControl.
An Architectural Introduction to Web Parts and ASP.NET
13

However, the WebPart class itself derives from System.Web.UI.Control class and this is
what ties a Web Part into the entire ASP.NET control infrastructure. To the features of a
stock ASP.NET control, the Web Part class adds the following:

Creates the title bar, border etc., around the control, which users can customize by
setting properties and applying themes.

Handles interactions with the WebPartPage and WebPartZone classes to support
adding, moving, hiding, deleting, connecting, and personalizing Web Parts on a page.
This is what “plugs” a Web Part into the Windows SharePoint Services infrastructure.

Provides a set of common properties such as Title, Height, Width, FrameState, etc.
The second difference is in Line 51.

When rendering an ASP.NET control, you typically override the Render method of the
base class; however, the WebPart class has sealed the Render method. Developers
should override the special RenderWebPart method provided by the WebPart class.
The rest of the code show above is straightforward ASP.NET control code:

Lines 19 and 20 create HTML text controls used in this web part (an input text and a
button control)

Lines 21 - 25 define the event handler for the button click event. This handler simply takes
the value in the text box, appends this to the value of the custom property called “Text”,
and sets this as the new title. Thus if the Text Property is “New Web Part” and the string
“Ralph” is typed in the input text box, then the button click will set the new title of the Web
Part to “Ralph’s New Web Part”.

Lines 26 - 37 define the accessors for the Text custom property.

In lines 38 - 49, we override the CreateChildControls method of the base class to
initialize the controls in this Web Part. The controls are added to the collection of child
controls for this Web Part class. Also, we add the click event handler defined in lines 2125 to the HtmlButton’s ServerClick event.
Rendering the Web Part at Design Time
FrontPage 2003 provides a design time preview of Web Parts on a Web Part Page at design
time. The developer can exercise precise control over this design time rendering. This is done
by implementing the IDesignTimeHtmlProvider interface in the Web Part. This interface has
a single method, called GetDesignTimeHtml, which returns the HTML string used to render
the Web Part. Design tools such as FrontPage 2003 which leverage Windows SharePoint
Services, check to see if this interface is implemented; if it is, then they call the
GetDesignTimeHtml method for rendering. Otherwise, they use the default rendering for that
Web Part.
Creating a Web Part Description File (dwp)
The Windows SharePoint Services infrastructure uses the Web Part description file which
contains metadata about the Web Part.
Shown below is the dwp file for the Web Part created in the previous section:
1.
2.
3.
4.
5.
<?xml version="1.0" encoding="utf-8"?>
<WebPart xmlns="http://schemas.microsoft.com/WebPart/v2" >
<Title>New Web Part</Title>
<Description>WebPart1.</Description>
<Assembly>WebPartLibrary1, Version=1.0.0.0, Culture=Neutral,
An Architectural Introduction to Web Parts and ASP.NET
14
6.
7.
PublicKeyToken=334fd085a590fb9f</Assembly>
<TypeName>WebPartLibrary1.WebPart1</TypeName>
</WebPart>
As you can see, the dwp is an XML file. The root element of this file is the <WebPart>
element, and it contains, among others, the following tags:

<Title> specifies the default title of the Web Part

<Description> specifies the pop up description for the Web Part which FrontPage 2003
and the browser displays.

<Assembly> specifies the name of the assembly that contains the implementation for this
Web Part.

<TypeName> specifies the class within the assembly which implements the Web Part.
This is required because an assembly can implement more than one Web Part and/or
other ASP.NET controls. Notice how the value of the TypeName tag corresponds to the
namespace declaration (line 11) and class declaration (line 14) shown in the previous
section.
Note You can export dwp files in FrontPage 2003, using Tools/Save Web Part to/File…
Deploying the Web Part
You can deploy a Web Part in two different ways:

Place it in one of the Windows SharePoint Services Web Part Libraries – the virtual server
library, site library, or the online library. This makes it available to all pages in the site.

Import it into a specific page. This makes the Web Part available only to that page and it
will not appear in any gallery.
Deploying in a Windows SharePoint Services Library
Before deploying the Web Part into a Windows SharePoint Services Library, you must build a
Web Part Package. A Web Part Package is a cabinet (.cab) file that contains the following
items:

Manifest.xml

.dwp files
Note: When using the Web Part Library template for Microsoft Visual Studio.net
2003, it automatically creates the manifest.xml and dwp files for you.

Web Part assemblies: one or more .NET assemblies and are the result of building your
Web Part Library solution

Class resource files contain bitmaps and other resources required for your Web Part.
The details of the structure of manifest.xml, and the modalities of building a CAB file are
outside the scope of this paper. For details, please see the white paper entitled “Packaging
and Deploying Web Parts for Microsoft Windows SharePoint Services” at
http://msdn.microsoft.com/library/default.asp?url=/library/enus/dnspts/html/SharePoint_DeployingWebParts.asp.
Once you have a CAB file, you can use the stsadm.exe tool on the server running Windows
SharePoint Services to add the Web Part to the virtual server library. The typical command
line for using stsadm.exe to add a Web Part looks like below:
stsadm.exe –o addwppack –filename path_to_CAB_file
An Architectural Introduction to Web Parts and ASP.NET
15
The stsadm.exe tool is typically available in
<drive>:\Program Files\Common Files\Microsoft Shared\web server extensions\60\BIN
For more details on using stsadm.exe tool, see the “Packaging and Deploying Web Parts for
Microsoft Windows SharePoint Services” white paper referenced above.
Using the stsadm.exe tool deploys the Web Part into the virtual server library and you can use
with FrontPage 2003 or the Web Browser interface. You can make any Web Part in the virtual
server library available in the site library. For more details on managing Web Parts in these
libraries, see “FrontPage 2003: Working with Web Part Libraries”.
Importing the Web Part into a Specific Page
You can also simply import a Web Part onto a page. The process of import does not add the
Web Part to the Virtual, Site, or Online libraries; it is just available on a given page. Before you
can import a Web Part onto a page, you must perform the following tasks on the machine
running Windows SharePoint Services:
1. Copy the Web Part assembly to the <drive>:\inetpub\wwwroot\bin folder.
2. Register the Web Part as a safe control. Do this by editing the web.config file, located
in the <drive>:\inetpub\wwwroot folder. For our sample Web Part, this involves adding
the following lines under the <configuration>/<SharePoint>/<SafeControls> block:
<SafeControl Assembly="WebPartLibrary1, Version=1.0.0.0,
Culture=Neutral, PublicKeyToken=334fd085a590fb9f"
Namespace="WebPartLibrary1" TypeName="*" Safe="True" />
3. Make the dwp file for the Web Part available for the users that want to import this Web
Part.
Assuming these steps are performed, the Web Part can be imported onto a page using
FrontPage 2003 using the following steps:
1. Bring up the Web Parts task pane: View/Taskpane and select “Web Parts” from the
dropdown list of available task panes.
2. Under Add Web Parts, click Import.
3. Browse to or type in the location of the .dwp file for the Web Part you want to import.
4. Click “Upload”. The Web Part now appears on the task pane.
You can now drag and drop the part onto the page.
Using the Web Part in FrontPage 2003
In this section, we will assume that our sample Web Part is available in the Virtual Server
Library of the Windows SharePoint Services installation.
Using this Web Part is no different from using any other Web Part. To use a Web Part, follow
these steps:
1. Open the site you wish to work with in FrontPage 2003. For the purposes of this
section, we will assume the site is located at the URL: http://myserver/my-workgroup.
2. Click on Data/Insert Web Parts to open the Web Parts taskpane in FrontPage 2003.
3. Click on Virtual Server Gallery to display the available Web Parts. You should see
the sample Web Part available there; its title is New Web Part.
Below is a screenshot of the task pane:
An Architectural Introduction to Web Parts and ASP.NET
16
4. Drag and drop this Web Part into an appropriate zone in your web page. For the
purposes of illustration, let us assume that we have dragged the Web Part into the
default.aspx page of a Windows SharePoint Services site created using the Team
Site template.
5. Save the page and run it in the browser by typing the appropriate URL. We have used
the URL http://myserver/default.aspx.
6. Locate the Web Part you just added (it should be titled “New Web Part”).
7. Type your name in the text box, and click on Add your Name to title button. The title
will change to (assuming the name you typed was Murali) “Murali’s New Web Part”.
Below is a screenshot of this:
An Architectural Introduction to Web Parts and ASP.NET
17
Recall that this Web Part has a custom property called Text. Refer to the Web Part code in
“Example: A Sample Web Part”.
Note the following:

Line 22 – 25 specifies that the event handler for the button click event on the Add your
Name to title button take the value of the Text property, append it to the string typed in
the text field, and set this as the value of the title.

Lines 26 – 37 implements the custom property and specifies that this property has to be
put under the category “Miscellaneous”.
To manipulate this property in FrontPage 2003, follow these steps:
1. In the Web Part properties dialog box, notice the new category called Miscellaneous.
Expanding this category shows a property called Text and a text box to enter the
value for it. FrontPage 2003 automatically displays a text box to enter the value of this
property because the data type of this property is string (line 27 of the code in
“Example: A Sample Web Part”)
2. Type “Fancy Web Part” as the new value of this property.
3. In FrontPage 2003, right click on our example Web Part and select Web Part
Properties in the pop-up menu.
Below is a screenshot of how this should look:
An Architectural Introduction to Web Parts and ASP.NET
18
4. Click OK, save changes and run the page in the browser by typing the appropriate
URL. We have used the URL http://myserver/default.aspx.
5. Locate our example Web Part (it title should be “New Web Part”).
6. Type your name in the text box, and click on Add your Name to title button. The title
will change to (assuming that the name you typed was Murali) “Murali’s Fancy Web
Part”.
Below is a screenshot of this:
Note By default, the custom properties you create and specify as browsable are automatically
displayed in the default property pane, making their use transparent to the user. If the default
property pane isn't rich enough in functionality, you can create a custom user interface called a
ToolPart to manipulate your custom properties. For information on creating a ToolPart, see the
http://msdn.microsoft.com/library/default.asp?url=/library/enAn Architectural Introduction to Web Parts and ASP.NET
19
us/spptsdk/html/CreateWPCustomProperties.asp.
An Architectural Introduction to Web Parts and ASP.NET
20
Conclusion
ASP.NET is part of the .NET Framework and is the core technology for developing web
applications and XML Web Services. ASP.NET is a compiled, .NET-based environment; you
can author applications in any .NET compatible language, including Visual Basic .NET, C#,
and JScript .NET. Additionally, the entire .NET Framework is available to any ASP.NET
application. Developers can easily access the benefits of these technologies, which include
the managed common language runtime environment, type safety, inheritance, and so on.
.NET developers write Web Parts using Visual Studio.NET 2003.
The Web Part Framework is the basis for extensibility in Windows SharePoint Services. It
allows developers to write custom components that plug into the SharePoint infrastructure by
encapsulating web services and enterprise data as Web Parts. Web Part Pages are special
ASP.NET pages which are the building blocks of a Windows SharePoint Services based data
driven web site. Web page authors can use Microsoft FrontPage 2003 to leverage Windows
SharePoint Services and use the Web Part Framework to easily build data driven web sites
using a library of readily available web parts. Microsoft FrontPage 2003 integrates closely with
Windows SharePoint Services and is the easiest and the most powerful web site design tool
that enables creation of a new category of collaborative, scalable, data driven web sites.
An Architectural Introduction to Web Parts and ASP.NET
21
References
FrontPage 2003: Overview of Web Parts Framework
FrontPage 2003: Working with Web Part Libraries
FrontPage 2003: Customizing Web Parts
FrontPage 2003: Connecting Web Parts
FrontPage 2003: Working with Web Part Pages
FrontPage 2003: Working with the Data View Web Part
Other Microsoft Resources
Microsoft FrontPage 2003 Customization Kit Web:
http://www.sharepointcustomization.com
Microsoft FrontPage Web site:
http://www.microsoft.com/frontpage/default.htm
Microsoft FrontPage Add-in Center:
http://www.microsoft.com/frontpage/downloads/addin/default.asp
Microsoft SharePoint Products and Technologies:
http://www.microsoft.com/sharepoint/default.asp
SharePoint Products and Technologies Web Component Directory:
http://www.microsoft.com/sharepoint/downloads/components/default.asp
An Architectural Introduction to Web Parts and ASP.NET
22
The information contained in this document represents the current view of Microsoft Corporation on the issues discussed as of the date
of publication. Because Microsoft must respond to changing market conditions, it should not be interpreted to be a commitment on the
part of Microsoft, and Microsoft cannot guarantee the accuracy of any information presented after the date of publication.
This white paper is for informational purposes only. MICROSOFT MAKES NO WARRANTIES, EXPRESS OR IMPLIED, IN THIS
DOCUMENT.
Complying with all applicable copyright laws is the responsibility of the user. Without limiting the rights under copyright, no part of this
document may be reproduced, stored in, or introduced into a retrieval system, or transmitted in any form or by any means (electronic,
mechanical, photocopying, recording, or otherwise), or for any purpose, without the express written permission of Microsoft Corporation.
Microsoft may have patents, patent applications, trademarks, copyrights, or other intellectual property rights covering subject matter in
this document. Except as expressly provided in any written license agreement from Microsoft, the furnishing of this document does not
give you any license to these patents, trademarks, copyrights, or other intellectual property.
© 2001 Microsoft Corporation. All rights reserved.
The example companies, organizations, products, domain names, e-mail addresses, logos, people, places, and events depicted herein
are fictitious. No association with any real company, organization, product, domain name, e-mail address, logo, person, place, or event
is intended or should be inferred.
Microsoft, FrontPage, and SharePoint are either registered trademarks or trademarks of Microsoft Corporation in the United States
and/or other countries.
An Architectural Introduction to Web Parts and ASP.NET
23