Well-designed web parts function in a variety of different pages because they are configurable by an administrator or end user directly in the site. This configuration is possible because each web part supports a series of properties that can be set in the site and read by the web part at run time. In code, these properties are created in the same manner as any property for any class with the exception that they have special attributes that determine their behavior within SharePoint. The process of creating a property begins with a standard property construct.

Most properties are designed to be configured directly in the portal. Therefore, you must decorate the property with different attributes to define its behavior when a page is designed. These property values are subsequently serialized and saved when the page is processed so that the property values can be read later when an end user accesses the page. Each of the properties you define is decorated with the WebBrowsable, Personalizable, WebDisplayName, and WebDescription attributes.

The WebBrowsable attribute is a Boolean value that determines whether the built-in SharePoint property editing pane can access the property. You may set this value to either True or False. Although most of your properties will be browsable, you may have sensitive properties that should not be accessible by general users. Additionally, when you create a custom property editor later in the section titled "Custom Editor Parts," you will set this value to False.

The Personalizable attribute is an enumeration that determines whether the property values are saved for an individual or for all users of the page on which the web part sits. This attribute may be set to PersonalizationScope.User or PersonalizationScope.Shared. When the attribute is set to PersonalizationScope.User, the property value may be set for each user of a page. The web part infrastructure serializes and saves the values separately for each user. When the attribute is set to PersonalizationScope.Shared, the web part infrastructure saves only a single value of the property that is applied to all users of the page on which the web part sits.

Once you understand the property definition scheme, you can create as many as you need to properly configure the web part. Although they are easy to change, I recommend that you spend some time designing your web part before implementing the property set. If you think through the intended use of the web part, you will save yourself a lot of wasted time writing and rewriting property structures. Listing 10-2 shows a complete property definition for a database connections string that can be set by a user and then utilized by the web part.

[Personalizable(PersonalizationScope.Shared),WebBrowsable(true),
WebDisplayName("Connection String"),
WebDescription("The connection string for the database")]
public string Connection
{
  get{return m_connection;}
  set{m_connection=value;}
}

Because the WebPart class inherits from System.Web.UI.Control, the entire user interface for a web part must be created through code. Although you can make use of ASP.NET controls in your web part, there is no drag-and-drop design capability in Visual Studio. This approach is definitely a drawback and can slow your ability to create web parts. Be that as it may, it becomes less of an issue once you have created a few web parts and learned the techniques for generating the user interface.

Properly rendering a web part requires that you first create any ASP.NET controls that you will need in code. The required ASP.NET controls are then added to the controls collection of the web part by overriding the CreateChildControls method of the base class. Finally, you can draw the output by overriding the RenderContents method. You may use any available ASP.NET control found in Visual Studio .NET or any ASP.NET control you have written to create the user interface for a web part. Remember though that these controls cannot be dragged onto a page. Instead, they must be declared in code. When you declare ASP.NET controls in code, be sure to set a reference to the appropriate namespace. Nearly all of the ASP.NET controls that you could want belong to the System.Web.UI.WebControls namespace.

Once the controls are declared, you can set their properties and add them to the Controls collection of the web part. You can do this by overriding the CreateChildControls method. In this method, set property values for each control and then add it to the Controls collection using the Controls.Add method. You can also utilize event handlers for the ASP.NET controls, which will be necessary to capture button clicks and the like. Listing 10-3 shows several controls being added to a web part.

protected TextBox txtDisplay;
protected Button btnGo;

protected override void CreateChildControls()
{
    this.btnGo.Click += new System.EventHandler(this.btnGo_Click);
    this.Controls.Add(btnGo);

    txtDisplay.Width=Unit.Percentage(100);
    this.Controls.Add(txtDisplay);

}

private void btnGo_Click(object sender, System.EventArgs e)
{
    txtDisplay.Text=Text;
}

Once the controls are all configured and added to the web part, you are ready to draw the output. When rendering the user interface of the web part, you use the HtmlTextWriter class provided by the RenderContents method. This class allows you to create any manner of HTML output for the web part.

As a general rule, you should render your user interface within an HTML <table>. The reason for this is that you can never be sure what the web part page layout will look like. As you saw in Chapter 5, layouts and web part zones can take almost any form. Therefore, you should use the relative layout offered by the <table> tag to respect the width defined by the zone where the web part appears. Listing 10-4 shows how to render a table containing ASP.NET controls. You should take particular note of the width definition within the table.

protected override void RenderContents(HtmlTextWriter writer)
{
  writer.Write("<table border="0" width="100%">");
  writer.Write("<tr><td>");
  btnGo.RenderControl(writer);
  writer.Write("</td></tr>");
  writer.Write("<tr><td>");

txtDisplay.RenderControl(writer);
  writer.Write("</td></tr>");
  writer.Write("</table>");

}

Just like ASP.NET controls, web parts participate in a server-side request/response sequence that loads a page in the portal each time it is requested, and unloads the page once it is sent to the client. Web parts, therefore, follow the same control life cycle that ASP.NET controls follow. You can see the events of this life cycle by creating a web part that generates output in response to each key event. Listing 10-5 shows the code for a complete web part with all of the major methods overridden to display the order in which they occur.

//The following are included in the project automatically
using System;
using System.Collections.Generic;
using System.Text;

//The following were added manually after setting a reference to System.Web
using System.Web.UI;
using System.Web.UI.WebControls;
using System.Web.UI.WebControls.WebParts;


namespace SPLifecycle
{
    public class Reporter:WebPart
    {
        //variable for reporting events
        private string m_report="";

        //variable for button and text
        private Button m_button;
        private TextBox m_text;

        protected override void OnInit(EventArgs e)
        {
            m_report += "OnInit<br/>";
            base.OnInit(e);
        }

protected override void LoadViewState(object savedState)
        {
            m_report += "LoadViewState<br/>";

            object[] viewState = null;
            if (savedState != null)
            {
                viewState = (object[])savedState;
                base.LoadViewState(viewState[0]);
                m_report += (string)viewState[1] + "<br/>";
            }

        }

        protected override void CreateChildControls()
        {
            m_report+="CreateChildControls<br/>";

            m_button = new Button();
            m_button.Text = "Push Me!";
            m_button.Click += new EventHandler(m_button_Click);
            Controls.Add(m_button);

            m_text = new TextBox();
            Controls.Add(m_text);
        }

        protected override void OnLoad(EventArgs e)
        {
            m_report += "OnLoad<br/>";
            base.OnLoad(e);
        }

