What is SharePoint?
· Microsoft SharePoint is a browser-based collaboration and document management platform from Microsoft - Wikipedia
· Microsoft's content management system. It allows groups to set up a centralized, password protected space for document sharing. Documents can be stored, downloaded and edited, then uploaded for continued sharing. - SAIT Polytechnic Teaching - Glossary
· SharePoint is a web-based intranet that can help improve your organisation's effectiveness by streamlining the management of and access to data. - Creative Sharepoint
· SharePoint is an enterprise information portal, from Microsoft, that can be configured to run Intranet, Extranet and Internet sites. - SharePoint HQ
· {..} SharePoint is a sort of sharing/blogging/wiki-style server that mainly provides a back end to Microsoft Office - Jack Schofield, Technical Writer Guardian newspaper, UK.
Windows SharePoint Services function the basic functionality that Gartner calls Basic Content Services. It offers the user access to Versioning and Check-in/Checkout functionality. WSS can then be extended through the use of the applets to add additional collaborative functions like email alerts, shared calendars, etc.
Microsoft Office SharePoint Server (MOSS) sits on top of WSS and adds additional features, both to the underlying WSS layer as well as additional ways for the end-user to interact with the repository. The data resides in a SQL Database. Using Webparts it can then present this information to the user using a wide range of different modules and for interaction in different business scenarios. These include such diverse applications as Collaboration, Document management, Records Management (including DOD 5015.2 certified components), Workflow, Personalization, more complex metadata models as well as Blogs and Wikis from the Web2.0 side.
Finally there is the Microsoft Search Server, an Enterprise Search engine that provides advanced indexing and searching capabilities that can be integrated into a MOSS Web-based interface.
About WSS vs MOSS:
· WSS in not a portal, it's only a collaborative plateform (there are no publishing features in WSS)
· MOSS allows you to use user profils, not WSS
· Search functionalities are cheap in WSS compare to MOSS (but you can extend them using Search Server Express)
· Many others: Infopath, BDC, Additional WebParts, Additional site and list templates
About Search Server and BDC: They do not compete.
Search Server is the MOSS search engine striped out. So you have only search functionalities (you can index SharePoint, WebSite, FileSystem).
The BDC (Business Data Catalog) allows you to view an external business data source, such as a SQL database (not necessarily SQL Server, it can be Oracle, MySQL....) or webservices. You'll be able to view data in your portal, and integrate this data to any of your list. The BDC also allows you to index this content source if you have SharePoint Enterprise Edition.
To get started launch Central Administration from Start->All Program->Microsoft Office Server->Sharepoint 3.0 Central Administration.
http://www.jasonslater.co.uk/wp-content/uploads/2008/08/moss-ca.pnghttp://www.jasonslater.co.uk/wp-content/uploads/2008/08/moss-ca.png
The first two questions you may be faced with are:
· What are Shared Services Providers (SSP)?
· Why do I have a Shared Services Administration section in Central Administration with a SharedServices1 entry?
What are Shared Services Providers (SSP)?
MOSS can be used to create and host a number of web applications, for example an Intranet, Extranet, Team Site, etc. These applications may typically require similar information such as user profile information from say Active Directory or LDAP but there are two caveats that lead to the need for SSP:
You may not want some information to cross between web applications (for example you may not want member of an Extranet to be able to access information from the Intranet).
Your MOSS may be public Internet facing (or close to it) and you don’t want to expose any sensitive back-end functionality.
Shared Services Providers act as more than an intermediary between web applications and sensitive services such as Active Directory and LDAP. By creating a Shared Services Provider (SSP) you can create an interface, or a mediator, that retrieves the information you need from the sensitive service and places it in a database for query by the appropriately authorised web applications.
The immediate question might be why can’t these applications talk to Active Directory – they could but you may be duplicating effort, taking a performance hit on the back-end and require over complicated security mechanisms to ensure minimal exposure to sensitive services.
Clicking on Shared Services Administration will bring you up with a Manage this Shared Services section where you can do several things. http://www.jasonslater.co.uk/wp-content/uploads/2008/08/moss-admin.png
You could create a new SSP, change the default if you have several (for example you may decide you have more Extranet users than internal users so make that the default). You can also restore a previously saved SSP from a backup. Additionally, you can Change the Association between Applications and SSP. For example you may have a number of SharePoint applications each serving different purposes – use this option to tell each application which SSP to use.
This area of administration simply allows you to create the framework for the SSP, you will manage it separately (such as where to get the information from) from its own administrative interface.
Why does an SSP exist already?
Once an SSP is configured you need to manage it from its own administration centre by clicking on its name in the sidebar. This URL will also be shown in the Edit Properties section of the SSP.
http://www.jasonslater.co.uk/wp-content/uploads/2008/08/moss-interface.pnghttp://www.jasonslater.co.uk/wp-content/uploads/2008/08/moss-interface.png
Typically you will have just one entry listed under Shared Services Administration unless your want to maintain clear boundaries, for example an Extranet or if you operate separate companies on the same server.
Typically you will have just one entry listed under Shared Services Administration unless your want to maintain clear boundaries, for example an Extranet or if you operate separate companies on the same server.
It is from this section that you can specify where to populate the SSP database, when, how often, and set the default policies of how this information is treated.
What is a Shared Service Provider?
For those of you who don't know what I am talking about a bit of overview. In MOSS 2007 there is this new concept of Shared Services Providers(SSP). The idea being that there are certain services that really make sense to centrally manage and share. A good example being profiles. With a SSP we can import all of the profile information from AD once and then our various web applications can consume the data. So maybe we have http://marketing and http://accounting it doesn't make sense for each one to maintain identical profile information, they should share.
The major services that are handled by the SSP are:
· Profiles and Audiences
· My Sites
· Search
· All of Excel Services
· All of the BDC (Business Data Catalog)
Below is an example screen shot from MOSS 2007 Enterprise:
Sometimes the easiest way to think of Shared Services is the Parent vs. Child relationship. The Parent (your SSP) goes out and does all of the work (pulling BDC data, indexing content, hosting My Sites) and the child (your web applications) come to the parents to ask for $5 (request data from the BDC, or view a calculated Excel sheet). Does that help?
Multiple SSPs
One of the most overwhelming things about SSPs for some people planning is how many should I have? It is easy to see from the interface that you are given the opportunity to create more than one. When should you do this?
As a general rule of thumb most companies will use one SSP. This is my default answer. So why do they give you the ability to run multiple SSPs? There are cases where you want separate search or profiles. The most common? Extranet/internet scenarios. Maybe your SharePoint farm hosts two primary web applications. http://portal for your intranet and http://ourcustomers for your extranet. In this scenario you probably want separate search and profiles. And now you have found the reason to have multiple SSPs. You don't want to share information you want unique information for both.
Another advantage of SSPs
Separation of roles. In some medium and large environments it is not uncommon to have one group administering the physical server farm while another group needs to just maintain search. Well the SSP concept makes this very easy. Since the SSP is its own SharePoint site collection you can define a users access so they can NOT access central administration but they CAN access the SSP. And once they get into the SSP you can even limit them. Once inside the SSP you can determine if they can:
· Manage user profiles
· Manage audiences
· Manage permissions
· Manage usage analytics
Best I can tell if you give them access to the SSP all of the other SSP functions they will have rights to. Guess it needs more testing.
Still this separation of services from the actual administration of the server can be quite useful. Epically in companies where the less access I give a user the better.
Moral of the story
SSPs are very helpful and important to understand. They should be part of your initial planning. They can be secured at a very granular level or they can be give broad access. Just mark this topic down as something else you need to full think through before you start rolling out SharePoint. And when all else fails just have one SSP.
SharePoint 2007 Tutorial for beginners
1. Microsoft Windows SharePoint Services 3.0 - an extension build on Windows Server 2003, which Provides the infrastructure for collaboration and a foundation for building Web-based applications with this versatile technology. In short, it provides the base for SharePoint Server 2007.
2. SharePoint and .Net - SharePoint development stack is build upon .Net Framework 2.0 so, it pretty much uses all the .Net Framework 2.0 classes as its base classes. IT however, has its own SharePoint API model, which is commonly used for development.
3. SharePoint and SQL - SharePoint definitely uses SQL server to store the data which is uploaded into it. So be ready with a big SQl space to accommodate SharePoint data.
Now let’s start with the basic definition of SharePoint Server 2007 - its Collaboration software or a Content management Portal which effectively manage and repurpose the content to gain increased business value. In simple words, SharePoint's main purpose is to allow various departments\teams in the company to upload manage and share documents using SharePoint sites. In addition to sharing documents, it also allows you to create and manage web sites, use workflows and various other options to implement the business process. For more info see What is SharePoint Used For
SharePoint as we know is a Content Management System developed by Microsoft that allows users to share the data (like word documents and stuff) in a web-based collaborative environment.
SharePoint is mostly used to create Companies Intranet Portal, where people can upload and Share documents they work on.
In brief, SharePoint is used to perform following functions in a company (Common Ones...)
1. Share Documents (like Word docs, excel sheets or simply some data values).
2. Start a Workflow on Document\Data.
3. Display Companies Announcements (You are given a template to write and publish announcements on an aspx Page)
4. Display RSS feeds from various sources including SharePoint lists.
5. Display Data from other sources like SQL server, Access and other on companies Intranet Page.
6. Send E-mails (Automatic Alerts) for anything or everything happening in the company’s portal.
7. Create aspx Pages and add data to them without writing code.
8. Make the intranet Portal Site Public ( It will behave like any other site on the web.)
SharePoint is mostly used to create Companies Intranet Portal, where people can upload and Share documents they work on.
In brief, SharePoint is used to perform following functions in a company (Common Ones...)
1. Share Documents (like Word docs, excel sheets or simply some data values).
2. Start a Workflow on Document\Data.
3. Display Companies Announcements (You are given a template to write and publish announcements on an aspx Page)
4. Display RSS feeds from various sources including SharePoint lists.
5. Display Data from other sources like SQL server, Access and other on companies Intranet Page.
6. Send E-mails (Automatic Alerts) for anything or everything happening in the company’s portal.
7. Create aspx Pages and add data to them without writing code.
8. Make the intranet Portal Site Public ( It will behave like any other site on the web.)
SharePoint Administration - As it a server, you would definitely need to learn its administration. SharePoint has two options available for administration.
1. Central admin - A website available to you immediately after you install SharePoint (and after you ran its Config wizard). This website pretty much allows you to perform and function in SharePoint like Creating\Deleting Websites, Backup\Restore Sites, Set up Users\accounts, Install Custom components and a lot more.
2. Stsadm Tool - This is a command line tool available in SharePoint, which allows you to perform all the administrative tasks that you can do with Central admin site.
12 Hive - SharePoint stores a lot it’s Pages and resources on the file system itself for fast retrieval. These Pages or Files which make SharePoint Interface are arranged in a Folder structure which we call as 12 Hive. The 12 hive gets created at location "C:\ProgramFiles\CommonFiles\Web Server Extentions\12" when you install the SharePoint sever initially. To Know more about 12 hive and SharePoint solution structure see 12 hive Folder Structure
1. Central admin - A website available to you immediately after you install SharePoint (and after you ran its Config wizard). This website pretty much allows you to perform and function in SharePoint like Creating\Deleting Websites, Backup\Restore Sites, Set up Users\accounts, Install Custom components and a lot more.
2. Stsadm Tool - This is a command line tool available in SharePoint, which allows you to perform all the administrative tasks that you can do with Central admin site.
12 Hive - SharePoint stores a lot it’s Pages and resources on the file system itself for fast retrieval. These Pages or Files which make SharePoint Interface are arranged in a Folder structure which we call as 12 Hive. The 12 hive gets created at location "C:\ProgramFiles\CommonFiles\Web Server Extentions\12" when you install the SharePoint sever initially. To Know more about 12 hive and SharePoint solution structure see 12 hive Folder Structure
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 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 Development - SharePoint is also looked upon as a development platform, since all the components in SharePoint, right from a small hyperlink to a fancy button is customizable. You can add your links, buttons , pages and even whole asp.net application SharePoint using its deployment architecture.For more details see :Sharepoint 2007 development Tutorial
Lets Start with what do you need for your development machine
1. First and foremost, you need Windows Server 2003 R2 with Windows SharePoint Services 3.0 Installed. Then you need to verify that you have Microsoft SQL Server 2005\2008 Developer Edition installed, before you began installing Microsoft Office SharePoint Server 2007 also Known as "MOSS".
Other quick way to start with development is to download SharePoint 2007 VHD from Here and run it with a software called Microsoft Virtual PC. This VHD Contains Microsoft Office SharePoint Server 2007 and Microsoft Office SharePoint Server 2007, you will however need to install VS 2005\2008 to get started.
Once you are all set with the machine you should consider installing Visual Studio Extensions for Windows SharePoint Services 3.0 from Here. This will provide you with various SharePoint Templates to get started.
Let's discuss the knowledge Part - First you need to be familiar with 12 Hive and the Solution structure of SharePoint.
12 hive - SharePoint 2007 have a 12 hive structure which basically contains various files and folders that make SharePoint Interface. The files\components that you will develop will also be deployed under this folder structure.
Solution Package and Feature - Every component that you will develop for SharePoint should be in the form of a Solution Package. These packages are nothing but a .cab files which contain other files that needed to be deployed on the SharePoint server. These Solutions packages represented in SharePoint as .wsp files, also allows you to package Features and defines important metadata about those Features. Besides, Solution Package "Features" is also an important concept in SharePoint development.
Feature is a functional component that can be activated and deactivated at various scopes throughout a SharePoint instances. Almost, every link, button or functional components in SharePoint is a Feature. Take it as a component that can be turned on\off when required. To understand the relation between 12 hive and the .wsp see
12 Hive Folder Structure
Now, lets discuss about SharePoint 2007 Object Model - In SharePoint 2007 Object Model there are two important namespaces .
1. Microsoft.SharePoint namespace - This is the root namespace for all WSS objects. A developer would always use Micorsoft.SharePoint.dll namespace for creating WSS compatible components like webparts,features and solution packages.
2. Microsoft.Office.Server namespace - This is the root namespace of all Office Server 2007 (i.e. MOSS) objects. A developer will use the Microsoft.Office.Server namespace while accessing SharePoint 2007 server (or MOSS) specific components like BDC,Enterprise search etc.
Creating WebParts - Lets Start with creating a very basic webpart using VseWss. This webpart will display some data from a SharePoint list using GridView control on a SharePoint Site Page. The webpart is created as a feature, that means you can activate\deactivate this webpart in your SharePoint site and is deployed in the SharePoint environment as a solution package.
See detail Step-by-Step example Create and Deploy Webpart as Solution Package
SharePoint Object Model -
In Sharepoint Object model there are two Important namespaces.
Microsoft.Office.Server - This is a root namespace of all Office Server objects. This means all the components or services available in Offiice SharePoint Server like BDC, enterprise search etc can be accesed programmatically using this namespace.
1. First and foremost, you need Windows Server 2003 R2 with Windows SharePoint Services 3.0 Installed. Then you need to verify that you have Microsoft SQL Server 2005\2008 Developer Edition installed, before you began installing Microsoft Office SharePoint Server 2007 also Known as "MOSS".
Other quick way to start with development is to download SharePoint 2007 VHD from Here and run it with a software called Microsoft Virtual PC. This VHD Contains Microsoft Office SharePoint Server 2007 and Microsoft Office SharePoint Server 2007, you will however need to install VS 2005\2008 to get started.
Once you are all set with the machine you should consider installing Visual Studio Extensions for Windows SharePoint Services 3.0 from Here. This will provide you with various SharePoint Templates to get started.
Let's discuss the knowledge Part - First you need to be familiar with 12 Hive and the Solution structure of SharePoint.
12 hive - SharePoint 2007 have a 12 hive structure which basically contains various files and folders that make SharePoint Interface. The files\components that you will develop will also be deployed under this folder structure.
Solution Package and Feature - Every component that you will develop for SharePoint should be in the form of a Solution Package. These packages are nothing but a .cab files which contain other files that needed to be deployed on the SharePoint server. These Solutions packages represented in SharePoint as .wsp files, also allows you to package Features and defines important metadata about those Features. Besides, Solution Package "Features" is also an important concept in SharePoint development.
Feature is a functional component that can be activated and deactivated at various scopes throughout a SharePoint instances. Almost, every link, button or functional components in SharePoint is a Feature. Take it as a component that can be turned on\off when required. To understand the relation between 12 hive and the .wsp see
12 Hive Folder Structure
Now, lets discuss about SharePoint 2007 Object Model - In SharePoint 2007 Object Model there are two important namespaces .
1. Microsoft.SharePoint namespace - This is the root namespace for all WSS objects. A developer would always use Micorsoft.SharePoint.dll namespace for creating WSS compatible components like webparts,features and solution packages.
2. Microsoft.Office.Server namespace - This is the root namespace of all Office Server 2007 (i.e. MOSS) objects. A developer will use the Microsoft.Office.Server namespace while accessing SharePoint 2007 server (or MOSS) specific components like BDC,Enterprise search etc.
Creating WebParts - Lets Start with creating a very basic webpart using VseWss. This webpart will display some data from a SharePoint list using GridView control on a SharePoint Site Page. The webpart is created as a feature, that means you can activate\deactivate this webpart in your SharePoint site and is deployed in the SharePoint environment as a solution package.
See detail Step-by-Step example Create and Deploy Webpart as Solution Package
SharePoint Object Model -
In Sharepoint Object model there are two Important namespaces.
Microsoft.Office.Server - This is a root namespace of all Office Server objects. This means all the components or services available in Offiice SharePoint Server like BDC, enterprise search etc can be accesed programmatically using this namespace.
Microsoft.SharePoint - This is the root namespace for all WSS 3.0 objects. Remember, Wss 3.0 is the base platform used by Office SharePoint server. For all namespaces see 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
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
What is SharePoint made of? - SharePoint Portal is a made of Web applications (WebSites in .Net), Site Collections (a top level Site of the Web application) Web Site Pages,Subsites(or child sites of Site collectons),Webparts,features and more ... See the basic defination for all SharePoint Components that you will use during development Important Definations.
Web Parts are componentized, self-contained packages of user interface that can be dropped into place on SharePoint Web Part pages to provide discrete sets of functionality to users.
It can be incredibly easy to get confused between sites, webs, web applications, and site collections. The farm is the topmost level in the hierarchy. Below the farm, you have web applications represented by the SPWebApplication class, which typically correspond to an IIS application pool. Below that, you have a collection of site collections contained in the SPSiteCollection class. Finally, you have site collections represented by the SPSite class and individual websites represented by the SPWeb class.
Features allow reusable pieces of functionality to be created and deployed to other sites,without modifying site templates.It is always better to deploy a feature in new site instead ofdirectly embedding mountains of complex XML.Using Features, you can do everything from adding a link to the Site Settings page to creating a complete, fully functioning Project Management suite that can be added to any SharePoint site.Features are organized in folders under the Features directory located under 12 hives; Where SharePoint Server 2007 puts all of its system files, at the following path: %SystemDrive%\Program Files\Common Files\Microsoft Shared\web server extensions\12. The two files that are used to define a feature are the feature.xml and Elements.xml .The feature XML file defines the actual feature and will make SharePoint aware of the installed feature. It usually identifies the Feature itself and its element manifest file and sets the Feature scope to Web site.
Elements.xml file identifies the assembly, class, and method to implement in feature.
You can directly deploy a feature in sharepoint site with
stsadm -o installfeature -filename XYZEventHandler\Feature.xml
stsadm -o activatefeature -filename DeletingEventHandler\Feature.xml -url href="http://server/Site/Subsite">http://Server/Site/Subsite
iisreset
OR To Deploy it as solution package you need a solution manifest (manifest.xml).
Solutions allow you to package Features in a cabinet (.cab) file and define important metadata about those Features. After a Solution is installed on a server in the farm, you can then use SharePoint’s Solution management features to automate the deployment of that Solution to other sites within the farm.
The solution manifest (always called manifest.xml) is stored at the root of a solution file. This file defines the list of features, site definitions, resource files, Web Part files, and assemblies to process. It does not define the file structure—if files are included in a solution but not listed in the manifest XML file, they are not processed in any way.
Because the solution file is essentially a .cab file, use the makecab.exe tool to create the solution package. The makecab.exe tool takes a pointer to a .ddf file, which describes the structure of the .cab file. The format of a .ddf file is, declare a standard header and then enumerate, one file per line, the set of files by where they live on disk, separated by where they should live in the .cab file.
Features & Solutions:
The Feature Framework has been extended to allow developers to create custom Features. Features can be deployed by using SharePoint Portal Server 2007 new form of deployment, namely Solution Deployment. Solutions as you know, are custom packages (e.g. WSP file) or redistributable CAB files, created by developers and deployed by SharePoint Administrators. Administrator can deploy Features to the individual site or to all Web front End Servers.
Features are a method for developers to package customisations and deploy them to the SharePoint portal. They can then be activated and deactivated at the Site Collection level. Solutions are a way to bundle features together for deployment.
Custom action : Represents a link, toolbar button, menu item, or any control that can be added to a toolbar or menu that appears in the UI. You define custom actions by using a custom action element within a feature definition file. You can bind custom actions to a list type, content type, file type, or programmatic identifier (ProgID). For more information, see Custom Action Definitions.
Event receiver: Evaluator of an event and definer of the behavior of an application. Windows SharePoint Services 3.0 allows you to define event handlers within libraries, lists, and sites. Event receivers can be defined by using a receiver element within a feature definition file. For more information, see Event Registrations.
Master page: Pages that provide a consistent layout and appearance (look and feel) for SharePoint sites. They allow you to factor out layout, structure, and interface elements such as headers, footers, navigation bars, and content placeholders. Master pages in ASP.NET 2.0 and master pages in Windows SharePoint Services work in the same way. For more information, see Building Simple Master Pages for Windows SharePoint Services 3.0.
Module : A file or collection of file instances that define the location where the files are installed during site creation. Modules are frequently used to implement a Web Part Page in the site. You can define modules by using a module element within a feature definition file. For more information, see Modules.
SharePoint site: A Web site hosted in a virtual URL. A SharePoint site is a place for collaboration, communication, or content storage. Depending on your business needs, you can create sites such as team sites, blog sites, wiki sites, and others. You can customize a site's appearance, users, user permissions, galleries, and site administration by using the Site Settings administration pages.
SharePoint site collection: A collection of SharePoint sites that share common administration pages and site settings. Site collections allow you to share content types, site columns, templates, and Web Parts within a group of SharePoint sites.
SharePoint Web farm: A group of Office SharePoint 2007 servers that share the same configuration database. All site content and all configuration data is shared for all front-end Web servers in a server farm.
Site definition.: A set of files that includes a master XML configuration file that is stored on all front-end Web servers. A site definition provides the basic blueprint for how sites look, what lists they include, their default navigational structures, and so on. For more information, see Working with Site Templates and Definitions.
Theme: A group of files (CSS, images) that allow you to define the appearance (look and feel) of Web pages. Themes in ASP.NET 2.0 and themes in SharePoint Products and Technologies work in the same way. Themes are used to help organizations to brand their portals and team sites. Office SharePoint Server 2007 includes a set of predefined themes. However, as a developer, you can create custom themes for your company. For more information, see How to: Customize
It can be incredibly easy to get confused between sites, webs, web applications, and site collections. The farm is the topmost level in the hierarchy. Below the farm, you have web applications represented by the SPWebApplication class, which typically correspond to an IIS application pool. Below that, you have a collection of site collections contained in the SPSiteCollection class. Finally, you have site collections represented by the SPSite class and individual websites represented by the SPWeb class.
Features allow reusable pieces of functionality to be created and deployed to other sites,without modifying site templates.It is always better to deploy a feature in new site instead ofdirectly embedding mountains of complex XML.Using Features, you can do everything from adding a link to the Site Settings page to creating a complete, fully functioning Project Management suite that can be added to any SharePoint site.Features are organized in folders under the Features directory located under 12 hives; Where SharePoint Server 2007 puts all of its system files, at the following path: %SystemDrive%\Program Files\Common Files\Microsoft Shared\web server extensions\12. The two files that are used to define a feature are the feature.xml and Elements.xml .The feature XML file defines the actual feature and will make SharePoint aware of the installed feature. It usually identifies the Feature itself and its element manifest file and sets the Feature scope to Web site.
Elements.xml file identifies the assembly, class, and method to implement in feature.
You can directly deploy a feature in sharepoint site with
stsadm -o installfeature -filename XYZEventHandler\Feature.xml
stsadm -o activatefeature -filename DeletingEventHandler\Feature.xml -url href="http://server/Site/Subsite">http://Server/Site/Subsite
iisreset
OR To Deploy it as solution package you need a solution manifest (manifest.xml).
Solutions allow you to package Features in a cabinet (.cab) file and define important metadata about those Features. After a Solution is installed on a server in the farm, you can then use SharePoint’s Solution management features to automate the deployment of that Solution to other sites within the farm.
The solution manifest (always called manifest.xml) is stored at the root of a solution file. This file defines the list of features, site definitions, resource files, Web Part files, and assemblies to process. It does not define the file structure—if files are included in a solution but not listed in the manifest XML file, they are not processed in any way.
Because the solution file is essentially a .cab file, use the makecab.exe tool to create the solution package. The makecab.exe tool takes a pointer to a .ddf file, which describes the structure of the .cab file. The format of a .ddf file is, declare a standard header and then enumerate, one file per line, the set of files by where they live on disk, separated by where they should live in the .cab file.
Features & Solutions:
The Feature Framework has been extended to allow developers to create custom Features. Features can be deployed by using SharePoint Portal Server 2007 new form of deployment, namely Solution Deployment. Solutions as you know, are custom packages (e.g. WSP file) or redistributable CAB files, created by developers and deployed by SharePoint Administrators. Administrator can deploy Features to the individual site or to all Web front End Servers.
Features are a method for developers to package customisations and deploy them to the SharePoint portal. They can then be activated and deactivated at the Site Collection level. Solutions are a way to bundle features together for deployment.
Custom action : Represents a link, toolbar button, menu item, or any control that can be added to a toolbar or menu that appears in the UI. You define custom actions by using a custom action element within a feature definition file. You can bind custom actions to a list type, content type, file type, or programmatic identifier (ProgID). For more information, see Custom Action Definitions.
Event receiver: Evaluator of an event and definer of the behavior of an application. Windows SharePoint Services 3.0 allows you to define event handlers within libraries, lists, and sites. Event receivers can be defined by using a receiver element within a feature definition file. For more information, see Event Registrations.
Master page: Pages that provide a consistent layout and appearance (look and feel) for SharePoint sites. They allow you to factor out layout, structure, and interface elements such as headers, footers, navigation bars, and content placeholders. Master pages in ASP.NET 2.0 and master pages in Windows SharePoint Services work in the same way. For more information, see Building Simple Master Pages for Windows SharePoint Services 3.0.
Module : A file or collection of file instances that define the location where the files are installed during site creation. Modules are frequently used to implement a Web Part Page in the site. You can define modules by using a module element within a feature definition file. For more information, see Modules.
SharePoint site: A Web site hosted in a virtual URL. A SharePoint site is a place for collaboration, communication, or content storage. Depending on your business needs, you can create sites such as team sites, blog sites, wiki sites, and others. You can customize a site's appearance, users, user permissions, galleries, and site administration by using the Site Settings administration pages.
SharePoint site collection: A collection of SharePoint sites that share common administration pages and site settings. Site collections allow you to share content types, site columns, templates, and Web Parts within a group of SharePoint sites.
SharePoint Web farm: A group of Office SharePoint 2007 servers that share the same configuration database. All site content and all configuration data is shared for all front-end Web servers in a server farm.
Site definition.: A set of files that includes a master XML configuration file that is stored on all front-end Web servers. A site definition provides the basic blueprint for how sites look, what lists they include, their default navigational structures, and so on. For more information, see Working with Site Templates and Definitions.
Theme: A group of files (CSS, images) that allow you to define the appearance (look and feel) of Web pages. Themes in ASP.NET 2.0 and themes in SharePoint Products and Technologies work in the same way. Themes are used to help organizations to brand their portals and team sites. Office SharePoint Server 2007 includes a set of predefined themes. However, as a developer, you can create custom themes for your company. For more information, see How to: Customize
