Sharepoint dll location

Physical location of Sharepoint dll is :


C:\Program Files\Common Files\Microsoft Shared\web server extensions\12\ISAPI

Enjoy..............

Site Defination and its component

Site Definitions in SharePoint 2007

For one of our clients we need to build custom site definitions. When building SharePoint solutions the terms site template, definition and to a lesser extent site portal are often used. Each of these allows the user to create a new site with a predefined set of Content Types, Layouts, and Lists etc. In the case of the Portal, it allows the user to create a site and one or more nested child sites.

Site definitions are our preferred way to develop custom sites. A portal definition is a variation of the Site Definition except that the definition describes a series of sites to be created. An example of this is the Site Collection Publishing Template, which creates a root site collection, a News sub site, a Documents sub site and some others.

The focus of this article is on how site definitions and Portal definitions can be created and deployed. Site definitions are usually deployed as a part of a solution package, which is a compressed cabinet file made up of XML files and other resources. Solution packages are first added and then deployed to the MOSS farm. Once deployed the contents of the solution can be made available to sites, or used to create new sites.

The Solution Package can also deploy Site Features. A Site Feature can do myriad things, such as deploying a new web part, defining a new content type, site column, list type, adding a new page layout, or even a graphic image. Site Features can then be activated in a site, or automatically applied in a new site definition. We typically deploy several features as part of the new site definition, as this allows multiple developers to work together without interfering with one another. The solution and feature methodology is a powerful new model for MOSS and is used by Microsoft to build and extend MOSS.


CREATING A SITE DEFINITIONTo create a site definition the first step is to create the “WebTemp” file. The purpose of the webtemp file is to describe to SharePoint the new Site Definition or Site Portal Definition. After the WebTemp file, the Site Definition file should be created, this is known as the ONET.XML file. Each Site Definition contains one or more configurations of lists and features. A site Definition can also point to a Portal Definition. The portal definition uses one or more site definitions. The relationship of files is shown below:

WEBTEMP FILE
All the webtemp files are XML files which live in the <12-hive>\TEMPLATES\1033\XML. The webtemp file can be thought of as Meta data or a description of a Site Definition. For example, the file contains the name of the site definition, as displayed in the Create Site page in a site or the Create Site Collection page in Central Administration.

Each Site Definition description is in a <Template> node that contains one or more configuration nodes. The name assigned to a Template must match the name of a directory in the <12-hive>\TEMPLATE\SiteTemplates directory. SharePoint then looks for the ONET.XML file in a subdirectory called XML to find the actual Site Definition. The ID of the Template must be unique across the SharePoint installation. The following is a sample template definition:

<Template Name="SPPR" ID="10856">

    <Configuration ID="0"

         Title="Syrinx Root"

         Description="This site is intended to be the root site collection for a Syrinx portal."

         Hidden="TRUE"

         ImageUrl="/_layouts/images/stsprev.png"

         DisplayCategory="Syrinx"

         RootWebOnly="True"/>

</Template>

The Configuration declaration can define if the site definition can be used for a site root collection only, a sub web site only or both. This provides a level control on how the site definition can be used, and provides a mechanism to control how certain features are enabled.
In the case of a Portal definition, the webtemp template configuration adds some additional attributes:

<Template Name="SyrinxPortal" ID="10855">

    <Configuration ID="0"

        Title="Syrinx Portal Site"

        Type="0"

        Hidden="FALSE"        ImageUrl="/_layouts/1033/images/template_corp_intranet.png"

        Description="This site is the definition of the Syrinx Portal collection."

        ProvisionAssembly="Microsoft.SharePoint.Publishing, Version=12.0.0.0, Culture=neutral, PublicKeyToken=71e9bce111e9429c"

       ProvisionClass="Microsoft.SharePoint.Publishing.PortalProvisioningProvider"

        ProvisionData="SiteTemplates\\WebManifest\\PortalWebManifest.xml"

        RootWebOnly="TRUE"

        DisplayCategory="Syrinx"/></Template>

The attributes of interest are the ProvisionAssembly, ProvisionClass and ProvisionData. When creating a Portal site the class specified by the ProvisionClass attribute is called in the assembly specified by the ProvisionAssembly. The class is passed the value of the ProvisionData attribute as a parameter. Microsoft provides an implementation of a Provisioning Class. The Microsoft Provisioning Class (MPC) is used to create a Portal Site.

The MPC expects the ProvisionData value to be the path to an XML file, which contains instructions on the sites to create as part of the Portal Definition. This methodology is used to create the Publishing Site, which creates several sub sites. By looking in the PortalWebManifest.xml file specified above, it can be seen that four sites are created, News, Site Directory, Search Center, and Document center. Below is a sample Syrinx Portal Provisioning Data XML file.

  <portal xmlns="PortalTemplate.xsd">

    <web name="Syrinx Root"

         siteDefinition="SPPR#0"

         displayName="Syrinx Portal Display Name"

         description="Syrinx Watch Portal Description">

      <webs>

        <web name="NorthEast"

             siteDefinition="SPRegion#0"

             displayName="North East"

             description="North East Site Description">

          <webs>

            <web name="Massachusetts"

                 siteDefinition="SPState#0"

                 displayName="Massachusetts"

                 description="Massachusetts Site Description"/>

          </webs>

        </web>

        <web name="SouthEast"

             siteDefinition="SPRegion#0"

             displayName="South West"

             description="South West Site Description"/>

      </webs>

    </web>

  </portal>