        void m_button_Click(object sender, EventArgs e)
        {
            m_report+="Button Click<br/>";
        }

        protected override void OnPreRender(EventArgs e)
        {
            m_report += "OnPreRender<br/>";
            base.OnPreRender(e);
        }

        protected override object SaveViewState()
        {
            m_report += "SaveViewState<br/>";

object[] viewState = new object[2];
            viewState[0] = base.SaveViewState();
            viewState[1] = "myData";

            return viewState;
        }

        protected override void RenderContents(HtmlTextWriter writer)
        {
            m_report += "RenderContents<br/>";
            writer.Write(m_report);
            m_text.RenderControl(writer);
            m_button.RenderControl(writer);
        }

        public override void Dispose()
        {
            base.Dispose();
        }

        protected override void OnUnload(EventArgs e)
        {
            base.OnUnload(e);
        }


    }
}

When a page from a WSS site that contains web parts is requested for the first timeor when it is submitted to the serverthe web part life cycle begins. The first phase in this life cycle is marked by a call to the OnInit method of the WebPart class. During initialization, configuration values that were marked as WebBrowsable and set through the web part task pane are loaded into the web part.

After the web part is initialized, the ViewState of the web part is populated. ViewState is a property inherited from System.Web.UI.Control. The ViewState is filled from the state information that was previously serialized. Once the ViewState property is populated, the control returns to the same state it was in when it was last processed on the server. The ViewState is populated through a call to the LoadViewState method.

Although it is normally not necessary to override the LoadViewState method, it is useful if you would like to persist your own data within a web part. Overriding the LoadViewState method along with the corresponding SaveViewState method lets you store custom data within the web part's view state. In Listing 10-5, I use this technique to show how these methods fit into the overall web part life cycle.

When the viewstate becomes available, the web part's user interface may be created. As I showed earlier, this happens with a call to the CreateChildControls method. In this method, all of the constituent controls are created and added to the Controls collection. It is important to note that the CreateChildControls method does not always get called at the same point in the life cycle. When web parts are first rendered on the page, the method generally occurs after the OnLoad method. After a postback, however, the method is called before the OnLoad method. You can even force it to be called using the EnsureChildControls method. All this means that you must not make any hard assumptions about when this method will execute.

Once the web part interface has been created and the properties set from the viewstate, the server can make changes to the properties of the web part based on values that are posted by the client browser. Any new values that are posted during the requestsuch as text field valuesare applied to the corresponding property of the web part. At this point, the web part has reached the state it was in just before the postback occurred.

After all of the new property values are applied to the web part, the page may begin using the information to process the end-user request. This begins through a call to the OnLoad method of the WebPart class. The OnLoad method fires for every web part regardless of how many properties have changed. Web part developers use the OnLoad method as the basis for the functionality embodied in the web part. During this event, web parts may obtain a connection to a database or other system to retrieve information for display. The key thing to remember about this method is that it always fires after the posted data has been applied to the web part.

Once the OnLoad method completes, any events triggered by the client interaction with the web part are fired. This includes all user-generated events such as the Click event associated with a button. It is critical for the web part developer to understand that the user-generated events happen after the OnLoad event. This means that you must be careful not to rely on the results of user-generated events when you write code for the OnLoad event.

Once the web part has finished handling the user-generated events, it is ready to create the output of the control. The web part begins creating this output with a call to the OnPreRender method of the WebPart class. The OnPreRender method gives the web part developer the opportunity to change any of the web part properties before the control output is drawn. This is the perfect place to run a database query that relies on several user-supplied values, because all of the values will be available at this point in the life cycle.

After the OnPreRender event is complete, the web part output may be drawn. Drawing begins through a call to the RenderContents method, which I discussed in the "Rendering Web Parts" section. In this method, the web part must programmatically generate its HTML output. This output will be rendered in the appropriate zone on the page in the portal.

The next step is to save the state of any controls on the page in the ViewState. The ViewState of the web part is serialized and saved to a hidden field in the web page. The ViewState is saved through a call to the SaveViewState event, which is inherited from the System.Web.UI.Control class.

Once the ViewState is saved, the control web part can be removed from the memory of the server. Web parts receive notification that they are about to be removed from memory through the Dispose event. This method allows the web part developer to release critical resources such as database connections before the web part is destroyed.

The web part life cycle ends when it is finally removed from memory. The last event to fire is the OnUnload event. This event notifies the web part that it is being removed from memory. Generally web part developers do not need access to this event because all cleanup should have been accomplished in the Dispose event.

Understanding the complete life cycle helps significantly when developing web parts. In particular, understanding when certain values are available to the web part will ensure that you create components with consistent behavior. Figure 10-1 shows the output of the life cycle web part.

Figure 10.1. The web part life cycle

Because SharePoint is a web-based application with potential ties to sensitive organizational information, web part security is a significant concern. These security concerns encompass not only access to information, but also potential malicious behavior by web parts. Imagine that a power user downloads and installs a free web part from the Internet. The web part has some nice site navigation that everyone likes, but in the background it is also crawling the network.

SharePoint web parts can be deployed with or without a strong name. Assemblies with a strong name may be deployed to the Global Assembly Cache (GAC) or the /bin directory of the targeted SharePoint site collection. Assemblies without a strong name may only be deployed to the /bin directory. The best practice, however, is to digitally sign web parts with a trusted certificate so that you can guarantee all of the web parts in your system are trustworthy. In my experience, however, most web parts are simply deployed using a strong name created by the developer at design time.

Before you can give your web part a strong name, you must generate a public/private key pair to use when signing the web part. You can create a key pair using the Strong Name tool (sn.exe) or have Visual Studio do it for you through the properties dialog. Figure 10-2 shows the Signing tab of the properties dialog in Visual Studio.

Figure 10.2. Signing the web part

If an organization already has a digital certificate, it may not be made generally available to developers who need to sign code. In this case, the developer may choose to delay signing the web part. When you delay signing, the web part space is reserved for the final signature, but you can still use the web part during development.

In order to delay signing the web part, you must set the AssemblyDelaySign attribute to True. You must then get the public key portion of the certificate and reference it using the AssemblyKeyFile attribute. Finally, you must instruct the .NET Framework to skip the strong name verification test for the web part by using the Strong Name tool with the following syntax:

sn -Vr [assembly.dll]

