Best Practices to Improve Performance for SharePoint 2007 Sites

Some of the best practices for using Publishing Site are:

1. Keep Files UnCustomized - Try to keep your
files UnCustomized or on the server. Avoid editing them in SharePoint designer
or by using SharePoint API if not needed. Customizing the files can cost you
alot in terms of Performance and space as every Customized or Unghosted file in
is subjected to safe mode parser.Its basically, a little Check to see that
everything on the Page is allowed to run in SharePoint.


2. Avoid adding lot of WebParts on a single Page
- Check the closed webparts on your page and make sure you delete
them.

3. Memory Management-
Always, Dispose SPSIte and SPWeb Objects if you have created them in your code.
You can employ certain coding techniques to ensure object disposal. These
techniques include using the following in your code:

* Dispose
method

* using clause

* try, catch, and finally blocks

Note
: SPContext objects are managed by the SharePoint framework and should not be
explicitly disposed in your code. This is true also for the SPSite and SPWeb
objects returned by SPContext.Site, SPContext.Current.Site, SPContext.Web, and
SPContext.Current.Web.


4. Reduce the
Page Payload - SharePoint Page loads a lot of images from _layouts or
other various paths which can make the Page load a slow process. To avoid this
Payload you can use clustering or stitching, which combines multiple images into
a single image file. You can then use CSS to clip parts of the image, giving
users the impression that multiple images are being used.

5. Enable output caching for a site collection
- For each page request for which an output cached version of a page is
served, the server does not have to:
* Make a round trip to the database to
fetch the source code for the .aspx page and any .ascx controls on the
page.
* Reload and re-render the controls.
* Requery any data sources that
the controls rely on for data.
However, Output caching consumes additional
memory. Each version of a page consumes memory on the Web client.When used with
two or more front-end Web servers, output caching may affect consistency.

Using External Javascript, CSS or Image File in a WebPart of SharePoint

Button Testbutton;
Image img;
string imagePath;

//
Referring External Javascript
ClientScriptManager cs =
Page.ClientScript;
// Include the required javascript file.
if
(!cs.IsClientScriptIncludeRegistered("jsfile"))
cs.RegisterClientScriptInclude(this.GetType(),
"jsfile", "/_wpresources/MyWP/1.0.0.0_9f4da00116c38ec5/jsfile.js");

Test
:
Testbutton= new Button();
Testbutton.Text = "Click
me";
Testbutton.OnClientClick = "jsfile_Function()"; // specify function name
here
this.Controls.Add(Testbutton);

// Refering External CSS

Microsoft.SharePoint.WebControls.CssLink cssLink = new
Microsoft.SharePoint.WebControls.CssLink();
cssLink.DefaultUrl =
"/_wpresources/MyWP/1.0.0.0_9f4da00116c38ec5/styles.css";
this.Page.Header.Controls.Add(cssLink);

//
Using External Image
imagePath =
"/_wpresources/MyWP/1.0.0.0_9f4da00116c38ec5/Image.jpg";
img.ImageUrl =
imagePath;
img.ID = "image1";

this.Controls.Add(mybutton);

this.Controls.Add(img);







 

The Impersonation in Sharepoint 2007 (RunWithElevatedPrivileges)

Although not recommended, there may be times when you need your code to
perform certain functions that the current user does not have the necessary
permissions to perform.

The SPSecurity class provides a method
(RunWithElevatedPrivileges) that allows you to run a subset of code in the
context of an account with higher privileges than the current user.
The
premise is that you wrap the RunWithElevatedPrivileges method around your code.
And also In certain circumstances, such as when working with Web forms, you may
also need to set the AllowSafeUpdates method to true to temporarily turn off
security validation within your code. If you use this technique, it is
imperative that you set the AllowSafeUpdates method back to false to avoid any
potential security risks.

Code example

