Inside Sharepoint 2010

 

User Control Life cycle

Event Phase	Description	Method or event to override
Initialize	Initialize settings needed during the lifetime of the incoming Web request.	Init event (OnInit method)
Load view state	At the end of this phase, the ViewState property of a control is automatically populated. A control can override the default implementation of the LoadViewState method to customize state restoration.	LoadViewState method
Load	Perform actions common to all requests, such as setting up a database query. At this point, server controls in the tree are created and initialized, the state is restored, and form controls reflect client-side data.	Load event (OnLoad method)
Handle postback events	Handle the client-side event that caused the postback and raise appropriate events on the server. Note Only controls that process postback events participate in this phase.	RaisePostBackEvent method
Prerender	Perform any updates before the output is rendered. Any changes made to the state of the control in the prerender phase can be saved, while changes made in the rendering phase are lost.	PreRender event (OnPreRender method)
SaveViewState	The ViewState property of a control is automatically persisted to a string object after this stage. This string object is sent to the client and back as a hidden variable. For improving efficiency, a control can override the SaveViewState method to modify the ViewState property.	SaveViewState method
Render	Generate output to be rendered to the client.	Render method
Dispose	Perform any final cleanup before the control is torn down. References to expensive resources such as database connections must be released in this phase.	Dispose method
Unload	Perform any final cleanup before the control is torn down. Control authors generally perform cleanup in Dispose and do not handle this event.	UnLoad event (On UnLoad

Web Part life cycle in SharePoint 2010

OnInit: This method handles initialization of the control.

OnLoad: This event handles the Load event. This is also used for initialize the control but is not intended for loading data or other processing functionality.

CreateChildControls: This is the most popular event in web part life cycle. This creates any child controls. So if you are adding any control to display then you have to write in this method.

EnsureChildControls: This method ensures that CreateChildControls has executed.

EnsureChildControls method must be called to prevent null reference exceptions.

SaveViewState: View state of the web part saved.

OnPreRender: This method handles or initiates tasks such as data loading that must complete before the control can render.

Page.PreRenderComplete: The page fires the PreRenderComplete event after all controls have completed their OnPreRender methods.

Render: This method is used to render everything.

RenderContents: Renders the contents of the control only, inside of the outer tags and style properties.

OnUnload: Performs the final cleanup.

ASP.NET Web Part Vs SharePoint Web Part

ASP.NET 2.0 Web Part	SharePoint-based Web Part
For most business needs. To distribute your Web Part to sites that run ASP.NET 2.0 or SharePoint sites. When you want to reuse one or more Web Parts created for ASP.NET 2.0 sites on SharePoint sites. To use data or functionality provided by Windows SharePoint Services 3.0. For example, you are creating a a Web Part that works with site or list data.	When you want to migrate a set of Web Parts using the SharePoint-based Web Part infrastructure to Windows SharePoint Services 3.0. To create cross page connections. To create connections between Web Parts that are outside of a Web Part zone. To work with client-side connections (Web Part Page Services Component). To use a data-caching infrastructure that allows caching to the content database.

Difference between Client Object Model and Server Object Model in SharePoint 2010

Server Object Model:

1-SharePoint itself uses the server object model.You can also use this model on a sharepoint server bcz it has some dependencies satisfied by the sharepoint server.

2-Here you can use LINQ programming like LINQ to SharePoint.

3-different classes are there like SPFarm, SPServer, SPService, and SPWebApplication etc.

Client Object Model:

1-Client Side APIs refer to the Client Object Models that were introduced in SharePoint 2010.

2-It is available in three different flavors like: .NET managed,Silverlight and ECMAScript.

3-The Main advantage of the CSOMs is that you do not need to be on the Server to use them in your program. The .NET client object can be used in any Desktop or Web Client. The Silverlight CSOM can be used in silverlight applications and you can call the JS Client Object Model directly from your web pages.

Managed Object Model	Microsoft.SharePoint.Client.dll Microsoft.SharePoint.ClientRuntime.dll	ISAPI folder
Silverlight client object model	Microsoft.SharePoint.Client.Silverlight.dll Microsoft.SharePoint.Client.Silverlight.Runtime.dll	LAYOUTS\ClientBin folder
JavaScript client object model	SP.js	LAYOUTS folder

Different types of Objects:

Server object model	Managed Model	Silverlight Model	Javascript Model
SPContext	ClientContext	ClientContext	ClientContext
SPSite	Site	Site	Site
SPWeb	Web	Web	Web
SPList	List	List	List
SPListItem	ListItem	ListItem	ListItem
SPField	Field	Field	Field

Difference between SharePoint 2010 and MOSS 2007

SharePoint 2010	MOSS 2007
Look and feel
In SP 2010 look and feel perspective there will be a ribbon where we can have a look and feel like Office 2010	In MOSS 2007 there is no ribbon
Deployment of Web parts
In SharePoint 2010 deploying custom web part is pretty simple i.e. just right click on the solution and click Deploy	In MOSS 2007 you need to drag the dll either to bin or GAC
Silverlight Application
In SP 2010 we can create a Silverlight application directly from Visual Studio 2010	In MOSS 2007 we have to create a web part to host Silverlight application
Shared Database & Service Application
In SP 2010 there is no SSP but there is a concept of Service Application like BCS as one service application, Excel Services as another service application, User Profile as separate service application General idea is that you have an application for each service, rather than one application with lots of service crammed into it Own database rather than shared database in SP 2010	In MOSS 2007 we have SSP where we can work around with BI,Search Settings, User Profile Import, Excel Services, Info path In Database also we use to have separate area for SSP stuff
Easy exports/imports between the forms
In SP 2010 we can update existing information	In MOSS 2007 through we can just read the information and we can't update the existing services
Improvement in Deployment
In SP 2010 we can Deploy through Farm based and solution based solution in SP 2010	In MOSS 2007 there is no such option
Alerts
In SP 2010 alerts were sent only through emails and send alerts to mobile device as SMS message. A New property delivery channel is introduced to indicate, whether the alerts is delivered as Email or an SMS message.	In MOSS 2007 alerts were sent only through emails.
Improvements of events
New events for list creation and web creation	No List and web events in MOSS 207
Getting Items from the list
In SP 2010 through object model we can fetch multiple list data by LINQ query and object model	In MOSS 2007 we can fetch only through object model
Rating
In SP 2010 we can have rating column by default	In MOSS 2007 we should install the feature that is available in codeplex to have rating
Key Word Suggestions
In SP 2010 we can have keyword suggestions	In MOSS 2007 we don’t have any keyword suggestions
Taxonomy
In SP 2010 we can create Taxonomy by using Managed Metadata service	In MOSS 2007 we don’t have taxonomy
Other Features
In SP 2010 we have Power Shell Scripting, JavaScript object model, Chart Web Parts	In MOSS 2007 we don’t have Power Shell Scripting, JavaScript object model, Chart Web Parts
Running stsadm command
In SP 2010 we have to go 14 hive path to run stsadm command	In MOSS 2007 we have to go 12 hive path to run stsadm command

View Site Groups In SharePoint 2010

using (SPSite siteCollection = new SPSite("http://hrweb"))
 {
   using (SPWeb site = siteCollection.OpenWeb())
     {
       // Print all groups name of site
       foreach (SPGroup group in site.Groups)
       {
          Console.WriteLine(group.Name);
        }
      Console.WriteLine("View All Site Groups");
 }
}

DataView WebPart In SharePoint 2010

A Data View Web part is a great way to display data with filtering, grouping, and user desired formatting.  It was the most useful webpart in SharePoint 2007 and now has been improved to a great extend in SharePoint 2010.  In SharePoint 2010 you now have a  XSLT Listview webpart and a Dataview webpart (Old one).

XSLT Listview webpart  – XSLT Listview webpart is a ListView whose XSLT can be modified in SharePoint designer.  With this you now have some advanced formatting options and can also use all the filters,sorting grouping etc features that a Dataview wbepart had in SharePoint 2007.

DataView Webpart – Even after all the great features that XSLT Listview webpart has offered, i would still prefer to work with the old Dataview webpart’s XSLT if i have to. The OLD dataview webpart is still available and can be used in the same manner as we used in SharePoint 2007. To add a Dataview webpart onto a page follow the steps below.

1. Open your SharePoint Page and in Site Actions select ->Edit in SharePoint Designer.

2. Now select a zone on teh Page where you want to add your Dataview weboart.

3. Next, click on Insert tab -> click on Data View.

4.  In the drop-down of Data view menu click on “Empty Data view” . This will now insert an Empty Data view in your selected zone.

5. Next click on “click here to select datasource” to select the datasource or list.

6. Select the list\library you want to display the data from.

7. Next drag and drop the columns in the dataview webpart from the right hand column list (for the list\library you selected).

You now have the Dataview webpart on your page. You can now use the formatting options available on your ribbon or can modify the XSLT either in Designer or on the page itself by editing the webpart properties in the Browser.

Different Types of WCF Hosting Environments

Self-Hosted:
By implementing your own self-hosted service application, you can:

• Add code to start and stop your WCF service when required.
• Expose your WCF service over protocols other than Hypertext Transfer Protocol (HTTP).
• Add additional code to get state information about the service host.

Windows Services:
This hosting option works by registering the application as a managed Windows service. Because the operating system controls the lifetime of the service, you can activate and start your WCF service as soon as the system starts. After it has started, the service runs silently in the background. Like the self-hosting option, this type of hosting environment requires that some hosting code is written as part of the application
IIS:
The IIS hosting option enables:

• Message-based activation, which creates a new instance of the service when a message arrives, rather than having a service running constantly.
• Process recycling, which restarts the hosting process to clear the effects of memory leaks.
• Idle shutdown, which stops and serializes the service after a given time to conserve system resources.
• Process health monitoring, which enables you to respond to resource issues in the services.

WAS:
IIS 7.0 includes WAS. Hosting your WCF service in WAS offers all of the benefits of hosting in IIS, including:

• Message-based activation
• Process recycling
• Idle shutdown
• Process health monitoring

Additionally, WAS is a generalization of IIS that is not bound to HTTP.

For more information about the possible hosting options, see Hosting and Consuming WCF Services

Difference Between SharePoint Application Pages Vs Site Pages

Application Pages:

• Application pages are stored in the server’s file system. 
• SharePoint Designer tool cannot be used with application pages. 
• Application pages cannot be used within sandboxed solutions. 
• An Application page cannot be customized and modified by end user, instead a developer is required. 
• These are the normal .aspx pages deployed within SharePoint. Most common of them are the admin pages found in _layouts folder.
• These are deployed either at the farm level or at application level. If they are deployed within _layouts folder or global SharePoint Virtual Directory, then they can be used by any SharePoint application (available at farm level), otherwise they can be deployed at application level only by creating a virtual directory.
• These are typical ASP.Net aspx pages and can utilize all of the functionalities available within ASP.Net including code-behind, code-beside, inline coding etc.
• These are compiled by .Net runtime like normal pages.
• If you deploy your custom ASPX pages within _layouts folder or within SharePoint application using a virtual directory, you will not be able to use SharePoint master pages and have to deploy your master page within the virtual directory or _layouts folder.
• Application Pages cannot use contents as this concept is associated with SharePoint Page Layouts not with ASP.Net.
• Since application pages are compiled once, they are much faster
• Normally application pages are not web part pages, hence can only contain server controls or user controls and cannot be personalized by users.
• Easiest way to deploy your existing ASP.Net web site within SharePoint is to deploy its pages as Application Pages within SharePoint. In this way you can convert any ASP.Net web solution as SharePoint application with minimal efforts.
• SharePoint specific features like Information Management Policies, Workflows, auditing, security roles can only be defined against site pages not against application pages.
• Application pages can be globalized using Resource files only. 

Site Pages:

• Site Pages is a concept where complete or partial page is stored within content database and then actual page is parsed at runtime and delivered to end-users.
• Site pages can be edited by using SharePoint Designer tool.
• Site pages are used within Sandboxed solutions. 
• A site page can be customized and modified by end user. 
• Pages stored in Pages libraries or document libraries or at root level within SharePoint (Wiki pages) are Site Pages
• You must be thinking why we should use such pages? There are many reasons for this. One of the biggest catch of the SharePoint is the page layouts, where you can modify page once for a specific content type and then you can create multiple pages using the same page layout with different contents. In this case, contents are stored within database for better manageability of data with all the advantages of a data driven system like searching, indexing, compression, etc and page layouts are stored on file system and final page is created by merging both of them and then the outcome is pared by SharePoint not compiled.
• Site Pages can contain web parts as well as contents placeholders, and all of them are stored per page-instance level within database and then retrieved at run time, parsed and rendered.
• Another advantage is they are at user-level not at web-application or farm level and can be customized per site level.
• Since their definition is retrieved from database, they can utilize master pages stored within SharePoint masterpages library and merged with them at run time for rendering.
• They are slower as compared to Application pages as they are parsed everytime they are accessed.
• SharePoint specific features like Information Management Policies, Workflows, auditing, security roles can only be defined against site pages not against application pages.
• Since they are rendered not compiled hence it is not easy to add any inline code, code behind or code beside. Best way of adding code to these pages is through web-parts, server controls in master pages, user controls stored in "Control Templates" folder or through smart parts. If you want to add any inline code to master page, first you need to add following configuration within web.config:<PageParserPaths>
          <PageParserPath VirtualPath="/_catalogs/masterpage/*" CompilationMode="Always" AllowServerSideScript="true" IncludeSubFolders="true" />
  </PageParserPaths>
• To add code behind to SharePoint master pages or page layouts.
• Since Site pages are content pages, hence all SharePoint specific features like Information Management Policies, Workflows, auditing, security roles can only be defined against site pages.
• Variations can only be applied against Site pages for creating multilingual sites.
• "SPVirtualPathProvider" is the virtual path provider responsible for handling all site pages requests.

 

Differences between .NET vs. SharePoint?

Feature	.NET	SharePoint
Creation:	Code need to be written even to achieve simple functionality	Lots of pre-defined web parts and elements available no need to write the code.
Time:	Takes time to create the code and test	Very less time required
Skilled Professionals:	Skilled professionals are required to create the functionality	Even novice professionals can do so easily
License Requirement:	Not required at the time of deployment of solution	Free versions available, but in case of extensive requirements License is required

 

How to Upload and Download Document from DocLibrary In SharePoint 2010

Upload Document:
String fileToUpload = @"C:\YourFile.txt";         
String sharePointSite = "http://yoursite.com/sites/Research/";        
String documentLibraryName = "Shared Documents";        
using (SPSite oSite = new SPSite(sharePointSite))        
{            
using (SPWeb oWeb = oSite.OpenWeb())            
{
  if (!System.IO.File.Exists(fileToUpload))                    
throw new FileNotFoundException("File not found.", fileToUpload);                
SPFolder myLibrary = oWeb.Folders[documentLibraryName];                
// Prepare to upload                
Boolean replaceExistingFiles = true;                
String fileName = System.IO.Path.GetFileName(fileToUpload);                
FileStream fileStream = File.OpenRead(fileToUpload);                
// Upload document                
SPFile spfile = myLibrary.Files.Add(fileName, fileStream, replaceExistingFiles);                
// Commit                
myLibrary.Update();            
}        
}
Download Document:
SPList currentLib = web.Lists["LibraryName"];

Get all items from the document library
foreach (SPListItem item in items)
{

byte[] binfile = item.File.OpenBinary();
FileStream fstream = new FileStream("C:\\" + item.File.Name,
FileMode.Create, FileAccess.ReadWrite);
fstream.Write(binfile, 0, binfile.Length);
fstream.Close();
}