Regardless of how you choose to sign the web part, you should make sure that the version number specified in the AssemblyInfo file is absolute. Visual Studio .NET has the ability to autoincrement your project version using wildcards; however, this is not supported by strong naming. Therefore, you must specify an exact version for the web part. The following code fragment shows an example:

[assembly: AssemblyVersion("1.0.0.0")]

As I mentioned earlier, you can deploy a web part in either the GAC or the in directory of the associated web application. If you choose to deploy the web part in the in directory, you will also need to add the AllowPartiallyTrustedCallers attribute to the AssemblyInfo file. This is required because assemblies in the in directory will not operate with full trust. The AllowPartiallyTrustedCallers attribute is part of the System.Security namespace, so you must reference the namespace as shown in the following code fragment:

using System.Security;
[assembly: AllowPartiallyTrustedCallers]

After the assembly is signed, you can build the web part. Once the web part is built, you may either install it in the GAC or copy it to the in directory. Installing the web part in the GAC allows the web part to operate with full trust, whereas copying it to the in directory subjects it to the security policy defined in the associated web.config file. Generally, the best practice is to copy the web part to the in directory and adjust the security policy as required. I'll cover more on security policies in the section titled "Code Access Security."

If you are going to copy your web part to the in directory, you must locate the correct web application on the file system and create a in directory, because it does not exist by default. As I discussed earlier in the book, SharePoint creates folders for all of the web applications in the path InetpubwwwrootwssVirtualDirectories. In this folder, you will find a folder for each web application that is generally named by port number. It is underneath this folder where you will create a in directory and copy the assembly. Figure 10-3 shows an example bin directory in the File Explorer.

Figure 10.3. Creating the in directory

SharePoint is based on ASP.NET technology. As such, it is bound by the same security limitations that apply to any ASP.NET application. Practically speaking, this means that web parts are often restricted from accessing enterprise resources such as databases and web services unless you specifically configure SharePoint to allow such access. Managing how code can access enterprise resources is known as code access security.

Understanding Configuration Files

Code access security is implemented by a series of configuration files. The first configuration file of concern is web.config located in C:WindowsMicrosoft.NET Frameworkv2.0.50727CONFIG. This file specifies master settings that will be inherited by all WSS sites that run on the server. This particular file is densely packed with information, and a complete discussion of the contents is beyond the scope of this book. However, one section<securityPolicy>is of immediate importance.

The <securityPolicy> section defines five levels of trust for ASP.NET applications: Full, High, Medium, Low, and Minimal. The trust level definitions allow you to assign partial permissions to an ASP.NET application that determine what resources the application can access. For example, applications with High levels of trust can read and write to files within their directory structure, whereas an application with a Low trust level can only read files. The permissions allotted by each level of trust are defined within a separate policy file designated by the <trustLevel> element. The following code shows the <securityPolicy> section for the machine.config file associated with an installation of WSS:

<securityPolicy>
    <trustLevel name="Full" policyFile="internal"/>
    <trustLevel name="High" policyFile="web_hightrust.config"/>
    <trustLevel name="Medium" policyFile="web_mediumtrust.config"/>
    <trustLevel name="Low" policyFile="web_lowtrust.config"/>
    <trustLevel name="Minimal" policyFile="web_minimaltrust.config"/>
</securityPolicy>

The security policy files referenced by the <trustLevel> element are also XML files. These files contain a separate section for each policy that the file defines. Examining each of the files referenced in the web.config file results in the complete picture of the trust levels and permissions.

The web.config file represents the highest level of configuration for ASP.NET applications; however, each application may have a supplemental configuration file also named web.config. This file is typically found in the root directory of an application, and for SharePoint it is located in inetpubwwwrootwssVirtualDirectories[WebApplication]. Opening this file will reveal that it also has a <securityPolicy> section that defines two additional levels of trust known as WSS_Medium and WSS_Minimal. The following code shows the <securityPolicy> section from the file:

<securityPolicy>
  <trustLevel name="WSS_Medium"
  policyFile="C:Program FilesCommon FilesMicrosoft Shared
Web Server Extensions12configwss_mediumtrust.config" />
  <trustLevel name="WSS_Minimal"
  policyFile="C:Program FilesCommon FilesMicrosoft Shared
Web Server Extensions12configwss_minimaltrust.config" />
</securityPolicy>

The default installation of WSS defines a trust level of WSS_Minimal for all sites. Because web parts are deployed to the in directory, they are affected by the trust level set in the web.config file. This means that web parts associated with a SharePoint site have significant limitations. Most importantly, web parts running under WSS_Minimal cannot access any databases nor can they access the objects contained in the SharePoint object model. The Common Language Runtime (CLR) will throw an error if a web part attempts to access an unauthorized resource. Therefore, you must always implement appropriate error handling in a web part during attempts to access resources. Exception classes for these errors can be found in the Microsoft.SharePoint.Security namespace.

Customizing Policy Files

Because one of the major reasons to write a web part is to access data in other systems, you will undoubtedly want to raise the trust level under which certain web parts will run. You have three options for raising the trust level for assemblies in the in directory. All three have strengths and weaknesses you need to consider depending upon whether you are in a development, testing, or production environment.

The first option is simply to raise the trust level for all SharePoint Services sites by modifying the web.config file directly in a text editor. The trust level for SharePoint Services is set in the <system.web> section of the web.config file. To raise the level of trust, modify the <trust> tag to use any one of the seven defined levels. The following code shows an example with the trust level set to WSS_Medium:

<trust level="WSS_Medium" originUrl=""/>

Although making a global change to the trust level is simple, it should only be done in development environments. Generally, you should strive to limit access to resources to only essential web parts in a production environment. The default WSS_Minimal level is recommended for production.

The second option is to deploy all of your web parts into the GAC. The GAC grants the Full level of trust to web parts installed there without requiring a change to the web.config file. Once again, this is a fairly simple way to solve the problem, but it does make the web part available to all applications and servers. This is a potential problem, because a highly trusted component is now more widely accessible. Web parts can be added to the GAC using the command-line tool gacutil.exe with the following syntax:

gacutil -i [assembly.dll]

The final option for raising the trust level associated with a web part is to create your own custom policy file. Although this approach requires the most effort, it is easily the most secure. This approach should be considered the recommended best practice for production environments.

To create a custom policy file, follow these steps:

Listing 10-6 shows the final XML.

<PermissionSet
    class="NamedPermissionSet"
    version="1"
    Name="wss_sqltrust">
        <IPermission
            class="AspNetHostingPermission"
            version="1"
            Level="Minimal"
        />
        <IPermission
            class="SecurityPermission"
            version="1"
            Flags="Execution"
        />