{
SPSite mySite = SPContext.Current.Site;
SPWeb
myWeb = mySite.OpenWeb();

//Using
RunWithElevatedPrivileges

SPSecurity.RunWithElevatedPrivileges(delegate()
{
//
Get references to the site collection and site for the current context.
//
The using statement makes sures these references are disposed
properly.

using (SPSite siteCollection = new
SPSite(mySite.ID))
{

using (SPWeb web =
siteCollection.OpenWeb(myWeb.ID))
{

web.AllowUnsafeUpdates =
true;

try
{
//Your code
}

web.AllowUnsafeUpdates =
false;

//siteCollection = null;
//web = null;

}

Retrieving large number of Items from sharepoint 2007 list

If you have to reterive a large number of Items and also need a better
performance then you should use one of the methods below :

1. Using SPQuery

2. Using PortalSiteMapProvider Class

Lets see the examples for both the methods :

Our Query - Query to get all the Items in a list where Category is "Sp2007"

SPQuery -

// Get SiteColl
SPSite curSite = new
SPSite("http://myPortal");

//Get Web Application
SPWeb curWeb = curSite.OpenWeb();

// Create a SPQuery Object
SPQuery curQry = new SPQuery();

// Write the query
curQry.Query = "<Where><Eq><FieldRef
Name='Category'/>
<Value Type='Text'>SP2007
</Value></Eq></Where>";

// Set the Row Limit
curQry.RowLimit = 100;

//Get the List
SPList curList = curWeb.Lists(new Guid("myListGUID"));

//Get the Items using Query
SPListItemCollection curItems = curList.GetItems(curQry);


// Enumerate the resulting items

foreach (SPListItem curItem in curItems)
{

string ResultItemTitle =
curItem["Title"].ToString();

}


PortalSiteMapProvider class -

The class includes a method called GetCachedListItemsByQuery that retrieves data from a list based on an SPQuery object that is provided as a parameter to the method call.
The method then looks in its cache to see if the items already exist. If they do, the method returns the cached results, and if not, it queries the list, stores the results in cache and returns them from the method call.


// Get Current Web
SPWeb curWeb = SPControl.GetContextWeb(HttpContext.Current);

//Create the Query
SPQuery curQry = new SPQuery();
curQry.Query = "<Where><Eq><FieldRef Name=\'Category\'/><Value Type=\'Text\'>SP2007</Value></Eq></Where>";


// Get Portal Map Provider

PortalSiteMapProvider ps = PortalSiteMapProvider.WebSiteMapProvider;

PortalWebSiteMapNode pNode = TryCast (ps.FindSiteMapNode (curWeb.ServerRelativeUrl), PortalWebSiteMapNode);

// Get the items
pItems = ps.GetCachedListItemsByQuery(pNode, "myListName_NotID", curQry, curWeb);

// Enumerate all resulting Items
foreach (PortalListItemSiteMapNode curItem in pItems)
{
string ResultItemTitle = curItem["Title"].ToString();
}

SharePoint 2007 Object Model

In Sharepoint Object model there are two Important namespaces.

The Microsoft.Office.Server namespace is the root
namespace of all Office Server objects and Microsoft.SharePoint is the root namespace
for all WSS objects.

The Chart Below illustrates some of the key classes
contained in each of these namespaces, as well as to which functional area they
belong.

Document Libraries (Microsoft.SharePoint)
SPDocumentLibrary ,
SPPictureLibrary

Business Data Catalog
(Microsoft.Office.Server.ApplicationRegistry.Administration)
EntityCollection ,
ApplicationRegistry

Features (Microsoft.SharePoint)
SPFeatureDefinition, SPFeatureScope,
SPElementDefinition, SPFeature, SPFeatureProperty

Sites
(Microsoft.SharePoint)
SPSite,
SPSiteAdministration, SPSiteCollection, SPWeb

Meetings
(Microsoft.SharePoint.Meetings)
SPMeeting, MtgUtility

User Profiles
(Microsoft.Office.Server.UserProfiles)
UserProfile,
UserProfileManager

Solutions
(Microsoft.SharePoint.Administration)
SPsolution, SPFeatureReceiver,
SPSolutionCollection

Lists (Microsoft.SharePoint)
SPList, SPListItem,
SPListItemCollection

Notes:
* To use the SharePoint API, your
code must reside on one of the machines in a SharePoint
application server
farm. Your code can still work with other sites in the farm from any
other
site in the farm, but you cannot, for example, work with the SharePoint API from
a
machine on which MOSS or WSS is not installed.

* The only practical
way to consume SharePoint data and functionality from a remote client is to use
the SharePoint web services.

* The object model is not designed to
support Remoting.

* To add a reference to a Sharepoint API, Right-click
the project(in VS) and select Add Reference. Click the Browse tab and select
the
following directory:
C:\program files\common files\microsoft
shared\web server extensions\12\isapi

Other Related Posts:

SharePoint 2010 Object model

The Backward Compatibility of SharePoint 2010 Object Model

The Backward Compatibility of SharePoint 2010 Object Model

Some Important things about SharePoint 2010 Object model and its backward
compatibility.

Microsoft SharePoint
Foundation 2010 and Microsoft SharePoint Server
2010 contain object model upgrades that are designed to be compatible with
existing solutions developed for Windows SharePoint Services 3.0 and
Microsoft Office SharePoint
Server 2007. Some namespaces, classes, and methods are now obsolete, but they
are still available and will continue to work as expected in your custom
code.

You can synchronize your customizations and applications with the
upgraded versions of Microsoft SharePoint
Foundation 2010 and Microsoft SharePoint Server
2010 after you have redeployed them.

The object model contains many
changes and enhancements, but your custom code will still compile and, with one
potential exception, it will run as expected. If in case, any of your
customizations rely on list queries that can generate result sets in excess of
5,000 items or that scan all rows of lists that consist of more than 5,000
items, you must change the query size threshold.(See Later in the
Post)..

Note: You must Re-compile or re-write your code in
below conditions:

* You should rewrite and recompile any code that refers
to files and resources in "12" hive.For example, if you have redeployed all of
your files into the "14" folder and emptied your "12" folder, any references to
files under the "12" folder will not work. You will need to rewrite your code to
refer the files in "14 Hive" instead of "12 Hive" to make it
work.

* You must
recompile custom code written for Windows SharePoint Services 3.0 and Office
SharePoint Server 2007 that does not run on IIS (such as console applications
and services).

* You should
recompile custom code written for Office SharePoint Server 2007 if your solution
includes a feature receiver that implements the FeatureInstalled, FeatureUninstalling, FeatureActivated, or FeatureDeactivating methods and you are deploying by using either the
Stsadm command-line tool or the timer service.



Lets Look at some of the custom solutions that you would be
moving to SharePoint 2010.


Moving
Using Solution Packages (.wsp Files)

You can simply deploy them as we did in SharePoint 2007. You dont need to recompile them(unless, your code has references to 12 hive). If however, you want to start upgrading your applications so that they use the most current classes and methods, you should recompile your code. The compiler warnings will tell you which elements of the object model are obsolete, and which newer alternatives you should use.


Moving Using Windows Installer
Files

If you deploy your custom solutions by using Windows
Installer (.msi) packages, be sure to change them so that your custom files are
deployed to their correct locations in the "14" folder. This is especially true
if you are deploying files to locations other than the TEMPLATE\FEATURES
folder.


Moving Site
templates

Site
templates are deprecated. If you
need to redeploy a site template to either SharePoint Foundation 2010 or
SharePoint Server 2010, follow these steps:

1. Create a site from the
site template.

2. Install SharePoint Foundation 2010 or SharePoint Server
2010 on your existing server farm or on a new server farm. If you install the
upgrades on a new server farm, attach the content database that contains the
site that you created to the new farm.

3. On the new installation, choose
Save Site as Template from the Site Settings page. This creates a solution
package with a .wsp file name extension.


CSS Changes :

When you upgrade to either
SharePoint Foundation 2010 or SharePoint Server 2010, you are able to choose
either backward compatibility mode or the upgraded user interface. You can
however, switch between backward compatibility mode and the new interface at the
site-collection level or site level.

Since, the UI has changed
significantly in both SharePoint Foundation 2010 and SharePoint Server 2010, any
customizations(made to SharePoint 2007 CSS) that rely on specific CSS classes
and UI elements will work only in backward compatibility mode.

A property
SPWeb.UIVersion is also available for developers, to
programmatically get or set the UI version (3 for backward
compatibility mode and 4 for the new
interface).


Themes:

Themes no longer exist in
SharePoint Foundation 2010 and SharePoint Server 2010, so any customizations and
design work that you have done with themes will not be imported into the new
interface.


Custom Actions and Toolbar
Additions:

Most custom actions, including those targeted at links
and edit control block (ECB) menus, continue to work as expected in the upgraded
interface. Because the toolbar is replaced by the ribbon, most custom actions
that add buttons to a toolbar will be
placed in the Custom Commands tab of
the ribbon.

Note : Any Custom Action Element that uses the
ControlAssembly attribute, the ControlClass attribute, or the ControlSrc
attribute, however, will not appear in the new interface.


Site definition :

Migrate sites to a supported, predefined site definition, then apply custom
features by using solution deployment.

You can also continue to use a custom site definition. You do not have to
create a new site definition based on SharePoint Server 2010.

Event handler : Rewrite and redeploy as a
feature.


JavaScript : In some
cases, you might have to adjust the scripts to work with the new page model.
Verify that it works on an upgraded site, and in both Visual Upgrade modes.


Conclusion:

Because the changes to the
API in the upgrades are backward compatible, you should not have to make any
changes to your custom code before you redeploy it in either SharePoint
Foundation 2010 or SharePoint Server 2010. All deprecated elements of the API
continue to be available to you, so that you have time to review the newer
elements of the API before incorporating them into your customizations.

SharePoint 2010 Object Model introduction

Microsoft has replaced the "12 hive" structure that we had in
SharePoint 2007 with "14 Hive" structure in 2010.

It has apparently added
four new folders to its hive.

The Folders are :
* Policy
*
UserCode
* WebClients
* WebServices

See the Details at : 14 hive Directory structure of SharePoint 2010

In Sharepoint 2010 This is a step-by-step
tutorial to learn using sharepoint 2010′s Server and client object
model.
Server Object Model –

Here we will look at how to use
SharePoint API's, LINQ, REST and SharePoint web service to extract data from
sharepoint server.

Lets Start with using the API's in
Microsoft.SharePoint and Microsoft.SharePoint.Utilities
namespaces.

Firstly, to work with SharePoint 2010 components, your code
must first establish the site context or site collection context for requests
that are made to the server.

Please Note : In SharePoint, the SPsite
object also refered to as Site is actually a "Site Collection" object, not a
website
and the SPweb object also refered to as "web" is a single site in the
site collection.(It can be a top-level site collection site).
also, object of
type SPWebApplication is a big boss object which has reference to the web
applictaion that contains the site collection.

To get the reference to
site context in your code use the recommended Microsoft.SharePoint.SPContext
class and its members.

Lets look at how it is used

To get a
reference to the site collection -

SPSite oSiteCollection =
SPContext.Current.Site;

To get a reference to the current web site or web
in the site collection -

SPWeb oWebSite =
SPContext.Current.Web;

or

SPWeb oWebSite =
SPControl.GetContextWeb(Context);

Note : if your are using
Microsoft.SharePoint.SPContext class, you should not dispose any SPSite or SPWeb
object obtained
by any of the above methods. The SharePoint Foundation
runtime will dispose of them after page completion.

To get a reference to
all the webs or sites in a site collection -

SPWeb oWebSite =
SPContext.Current.Site.AllWebs["mySite1"];

oWebSite.Dispose();

Note
: You should explicitly dispose of references to objects that are obtained
through the AllWebs() or Openweb() property. You can also use using
clause
like below to avoid calling the dispose off method and let sharepoint
do this for you.

using can be something like

using (SPWeb oWebSite
= SPContext.Current.Site.AllWebs["mySite1"]);
{
…
}

You can also
use the Openweb() as below

using (SPWeb oWebSite =
mySiteCollection.OpenWeb("mySite1″))
{
…
}

Lets look at some
other components of the SharePoint farm that you can get using
SPContext

To get a reference to the current top-level server farm object
-

SPFarm myFarm = SPContext.Current.Site.WebApplication.Farm;

To
get a reference to the site collection database -

SPSite oSiteCollection
= SPContext.Current.Site.CurrentDatabase

Lets look at some of the general
code snippets

To return the collection of site collections in a
SharePoint Web application -

SPWebApplication webApplication =
SPContext.Current.Site.WebApplication;

using (SPSiteCollection
siteCollections = webApplication.Sites)
{

foreach (SPSite
siteCollection in siteCollections)
{
Label1.Text += siteCollection.Url +
"
";

siteCollection.Close();
}

}

Note : To runthe
above code reference the Microsoft.SharePoint.Administration.SPWebApplication
assembly in your code.

To return the collection of The all the Webs or
sites within a site collection, including the top-level site and all
subsites.

SPSite oSiteCollection =
SPContext.Current.Site;
using(SPWebCollection collWebsite =
oSiteCollection.AllWebs);
{

for (int i = 0; i < collWebsite.Count;
i++)
{
using (SPWeb oWebsite = collWebsite[i])
{
SPListCollection
collList = oWebsite.Lists;

for (int j = 0; j < collList.Count;
j++)
{
Label1.Text += SPEncode.HtmlEncode(collWebsite[i].Title) + " "
+
SPEncode.HtmlEncode(collList[j].Title) + "
";
}
}}}

To return
the all the subsites and lists of the current site

using (SPWeb oWebSite
= mySiteCollection.OpenWeb())
{

using(SPWebCollection subSites =
oWebsite.Webs)
{

foreach (SPWeb subSite in
subSites)
{
Label1.Text += SPEncode.HtmlEncode(subSite.Title) +
"
";

SPListCollection collList = subSite.Lists;

foreach (SPList
oList in collList)
{
Label1.Text += SPEncode.HtmlEncode(oList.Title) + " "
+
oList.ItemCount.ToString() + "
";

}subSite.Close();
}
}}

Developer: 12 hive folder structure in sharepoint 2007

Few things about 12 hive folder structure and how well it is mapped with the wsp
schema.
SharePoint 2007 have a 12 hive structure which basically contains
various files and folders that make SharePoint Interface. The files under 12
hive are mostly Uncustomized, that means they stay on the file system rather
than in SharePoint database and perform better while rendering the
Pages.

You would normally, deploy your Custom files like Custom
Pages\layouts, webparts, css or javascript files under 12 hive, so that they can
well interact with SharePoint site.

12 hive in SharePoint 2007 has
various folders that make up a virtual path for the resources they contain. For
e.g to access a CSS file deployed under styles folder we can use a path
like
/_layouts/1033/styles/Customcss.css.

The most commonly used
folders are :

\ISAPI\HELP\[LCID] - SharePoint help files. Deploy your own
.chm files to this folder (or a localized subfolder)

\CONFIG - Web.config
customizations

\ISAPI - SharePoint web services (deploy your custom web
services here); this maps to /_vti_bin.

\Resources Global .resx - Files
accessed from custom features and site
definitions

\TEMPLATE\CONTROLTEMPLATES - deploy .ascx user controls here;
maps to /_controltemplates

\TEMPLATE\FEATURES - Features contain folder
and related file for each feature.

\TEMPLATE\LAYOUTS - Common site pages;
maps to /_layouts

\TEMPLATE\IMAGES - Common site image files; maps to
/_layouts/images

\TEMPLATE\SiteTemplates - All SharePoint site
definitions; create a \xml to deploy your onet.xml custom site
definition

\TEMPLATE\THEMES - All UI elements used in themes; clone an
existing theme folder to create your own

\TEMPLATE\[LCID]\XML -
Webtemp.xml files to define available site definitions; add an xml file here for
your custom site definition

\TEMPLATE\ADMIN Pages - Used by Central
Admin; maps to /_admin

\ADMISAPI Administration web services; maps to
/_vti_adm

Now lets discuss the most commonly used Folder in SharePoint
development.

TEMPLATE Folder - The most commonly used folder in 12 hive
is the template folder or 12\TEMPLATE\. This is where developers deploy all of
there custom files like Custom css, javascript file, Image file, Usercontrol,
Custom aspx page, layouts page etc. etc.. These Custom files then run under
SharePoint context and can well interact with Out-of-Box sharePoint
components.

Now, lets talk about how a wsp (or solution package)
interacts with the 12 hive - When you deploy a Solution using stsadm or Visual
Studio( using VseWss), SharePoint copies various files from the WSP to the hive.
The file responsible in wsp to perform various deployments\copying is the
"manifest file".The manifest.xml file specifies how the WSP file is put
together.
So, when the deployment starts the sharepoint compiler looks for
the first tag i.e the <solution >
tag. This tag tells sharepoint about the
solution id that uniquely identifies your solution.

Next it looks for the
<FeatureManifest> tag. This location however, is
virtually mapped to the root of the FEATURES folder at 12 hive i.e to
12\TEMPLATE\FEATURES. So, the SharePoint compiler reads this location and
creates a Cutsom Folder usually specified in <FeatureManifest>
tag and places the feature.xml file
into that folder.

Next it looks for <TemplateFile> tag. This location is virtually
mapped to the root of the TEMPLATE folder i.e. at 12\TEMPLATE. This tells
compiler to deploy the files specified under this tag, into one or more folder under
template directory.
For e.g. if <TemplateFile> tag has location as
Location="Layouts\CustomPage.aspx", the installer will drop the file
CustomPage.aspx under the Layouts folder, since it is already pointing to the
root of the Layouts folder Tempalte folder.

Finally, the installer looks
at the <Assemblygt; tag which specifies where the DLL
is located. The root for this element is the web application bin file if you
specify DeploymentTarget="WebApplication", and the GAC if you specify
DeploymentTarget="GlobalAssemblyCache".

While the manifest determines
what's in the WSP file, you still have to create a diamond definition file also
known as .ddf file which is an instruction file for building WSP files. However,
if you are using VseWSS you will not create all the deployment files manually.
The extentions take care of that.

Sharepoint 2010 of 14 hive directory structure introduction

Microsoft has replaced the "12 hive" structure that we had in
SharePoint 2007 with "14 Hive" structure in 2010.

Some of the folders in
14 hive are :

Program Files\Common files\Microsoft Shared\Web Server
Extensions\14 -
This directory is the
installation directory for core SharePoint Server files.

Program
Files\Common files\Microsoft Shared\Web Server
Extensions\14\ADMISAPI -
This
directory contains the soap services for Central Administration. If this
directory is altered, remote site creation and other methods exposed in the
service will not function correctly.

Program Files\Common
files\Microsoft Shared\Web Server
Extensions\14\CONFIG -
This directory
contains files used to extend IIS Web sites with SharePoint Server. If this
directory or its contents are altered, Web application provisioning will not
function correctly.

Program Files\Common files\Microsoft Shared\Web Server
Extensions\14\LOGS -
This directory
contains setup and run-time tracing logs.

Other newly added folders are
:

Program Files\Common files\Microsoft Shared\Web Server
Extensions\Policy -


Program
Files\Common files\Microsoft Shared\Web Server
Extensions\UserCode -
This directory
contains files used to support your sandboxed solutions.

Program
Files\Common files\Microsoft Shared\Web Server
Extensions\WebClients -
This directory
contains files related to the new Client Object Model.

Program
Files\Common files\Microsoft Shared\Web Server
Extensions\WebServices -
This
directory contains new wcf or .svc related files.

Note : You should
rewrite and recompile any code that refers to files and resources in "12" Hive
structure.For example, if you have redeployed all of your files into the "14"
folder and emptied your "12" folder, any references to files under the "12"
folder will not work.

See more details @ 14 hive and other directories of SharePoint 2010

SharePoint 2007 Object Model

In Sharepoint 2007 Object model there are two Important namespaces.

The Microsoft.Office.Server namespace is the root
namespace of all Office Server objects and Microsoft.SharePoint is the root namespace
for all WSS objects.

The Chart Below illustrates some of the key classes
contained in each of these namespaces, as well as to which functional area they
belong.

Document Libraries (Microsoft.SharePoint)
SPDocumentLibrary ,
SPPictureLibrary

Business Data Catalog
(Microsoft.Office.Server.ApplicationRegistry.Administration)
EntityCollection ,
ApplicationRegistry

Features (Microsoft.SharePoint)
SPFeatureDefinition, SPFeatureScope,
SPElementDefinition, SPFeature, SPFeatureProperty

Sites
(Microsoft.SharePoint)
SPSite,
SPSiteAdministration, SPSiteCollection, SPWeb

Meetings
(Microsoft.SharePoint.Meetings)
SPMeeting, MtgUtility

User Profiles
(Microsoft.Office.Server.UserProfiles)
UserProfile,
UserProfileManager

Solutions
(Microsoft.SharePoint.Administration)
SPsolution, SPFeatureReceiver,
SPSolutionCollection

Lists (Microsoft.SharePoint)
SPList, SPListItem,
SPListItemCollection

Notes:
* To use the SharePoint API, your
code must reside on one of the machines in a SharePoint
application server
farm. Your code can still work with other sites in the farm from any
other
site in the farm, but you cannot, for example, work with the SharePoint API from
a
machine on which MOSS or WSS is not installed.

* The only practical
way to consume SharePoint data and functionality from a remote client is to use
the SharePoint web services.

* The object model is not designed to
support Remoting.

* To add a reference to a Sharepoint API, Right-click
the project(in VS) and select Add Reference. Click the Browse tab and select
the
following directory:
C:\program files\common files\microsoft
shared\web server extensions\12\isapi