Submitted By: Bob Mixon, MSD2D SharePoint Community Manager and Managing Director/ShareSquared, Inc.
Posted On: 3/5/2007

In the tip Custom Web Part Basics, we walked through the steps of creating a simple Web Part base class that you can use in your own common library.  The purpose of creating such a base class is to give you the flexibility to include common features such as error and informational logging, debugging, and so forth.  Before we add any error and information logging features, lets first put our Web Part base class to use by creating and registering a simple Web Part and placing it on a Web Part page.  We can then use this test Web Part as we further enhance the base class feature set.

To get started, open Microsoft Visual Studio (VS) 2005and create a new class library project.  I named mine S2.TestWebPartBase.  This new solution will contain two projects--S2.TestWebPartBase and S2.Web (our Web Part base project from the tip, Custom Web Part Basics).  Your VS solution explorer should look like that in Figure 1:

The TestWebPartBase.cs class is a very simple Web Part that's based on our WebPartBase class.  In the source file, implement the following code:

using System;

using System.Collections.Generic;

using System.Drawing;

using System.Text;

using System.Web.UI.WebControls;

using S2;

namespace S2.TestWebPartBase

{

public class TestWebPartBase :

S2.Web.UI.WebControls.WebParts.WebPartBase

{

private Label _label = null;

protected override void CreateChildControls()

{

const string PROC = "CreateChildControls";

int result = 0;

int value = 0;

try

{

// Will throw a 'divide by 0' exception.

// Comment out to see Web Part without exception.

result = 0 / value;

_label = newLabel();

_label.Text = "This is a test";

this.Controls.Add( _label );

}

catch( Exception ex )

{

this.LogError( PROC, ex );

}

}

}

}

Before we can test our new Web Part, we need to copy the S2.Web.dll and S2.TestWebPartBase.dll assemblies to the bin directory associated with a SharePoint Web application.  In addition, we need to register these as safe in the web.config file.

To keep things simple, you can specify a post-build event command line that is executed each time your project is successfully compiled. I recommend that you specify this command line with the SP.TestWebPartBase assembly because this will ensure both assemblies are successfully compiled first (i.e., S2.TestWebPartBase depends on S2.Web, so S2.Web will be compiled first.)

Place the following command line in the S2.TestWebPartBase project post-build event:

xcopy "*.dll" "C:\Inetpub\wwwroot\wss\VirtualDirectories\SSP1\bin" /y

as Figure 2 shows.



Make sure to change the destination bin directory to the location of your SharePoint Web application.  Now build your solution.  After you have a successful build, check the SharePoint Web application bin directory and make sure the xcopy operation was successful.

Now  register these assemblies/namespaces as safe in the SharePoint Web application web.config file.  Before you make any changes to the web.config file, I highly recommend you make a backup copy; any mistakes made in this file will render your SharePoint Web application unusable. Your web.config file should contain two new safe control entries as Figure 3 shows.



If all went well, which I'm sure it has, you should be able to open SharePoint and place an instance of your new Web Part on a Web Part page.  After adding it, you should see the "divide by zero" error message, as Figure 4 shows.



So why do we go through all these steps?  I'm hoping it will all become clear as we move forward with expanding our Web Part base class.  In general, we'll first be expanding on common error handling and logging so that our Web Part can communicate what's happening to our users without delivering a cryptic broken page message.  When something fails in one of my Web Parts, I don't want it to have a negative impact on other SharePoint functionality.