<IPermission class="WebPartPermission"
            version="1"
            Connections="True"
        />
        <IPermission
            class="SqlClientPermission"
            version="1"
            Unrestricted="true"
        />
</PermissionSet>

The predefined security policies available to SharePoint lack templates for defining access to several key resources. These resources include the SharePoint object model and web services. Therefore, I will review the necessary modifications you must make to policy files in order to access these resources.

If you want your web part to be able to access the classes in the SharePoint namespace, you must define a new <IPermission> element in the policy file similar to what was done here for SQL access. The following code shows how to define the element:

<IPermission
    class="SharePointPermission"
    version="1"
    ObjectModel="true"
/>

Similarly, if you want your web part to be able to call a web service, you must also define a new <IPermission> element. In this element, you specify the Uniform Resource Identifier (URI) of the web service to access. This URI may be in the form of a regular expression, which means you can set it up to match more than one available web service. The following code shows how to define the element:

<IPermission class="WebPermission" version="1">
<ConnectAccess>
<URI uri="http://localhost/services/callreport.asmx?WSDL"/>
</ConnectAccess>
</IPermission>

Remember that in any case where a strongly named web part is in use, all of the other components must also be strongly named. This can cause problems when you are accessing web services or other libraries. In these cases, you must either install your web part to the GAC or implement a custom security policy.

Marking Web Parts As Safe

Adding a new web part to the in directory or the GAC handles the code access security issues for the part, but it is not sufficient to allow the part to be imported into SharePoint. In addition to permission to access resources, web parts also need permission to be imported into SharePoint. This permission is granted by marking the web part as Safe in the web.config file.

The web.config file contains not only the code access security policy but also the list of all assemblies allowed to run in a web part page. This information is kept in the <SafeControls> section of the file. Before a web part can be imported into SharePoint, it must be listed in the section. Listing 10-7 shows a truncated example of a <SafeControls> section.

<SafeControls>
<SafeControl Assembly="SPMaskTool, Version=1.0.0.0, Culture=neutral,
PublicKeyToken=eb3e58846fb2ac2b" Namespace="SPMaskTool" TypeName="*" />
<SafeControl Assembly="SPPageView, Version=1.0.0.0, Culture=neutral,
PublicKeyToken=eb3e58846fb2ac2b" Namespace="SPPageView" TypeName="*" />
<SafeControl Assembly="SPDataList, Version=1.0.0.0, Culture=neutral,
PublicKeyToken=eb3e58846fb2ac2b" Namespace="SPDataList" TypeName="*" />
<SafeControl Assembly="SPDataSet, Version=1.0.0.0, Culture=neutral,
PublicKeyToken=eb3e58846fb2ac2b" Namespace="SPDataSet" TypeName="*" />
<SafeControl Assembly="SPPivotalContacts, Version=1.0.0.0, Culture=neutral,
PublicKeyToken=eb3e58846fb2ac2b"
Namespace="SPPivotalContacts" TypeName="*" />
<SafeControl Assembly="Citrix, Version=1.0.0.0, Culture=neutral,
PublicKeyToken=eb3e58846fb2ac2b" Namespace="Citrix" TypeName="*" />
</SafeControls>

In the <SafeControls> section, you must add a <SafeControl> element for each web part that you want to use in SharePoint. In the <SafeControl> element, you must specify several attributes:

Setting the output path for the web part project to in or copying the assembly are simple ways to ensure that the final web part assembly is deployed to the right location; however, this technique is only useful in a development environment. For production environments, you will want to build a solution package that can be deployed independent of Visual Studio.

Creating solution packages is done inside Visual Studio .NET as a new cabinet project in the same solution where the web part project is located. When you create the cabinet, you need to create a solution manifest file and include the assembly file to successfully deploy the web part. SharePoint recognizes cabinet files with a WSP extension as solution packages. Solution packages can be used to deploy all manner of components.

Before you can create the solution package, you must create a manifest file to describe the solution. This file must be named manifest.xml and will include a reference to the assembly as well as an appropriate entry for the SafeControls section of the web.config file. The simplest way to make this file is to include it directly in the web part project. Listing 10-8 shows an example manifest.xml file that deploys a web part to the in directory.

<Solution xmlns=http://schemas.microsoft.com/sharepoint/
  SolutionId="997310BA-AB2E-4d97-87B4-4DABAB0EB796" >
  <Assemblies>
    <Assembly DeploymentTarget="WebApplication" Location="SPScript.dll">
      <SafeControls>
        <SafeControl
        Assembly="SPScript, Version=1.0.0.0, Culture=neutral,
        PublicKeyToken=689f1d0ba493bcce"
        Namespace="SPScript" Safe="True" TypeName="*"/>
      </SafeControls>
    </Assembly>
  </Assemblies>
</Solution>

The Solution element contains a SolutionId attribute that uses a GUID to uniquely identify the solution. The Assembly element contains a DeploymentTarget attribute that can be set to WebApplication or GlobalAssemblyCache to specify whether the assembly should be deployed to the in directory or the GAC, respectively. The SafeControl element is used to specify an entry in the web.config file for the assembly. Once you have the manifest.xml file created, you can create a deployment package for the web part.

Here are the steps to follow to create a deployment package:

Once the cabinet file is created, you should rename it to have a WSP extension. Then you may add it to the solution store, which is a central location for deploying solutions to web applications. In order to add your solution to the store, you must use the administration tool StsAdm.exe. The tool is located in the directory Program FilesCommon FilesMicrosoft Sharedweb server extensions12in. Use the following command to add a solution to the solution store:

Stsadm.exe -o addsolution -filename mypart.wsp

Once your solution is added to the store, you can deploy it to any web application. Open the Central Administration web site and click the Solution Management link on the Operations tab. The Solution Management page displays all of the solutions in the store. Figure 10-4 shows the Solution Management page in the Central Administration web site.

Figure 10.4. The solution store

From the Solution Management page, you can click any solution and then choose to deploy it. Deploying a solution from the solution store is much easier than copying the same files repeatedly to different web applications. Additionally, the Solution Management page can be used to remove a solution from a web application.

Regardless of whether you edit the web.config file and copy the assembly by hand or use a solution package, a custom web part is not available for use until it is added to the Web Parts Gallery. You can access the Web Parts Gallery from the Site Settings page associated with the top-level site in a collection. This gallery shows all of the web parts that are available for use in the site collection.

