Deploying an ASP.NET Web Part to WSS
Deploying your custom Web part into a WSS environment is quite simple and in fact is identical for both environments. First you have to decide where you want your Web parts assembly to be kept. As with all .NET applications you can choose either the Sharepoint applications Bin directory or the Global Assembly Cache (GAC).

Note that if you choose to keep the Web parts assembly in the Bin directory, you have to add the AllowPartiallyTrustedCallers attribute to the assembly's AssemblyInfo file. This is because the Bin directory isn't a full trust location, so you need to tell .NET to allow your assembly additional rights.

[assembly: AllowPartiallyTrustedCallers()]

Once your assembly is in place, you need to tell WSS that it's safe to load the Web parts in the assembly. WSS works on an opt-in model, only loading Web parts from assemblies that are explicitly listed as safe. To do this, all you have to do is add an entry to the SafeControls section of the WSS application's Web.config file. If you're using the default root instance of WSS, then the application root should be: C:\Inetpub\wwwroot\wss\VirtualDirectories\80

Once you've found the Web.config, open it and locate the <SafeControls> config section and add the following entry, substituting your assembly name and namespace in:

<SafeControl Assembly="InfragisticsGuidanceSharepoint" Namespace="Infragistics.Guidance.Sharepoint"
TypeName="*" Safe="True" />

The final step in adding the custom Web part to WSS is create a .Webpart file, which is a small XML file that describes your Web part to WSS. WSS can create it for you automatically. Simply navigate to http://MyServer/_layouts/newdwp.aspx and you should see the Web part you added to the Bin directory listed. Simply check the checkbox located next to the Web Part type and click the Populate Gallery button. You should now see your custom Web part listed in the Web Part Gallery, and the part is now available for use by your WSS users.

Figure 3 demonstrates the same Web part used in a SharePoint portal Web site. You can see that it appears identical to its use in the ASP.NET portal framework. And, because it's being used in the SharePoint site, it inherits all of the normal SharePoint WebPart behavior.

Adding WSS-Specific Functionality
Now that you've seen how easy it is to create a basic Web part you can use in any of the Microsoft Web portals, let's take a look at how you can integrate SharePoint-specific features into the Web part. SharePoint includes a rich set of APIs that you can use in your Web part simply by adding a project reference to the Microsoft.Sharepoint.dll assembly.

Note: The Microsoft.Sharepoint.dll assembly is installed with WSS so to add it as a project reference you either need to be developing on a machine that has WSS installed or you can copy the assembly to your development machine from your WSS server.

The Windows SharePoint Services SDK includes a help library that offers documentation for the public SharePoint APIs. See Click Here!.

Once you've added the assembly reference to your project, you can add the necessary using statements to your Webpart class:

using Microsoft.SharePoint;
using Microsoft.SharePoint.WebControls;
using Microsoft.SharePoint.WebPartPages;

Now you can begin to add Sharepoint-specific features to the Web part. For example, you could customize the previous sample to include a greeting for the currently logged in user:

SPSite site = SPControl.GetContextSite(Context);
SPWeb Web = site.OpenWeb();

output.RenderBeginTag(HtmlTextWriterTag.P);
output.Write("{0}'s Top Stories", Web.CurrentUser.Name);
output.RenderEndTag();

In this case, you can use the SPSite and SPWeb objects to get a reference to the currently open SharePoint Web site. From there the sample adds a caption to the Web part that includes the current users Name.

Using the SharePoint APIs can add significant power to your custom Web parts, from creating new SharePoint Sites and Users to retrieving list and document information, they let you create powerful and flexible Web parts.

Deriving from the SharePoint WebPart Base Class
Although Microsoft recommends that you create ASP.NET 2.0 Web parts whenever possible, there are certain situations where you need to integrate specific types of SharePoint functionality into your Web parts that require you to derive from Microsoft.SharePoint.WebPartPages.WebPart. The SharePoint SDK documentation lists the four reasons you'd want to derive from the SharePoint WebPart base class as:
  •   You need to use cross-page connections
  •   You need connections between Web parts that are outside of a Web part zone
  •   You need client-side connections (Web Part Page Services Component)
  •   You want to leverage the data caching infrastructure that allows caching to the content database

If you want to use any of these features you need to make sure your Web Part class derived from Microsoft.SharePoint.WebPartPages.WebPart.

Embedding Client-Side Script in a Web Part
Since SharePoint is a Web-based technology, you may eventually need to write a Web part with JavaScript-based client-side functionality. In older versions of SharePoint dealing with this was quite painful, but beginning with WSS 3.0, you can simply change the script files Build Action property to "Embedded Resource" and use ASP.NET's WebResource assembly attribute.

[assembly: WebResource("Infragistics.Guidance.Sharepoint.SimpleWebPartSample.js", "text/javascript")]

Now in your Web Part class you can register the JavaScript resource in the Web Parts OnPreRender event:

protected override void OnPreRender(EventArgs e)
    {
base.OnPreRender(e);

Page.ClientScript.RegisterClientScriptResource(this.GetType(),
"Infragistics.Guidance.Sharepoint.SimpleWebPartSample.js");
       }

This sample shows the use of ASP.NET's RegisterClientScriptResource method, which is used to register the JavaScript resource with the Web page.

Wrap Up
Portals continue to grow as a popular way to create Web sites that let end users create customized content aggregators and facilitate collaboration. And Microsoft ASP.NET WebParts Framework and SharePoint products offer great solutions for building portal applications. The flexible and powerful Web parts architecture lets you extend your portal with custom Web parts using the same basic control development techniques you're already familiar with, while at the same time leveraging the power and infrastructure Microsoft provides in its APIs.