This file declares the top-level site that is to be created, and it uses the SPPR#0 site definition. This is a reference back into the webtemp files; it is referencing a site definition template called “SPPR” and from that definition use configuration “0”, the display name and description of the root level site are overwritten by the values entered by the user when the site is created.  Nested below this site, are two child sites that use configuration 0 from the SPRegion site definition, the North East and South East regional sites. Below the North East regional site is a sub site called Massachusetts, which uses configuration 0 from the SPState site definition.

ONET.XML FILEThe onet.xml file contains the actual site definition and is broken in to several sections, navigational areas, list templates, document templates, configurations, modules, components, and server e-mail footer. The MSDN documentation provides an good reference on the structure and contents of an onet.xml file (seehttp://msdn2.microsoft.com/en-us/library/ms474369.aspx). The best way to create a new onet.xml file is to copy one from the site templates directory which is close to what you need and then modify it to suit your needs. Below is an overview of the sections within the onet.xml file.

Click here for more details

The wrong way to iterate through SharePoint SPList Items

Lets start by looking at a code snippet that can be used in a WebPart to access the first 100 items from the SharePoint list of the current context:

SPList activeList = SPContext.Current.List;
for(int i=0;i<100 && i<activeList.Items.Count;i++) {
  SPListItem listItem = activeList.Items[i];
  htmlWriter.Write(listItem["Title"]);
}

Assuming that there are at least 100 items in the list. How many roundtrips to the database is this code going to make in order to retrieve the 100 Title’s of the first 100 SharePoint list items? You might be surprised. Its a total of 200 database calls as you can see from the database view when analyzing the transaction executing the above code:

200 SQL Statements get executed when iterating through SPList.Items

The reason for that is because in every loop we request a new SPListItemCollectionobject when accessing the Items property. The Items property is not cached and therefore always requests all items from the database again. Here is how the first loop iterations look like in the PurePath:

Every access to the Items property executes the same SQL statement again

The CORRECT way to do it

The correct way to do it is of course to store the Items property return value in a SPListItemCollection variable. With this the database is only queried once and we will then iterate over the result set that is stored within the collection object. Here is the changed sample code:

SPListItemCollection items = SPContext.Current.List.Items;
for(int i=0;i<100 && i<items.Count;i++) {
  SPListItem listItem = items[i];
  htmlWriter.Write(listItem["Title"]);
}

Resulting in the following PurePath.

Storing the Items property in a variable elminiates 99.5% of the database calls

Conclusion

Many properties in SharePoint return new object instances every time you access them. In order to build good software based on the Microsoft SharePoint Platform its necessary to understand what is going on under the hood. This will eliminate “surprises” once your custom code is first executed with real life data.

There are additional ways to optimize access to data stored in SharePoint lists. I will cover that in my next posts.

Add item to splist

Here is the code snippet:


using(SpSite site=new SPSite("Server"))
{
using(SpWeb web=site.OpenWeb())
{
SpList list=web.Lists["ListName"];
SpListItem item=list.Items.Add();

item["Title"] = "testTitle";

item["Description"]="test"; 

item.Update();

}
}

Enjoy

When should I use SPSecurity.RunWithElevatedPrivileges?

It is very importent to understand why and when to use SPSecurity.RunwithElevatedPrivilages.When we want to retrive or update the data where a normal user don't have permission,there we use this code segment. How this exactly works is like SPSecurity.RunWithElevatedPrivileges runs current process under application pool identity and it allows users to add/update item in list,library or site.


Example 

SPSecurity.RunWithElevatedPrivileges(delegate()
{
    using (SPSite site = new SPSite(web.Site.ID))
    {


      // site will be based on the rights for the system account

    }

});

For more details click here

Base class used while creating a webpart

There are two base classes which are going to be consumed by sharepoint can inherit from, either the sharepoint base class or ASP.NET2.0 Webpart base class.When inheriting from sharepoint base class your derived webpart will inherit from Microsoft.Sharepoint.WebPartPages.WebPart base class. When ingeriting from ASP.Net 2.0 webpart base class, your derived webpart will use System.Web.UI.WebControls.WebParts.WebPart . It is preferable to use ASP.NET base class as old base class is meant of backward compatibility  with previous version of sharepoint.However there are four exception when it is better to leaverage functionality from sharepoint webpart base class.
These are the scenarios:

1. Cross Page connection.
2. Connection between webpart that are outside webpart zone.
3. Client side conection.
4. data-cachieng infrastructure

for any further detail,you can post your query.

Sharepoint 2010 enhancements

Sharepoint 2010 is very dynamic and more user friendly portal.

User interface:Microsoft has worked very hard on this control.This makes easy access to your need on List,Library or pages.For details click here

Developer view: from developer point of view also this has enlarged on very large scale.Like we have more classes,Web Parts and sevices.For more details click here.