You can add your custom web part to the gallery by clicking the New button, which will open the New Web Parts page. Any web part deployed manually or using a solution will appear on this page. You simply check the web parts that you want to add to the gallery, and then click the Populate Gallery button. After this, the selected web parts will be available for use on a web page. Figure 10-5 shows the New Web Parts page.

Figure 10.5. Adding web parts to the gallery

When you build custom connection interfaces, you start by defining an interface that returns the type of data that you want to pass from one part to another. There are no special requirements for this interface, and it looks like any you would define. The following code shows a simple interface defined to pass a string from one web part to another:

public interface IStringConnection
{
    string ProvidedString { get;}
}

The provider web part, which supplies the value to be passed, will implement the custom connection interface. Along with the implementation of the interface, the provider web part exposes a property that returns a reference to the connectable interface. The property must then be decorated with the ConnectionProvider attribute, which marks the interface as connectable within the web part infrastructure. Listing 10-10 shows how a web part class would implement an interface and expose it for connections.

public class StringProvider:WebPart,IStringConnection
{

    protected string m_string = "Test Data";

    [ConnectionProvider("String Provider")]
    public IStringConnection ConnectionInterface()
    {
        return this;
    }

    //The passed value
    public string ProvidedString
    {
        get { return m_string; }
    }
}

The consumer web part, which will receive the passed value, must contain a method for receiving the connection interface. This method is also decorated with the ConnectionProvider attribute. This attribute determines which web parts on a page are compatible for connections. Listing 10-11 shows how a web part class would obtain a reference to the connectable interface and receive the passed value.

public class SPStringConsumer : WebPart
{

    IStringConnection m_providerPart = null;

    [ConnectionConsumer("String Consumer")]
    public void GetConnectionInterface(IStringConnection providerPart)
    {
        m_providerPart = providerPart;
    }

    protected override void RenderContents(HtmlTextWriter writer)
    {
      try
      {
         writer.Write(m_providerPart.ProvidedString);
      }

catch
      {
         writer.Write("No connection.");
      }
    }
}

Once you have created and deployed compatible web parts, you can add them to a page. After they are on the page, they can be connected using the web part menu associated with either the provider or the consumer. When compatible web parts are on the same page, a menu item titled Connections will be available for selecting a compatible web part. This menu item functions identically to the ones you have used previously in the book to connect out-of-the-box web parts.

While creating custom interfaces is a quick way to connect web parts, they cannot be used to connect to libraries, lists, or out-of-the box web parts. SharePoint provides a separate set of interfaces that constitute a standard mechanism for connecting web parts. These interfaces expose methods and events that allow the connection infrastructure to query your web parts for appropriate connection information and provide notification when another web part wants to connect. The available interfaces support passing a single piece of data, a row of data, or an entire list of data. Table 10-1 lists the available interfaces and their purposes.

If a provider web part and a consumer web part are exchanging similar datasuch as a single cellthey may be connected directly using the web part menu associated with either part. Connection interfaces, however, can often allow connections that are not immediately obvious. For example, a web part that provides an entire row can be connected to a web part that only consumes a single field.

Determining which interfaces are compatible is handled by the web part infrastructure according to several rules. The first, and most obvious, rule is that web parts providing or consuming the same data structures are always compatible. For interfaces that use different data structures, extended connectionsknown as transformersare allowed where they make sense. The web part infrastructure implements a selection dialog that allows end users to map fields from compatible interfaces when necessary. Figure 10-6 shows a typical field selection dialog in SharePoint.

Figure 10.6. Connecting web parts in SharePoint

Building a Provider Web Part

You begin the process of creating a provider web part by deciding what kind of data it will expose. Based on this decision, your web part will implement the appropriate interface from Table 10-1. The code is very similar to creating your own custom interface except there are a couple of extra methods. Listing 10-12 shows the basic structure for stubbing out providers based on each of the available interfaces.

public class FieldProviderStub:WebPart,IWebPartField
{
    [ConnectionProvider("Data")]
    public IWebPartField ConnectionInterface()
    {
        return this;
    }

    public void GetFieldValue(FieldCallback callback)
    {
    }

    public PropertyDescriptor Schema
    {
        get {}
    }

}


public class RowProviderStub:WebPart,IWebPartRow
{
    [ConnectionProvider("Data")]
    public IWebPartRow ConnectionInterface()
    {
        return this;
    }

public void GetRowData(RowCallback callback)
    {
    }

    public PropertyDescriptorCollection Schema
    {
        get {}
    }

}


public class TableProviderStub:WebPart,IWebPartTable
{
    [ConnectionProvider("Data")]
    public IWebPartTable ConnectionInterface()
    {
        return this;
    }

    public void GetTableData(TableCallback callback)
    {
    }

    public PropertyDescriptorCollection Schema
    {
        get {}
    }

}


public class ParameterProviderStub:WebPart,IWebPartParameters
{
    [ConnectionProvider("Data")]
    public IWebPartParameters ConnectionInterface()
    {
        return this;
    }

    public void GetParametersData(ParametersCallback callback)
    {

    }

public PropertyDescriptorCollection Schema
    {
        get {}
    }

    public void SetConsumerSchema(PropertyDescriptorCollection schema)
    {
    }
}

In just the same way as you did for custom interfaces, the provider must supply a reference to itself that is returned through a method decorated with the ConnectionProvider attribute. This reference is used by the web part infrastructure when connecting web parts.

Each provider must also implement a method for receiving a reference to the consumer web part. These methods are GetFieldValue, GetRowData, GetTableData, and GetParametersData, depending upon which interface you are implementing. During the connection process, the web part infrastructure will pass a callback reference in that you can use later to pass data to the consumer web part.

Each provider web part must also implement a method for exposing the schema for the data that will be returned. The method returns a System.ComponentModel.PropertyDescriptor if you are only passing a cell of data, or a System.ComponentModel.PropertyDescriptorCollection if you are passing a row, a table, or parameters. The returned schema can subsequently be used by the consumer to validate the passed data and ensure that it is meaningful.

The best way to implement these methods is to create a web part property for each piece of data that you want to make available. When you make a web part property, you can then use the System.ComponentModel.TypeDescriptor object to return information about the properties you want to expose. The following code shows how to return the schema for a LastName property.

public PropertyDescriptor Schema
{
    get { return TypeDescriptor.GetProperties(this)["LastName"];}
}

If you are implementing the IWebPartParameters interface, you will also have to create a SetConsumerSchema method. This method is called by the consumer web part during the connection process to pass the schema of the properties it has available for mapping. The provider can use this information to validate that the requested data is meaningful.

The data itself is transferred between the web parts on the server when the page is submitted. In the section "Understanding the Connection Life Cycle," I look in detail at the web part life cycle and how it is affected by connections. For now, examine Listing 10-13, which shows a complete provider web part that exposes a text value entered into a field.

public class TextProvider : WebPart, IWebPartField
{
    //Member variables
    protected Button button = null;
    protected TextBox text = null;
    string m_data = null;

    //Text Property
    [Personalizable(PersonalizationScope.Shared), WebBrowsable(false),
    WebDisplayName("Text"),
    WebDescription("The text to send")]
    public string Text
    {
        get { return m_data; }
        set { m_data = value; }
    }

    //Child controls
    protected override void CreateChildControls()
    {
        button = new Button();
        button.Text = "Send Data";
        button.Click += new EventHandler(button_Click);
        Controls.Add(button);

        text = new TextBox();
        Controls.Add(text);
    }

    //Show UI
    protected override void RenderContents(HtmlTextWriter writer)
    {
        button.RenderControl(writer);
        text.RenderControl(writer);
    }

    //The connection description
    [ConnectionProvider("Text")]
    public IWebPartField ConnectionInterface()
    {
        return this;
    }

//Callback object
    public void GetFieldValue(FieldCallback callback)
    {
        //Send data to consumer
        callback.Invoke(text.Text);
    }

    //Publish schema
    public PropertyDescriptor Schema
    {
        get
        {return TypeDescriptor.GetProperties(this)["Text"];}
    }

    void button_Click(object sender, EventArgs e)
    {
        m_data = text.Text;
    }

}

Building a Consumer Web Part

When you create a consumer web part, you must first determine what kind of data structure it will receive. However, you do not have to implement any specific interface to use the data structure. Instead, you create a method decorated with the ConnectionProvider attribute to receive a reference to the provider part. Additionally, you must register a callback method with the provider part so the consumer can receive the data structure. This is done using delegates that are defined in the WebParts namespace. Listing 10-14 shows code stubbed out for the different data structures that consumers can receive.

public class FieldConsumerStub:WebPart
{

    [ConnectionConsumer("Field")]
    public void GetConnectionInterface(IWebPartField providerPart)
    {
        FieldCallback callback = new FieldCallback(ReceiveField);
        providerPart.GetFieldValue(callback);
     }

    public void ReceiveField(object field)
    {
    }

}

public class RowConsumerStub:WebPart
{
    [ConnectionConsumer("Row")]
    public void GetConnectionInterface(IWebPartRow providerPart)
    {
        RowCallback callback = new RowCallback(ReceiveRow);
        providerPart.GetRowData(callback);
    }

    public void ReceiveRow(object row)
    {
    }
}


public class TableConsumerStub:WebPart
{
    [ConnectionConsumer("Table")]
    public void GetConnectionInterface(IWebPartTable providerPart)
    {
        TableCallback callback = new TableCallback(ReceiveTable);
        providerPart.GetTableData(callback);
    }

    public void ReceiveTable(ICollection table)
    {
    }
}


public class ParametersConsumerStub:WebPart
{
    [ConnectionConsumer("Parameters")]
    public void GetConnectionInterface(IWebPartParameters providerPart)
    {
        //Specify what properties this part can map
        PropertyDescriptor[] property =
        {TypeDescriptor.GetProperties(this)["propertyName"]};
        PropertyDescriptorCollection schema =
        new PropertyDescriptorCollection(property);
        providerPart.SetConsumerSchema(schema);

        //Give provider reference to callback function
        ParametersCallback callback = new ParametersCallback(ReceiveParameters);
        providerPart.GetParametersData(callback);
    }

public void ReceiveParameters(IDictionary parameters)
    {
    }
}

Understanding the Connection Life Cycle

The life cycle of parts involved in a connection follows the same events as an unconnected web part, with a few additions. The key new events occur when the connection interface is queried and the callback object is passed to the provider. The exact sequence of events that occurs during a connection is critical because certain values and objects may not exist until a specific time, and calling to them before they are created will result in errors.

The connection process begins when you choose to connect two web parts using the web part menu. When you make your selection, the current page is posted back and both the provider and the consumer execute the OnInit, LoadViewState, and OnLoad methods. So far, this is identical to the life cycle of an unconnected part.

After the web parts are loaded, the connection infrastructure queries the connection interfaces to get a reference to the provider web part and pass it to the consumer web part. The consumer web part then responds by sending the callback object to the provider. If the consumer expects to receive parameters, it may also publish its schema using the SetConsumerSchema method. At this point, the provider may immediately use the callback method to send a value.

Once references and data have been exchanged, the life cycle proceeds as normal. The CreateChildControls, OnPreRender, SaveViewState, RenderContents, OnUnload, and Dispose methods are executed. The consumer web part may use the passed data to affect its output as necessary.

After the connection is made, subsequent postbacks follow a slightly different sequence. Just like an unconnected web part, the connected web parts will execute OnInit, LoadViewState, CreateChildControls, and OnLoad. Now the sequence becomes interesting because the provider web part will proceed to execute any control events such as the Click method, but this will occur before the connection infrastructure provides the reference to the consumer web part.

It is important to understand that the references between the provider and the consumer are not persistent. They are reestablished by the connection infrastructure during each postback. Therefore, you cannot send data from provider to consumer until the reference is reestablished. This means that you cannot write code in control events to send data to the consumer, which is what you naturally want to do. Instead, use your control events to store data in the viewstate or another control. Then you can send the stored data as the source for the consumer. Listing 10-13 earlier shows this exact technique for a provider web part. At the end of this chapter, you will also find a complete exercise for creating connected web parts.

To create a custom editor part, you need to build a new class that inherits from the EditorPart class. Because an editor part is essentially a specialized web part that runs in the tool pane of SharePoint, you will find that you use many of the same skills to build an editor part that you used previously to build web parts.

Just like a standard web part, editor parts must override the CreateChildControls method to build a user interface. You draw the user interface by overriding the RenderContents method in the same way you would for a web part. When the user interface is drawn, the child controls show up in the property pane.

What makes an editor part different from a standard web part is that it has methods that allow it to receive events from the property pane in SharePoint. These events are fired whenever a user clicks Apply, OK, or Cancel in the tool pane. The EditorPart class allows your custom editor part to receive these events through the ApplyChanges and SyncChanges methods.

The ApplyChanges method is called by the web part infrastructure whenever a user clicks Apply or OK. In this method, you retrieve the new value of the property as it was entered into the property pane by the end user. You must in turn pass the property to the web part so that it can update its own display. In order to pass a value from the property pane to the web part, you must retrieve a reference to the web part using the WebPartToEdit property.

After any changes are made in the property pane, the web part infrastructure calls the SyncChanges method. This method is used to pass changes back from the web part to the property pane. This is necessary because the web part and the property pane can be out of sync if the user cancels an action or if there is a validation error you need to report to the user. Listing 10-15 shows a complete editor part for a custom phone number field that uses a regular expression to ensure the phone number is formatted correctly.

public class PhoneEditor:EditorPart
{
    TextBox property = null;
    Label messages = null;

    protected override void CreateChildControls()
    {
        property = new TextBox();
        Controls.Add(property);

        messages = new Label();
        Controls.Add(messages);
    }

protected override void RenderContents(HtmlTextWriter writer)
    {
        property.RenderControl(writer);
        writer.Write("<br/>");
        messages.RenderControl(writer);
    }

    public override bool ApplyChanges()
    {
        try
        {
            Regex expression = new Regex(@"(ddd)sddd-dddd");
            Match match = expression.Match(property.Text);
            if (match.Success == true)
            {
                ((PhoneLabel)WebPartToEdit).Phone = property.Text;
                messages.Text = "";
            }
            else
            {
                ((PhoneLabel)WebPartToEdit).Phone = "Invalid phone number";
            }
        }
        catch (Exception x)
        {
            messages.Text += x.Message;
        }
        return true;
    }

    public override void SyncChanges()
    {
        try
        {
            property.Text = ((PhoneLabel)WebPartToEdit).Phone;
        }
        catch { }
    }

}

Once you have created a custom editor part, you must associate it with a web part. This is accomplished by overriding the CreateEditorParts method of the web part. When the CreateEditorParts method is called, you can create instances of any editor parts you want to load into the property pane. After the editor parts are created, you must add them to a new EditorPartCollection and return the collection. Listing 10-16 shows a complete web part for displaying a phone number with a custom format.

public class PhoneLabel:WebPart
{
    protected string m_phone;

    [Personalizable(PersonalizationScope.Shared), WebBrowsable(false),
    WebDisplayName("Phone"),
    WebDescription("Phone number")]
    public string Phone
    {
        get { return m_phone; }
        set { m_phone = value; }
    }

    public override EditorPartCollection CreateEditorParts()
    {
        ArrayList partsArray = new ArrayList();

        PhoneEditor phonePart = new PhoneEditor();
        phonePart.ID = this.ID + "_editorPart1";
        phonePart.Title = "Phone Number";
        phonePart.GroupingText = "(xxx) xxx-xxxx";
        partsArray.Add(phonePart);

        EditorPartCollection parts = new EditorPartCollection(partsArray);
        return parts;
    }

    protected override void RenderContents(HtmlTextWriter writer)
    {
        writer.Write("<p>" + m_phone + "</p>");
    }
}

You'll need a sample database for creating this web part. If you followed the setup instructions in Chapter 2, you should have SQL Server 2005 available to you. Unfortunately, SQL Server 2005 does not ship with a sample database. Therefore, you'll have to install a sample database before you can get started.

Follow these steps to install the sample database:

Web parts are created as classes in Visual Studio 2005. In order to create the web part, you'll need to create a class and set some references to namespaces you will use. After creating the project, you'll import the referenced namespaces.

Follow these steps to create the new project:

using System.Web.UI;
using System.Web.UI.WebControls;
using System.Web.UI.WebControls.WebParts;
using System.Data;
using System.Data.SqlClient;
using System.Drawing;

Once you have the basic class stubbed out, you can proceed to code the web part. In this exercise, you'll add a property and some child controls to the web part. You'll use the properties and controls to query a database and display a result set.

Defining the Properties

The web part only requires a single property for defining the database connection string. Once deployed, you will have to set this string inside of SharePoint. Although we are using a connection string for simplicity, you should be careful about saving sensitive user and password information in a web part property. SharePoint has a single sign-on service that you'll learn about in Chapter 11, which is the appropriate place for storing credentials.

Add the following code to the Adventure class to define the Connection property:

//Member variables for properties
protected string m_connection;

//Connection Property
[Personalizable(PersonalizationScope.Shared),WebBrowsable(true),
WebDisplayName("Connection String"),
WebDescription("The connection string for the AdventureWorks database")]
public string Connection
{
    get{return m_connection;}
    set{m_connection=value;}
}

Defining the Child Controls

In order to use existing ASP.NET controls in your new web part, you must override the CreateChildControls method. In this method, you programmatically create a new instance of each child control, adjust its properties, and add it to the Controls set for the web part. Listing 10-17 shows how to create the child controls for the web part.

DataGrid grid;
Label messages;

protected override void CreateChildControls()
{
    //Add grid
    grid = new DataGrid();
    grid.AutoGenerateColumns = false;
    grid.Width = Unit.Percentage(100);
    grid.GridLines = GridLines.Horizontal;
    grid.HeaderStyle.CssClass = "ms-vh2";
    grid.CellPadding = 2;

    //Grid columns
    BoundColumn column = new BoundColumn();
    column.DataField = "FullName";
    column.HeaderText = "Associate";
    grid.Columns.Add(column);

column = new BoundColumn();
    column.DataField = "Title";
    column.HeaderText = "Title";
    grid.Columns.Add(column);

    column = new BoundColumn();
    column.DataField = "SalesTerritory";
    column.HeaderText = "Territory";
    grid.Columns.Add(column);

    column = new BoundColumn();
    column.DataField = "2002";
    column.HeaderText = "2002";
    column.DataFormatString = "{0:C}";
    column.ItemStyle.BackColor = Color.Wheat;
    grid.Columns.Add(column);

    column = new BoundColumn();
    column.DataField = "2003";
    column.HeaderText = "2003";
    column.DataFormatString = "{0:C}";
    grid.Columns.Add(column);

    column = new BoundColumn();
    column.DataField = "2004";
    column.HeaderText = "2004";
    column.DataFormatString = "{0:C}";
    column.ItemStyle.BackColor = Color.Wheat;
    grid.Columns.Add(column);

    Controls.Add(grid);

    //Add label
    messages = new Label();
    Controls.Add(messages);

}

Rendering the Web Part

Rendering the web part is done in the RenderContents method. In this exercise, you will create a layout table in HTML and then render the web part's constituent controls in the table. Layout tables are a good way to ensure that your web part looks good regardless of where it is positioned on the page.

Add the following code to the Adventure class to render the user interface:

protected override void RenderContents(HtmlTextWriter writer)
{
    DataSet dataSet = null;
    string sql = "SELECT     FullName, Title, SalesTerritory, " +
    "[2002], [2003], [2004] FROM Sales.vSalesPersonSalesByFiscalYears";

    //Get data
    using (SqlConnection conn = new SqlConnection(Connection))
    {
        try
        {
            conn.Open();
            SqlDataAdapter adapter = new SqlDataAdapter(sql, conn);
            dataSet = new DataSet("root");
            adapter.Fill(dataSet, "sales");

        }
        catch (SqlException x)
        {
            messages.Text = x.Message;
        }
        catch (Exception x)
        {
            messages.Text += x.Message;
        }

    }

//Bind data
    try
    {
        grid.DataSource = dataSet;
        grid.DataMember = "sales";
        grid.DataBind();
    }
    catch (Exception x)
    {
        messages.Text += x.Message;
    }

    //Display data
    writer.Write("<table border="0" width="100%">");
    writer.Write("<tr><td>");
    grid.RenderControl(writer);
    writer.Write("</td></tr>");
    writer.Write("<tr><td>");
    messages.RenderControl(writer);
    writer.Write("</td></tr>");
    writer.Write("</table>");

    }
}

In order to deploy the web part, you must give it a strong name and allow partially trusted callers to access the web part. Additionally, you must create a solution package so that administrators can control which web applications will use the web part. In the next section you will create a strong name for the web part, but for now, open the AssemblyInfo.cs file and add the attribute [assembly: System.Security.AllowPartiallyTrustedCallers()].

Creating a Strong Name

Web parts should have a strong name when used with SharePoint. In order to give the web part a strong name, you have to create a key pair file using the Strong Name tool, sn.exe. Once the strong name is created, you must create a reference to it in the assembly file. Although you can also create a strong name in Visual Studio for your assembly, it's easier to use the same key pair file for all your testing and debugging.

Perform these steps to create a strong name:

Creating a Manifest File

Even though the web part has compiled successfully, it cannot run in SharePoint until it is deployed to the target web application and marked as safe. While you can certainly accomplish these tasks manually, the best way to deploy a web part is with a solution file. The solution file will make the web part available for deployment through the Central Administration web site, which will allow it to be deployed to multiple web applications from a single location. In order to create a solution, you must first add a manifest file to the web part project. The manifest file contains the information necessary to deploy the web part and update the web configuration file.

Follow these steps to create the manifest file:

<?xml version="1.0" encoding="utf-8" ?>
<Solution xmlns="http://schemas.microsoft.com/sharepoint/"
  SolutionId="AF597DAB-65D7-4c1a-A012-D04184CA647E">
    <Assemblies>
      <Assembly DeploymentTarget="WebApplication"
      Location="SPDataPart.dll">
       <SafeControls>
        <SafeControl
         Assembly="SPDataPart, Version=1.0.0.0, Culture=neutral,
         PublicKeyToken=8c9fc716f38d08b2"
         Namespace="SPDataPart" TypeName="*"/>
        </SafeControls>
      </Assembly>
    </Assemblies>
</Solution>

Creating a Solution Package

Once the manifest file is completed, you are ready to create a solution package. The solution package is essentially a cabinet file that contains the web part assembly and manifest file. Once created, you may add the solution to the Central Administration solution store where an administrator can determine which web applications can utilize the new web part.

Follow these steps to create the solution package:

Stsadm.exe -o addsolution -filename SPDataPartSolution.wsp

Deploying the Web Part to a Web Application

Once the solution package has been added to the solution store, you can access it from the Central Administration web site. From the Central Administration web site, you may select to deploy the solution to a web application. Once deployed to a web application, a site collection administrator can make the web part available through the Web Parts Gallery.

Follow these steps to deploy the web part:

Once the web part is properly deployed to a web application, it can be used in a page. To use the web part, it must be added to the Web Parts Gallery. Once it's added, it can drag it onto a page and have its properties set.

Perform these steps to use the web part:

Figure 10.7. The completed web part

After finishing Exercise 10.1, the Adventure web part will return an entire result set of information. In order to filter the results, you must add a property that can be used as a filter in the query. This property will filter by last name and be set by another web part. Therefore, the property will not be visible in the property pane.

Open the SPDataPart project and add the following code to the Adventure class to add the new LastName property for filtering:

//Filter value
string m_lastName = null;

//Filter Property
[Personalizable(PersonalizationScope.Shared), WebBrowsable(false),
WebDisplayName("Last Name"),
WebDescription("The last name to use as a filter")]
public string LastName
{
    get { return m_lastName; }
    set { m_lastName = value; }
}

Once the new property is added, you must add the code that will get a reference to the provider part and allow you to pass a reference to the callback function. Since this web part will only filter by last name, you will accept connections with providers that implement IWebPartField or an interface that can be transformed to provide a single value.

Add the following code to support these connections:

[ConnectionConsumer("Last Name")]
public void GetConnectionInterface(IWebPartField providerPart)
{
    FieldCallback callback = new FieldCallback(ReceiveField);
    providerPart.GetFieldValue(callback);
}

public void ReceiveField(object field)
{
    if(field!=null)
        LastName = field.ToString();
}

Once the web part connection is made, you will need to use the passed value to filter the SQL statement. In this exercise, you will simply change the SQL in the web part to use the passed value. Alter the SQL statement to appear as this:

string sql = "SELECT     FullName, Title, SalesTerritory, " +
"[2002], [2003], [2004] FROM Sales.vSalesPersonSalesByFiscalYears " +
"WHERE FullName LIKE '%" + LastName +"'";

Once the web part modifications are made, build the part. If you followed the steps in the previous exercise, simply copy the new assembly into the in directory. There are no other steps required because you already gave it a strong name and modified the web configuration file.

After the web part is deployed and functioning, you'll need to create a list to act as a filter. After you create the list, you'll connect it to the web part. Once connected, you can select items in the list and filter the data shown in the web part.

Follow these steps to create the list:

Figure 10.8. Connected web parts