Render methods in web parts in SharePoint

Today's blog post cover methods of rendering web parts. There are some methods which you can use to render content of a web part. The first method - override RenderContens  method. This method take HtmlTextWriter as argument. So, you can use it to write to the output any information. This code block illustrate how to do it:

protected override void RenderContents(HtmlTextWriter writer) {       writer.Write("Hello world"); }

This method simply put text "Hello world" to the output stream of the web part.
Another way to render web part content - override CreateChildControls:

protected override void CreateChildControls() {       var lblHello = new Label {Text = "Hello world"};       Controls.Add(lblHello); }

We'll get the same result as a previous one, but using CreateChildControls method. You can use the first method in a very simple scenarios, when there is no need to render complex layout with many controls. The second method fit situation when you must have several controls, but with rather simple logic.
But what if we have several controls, but we want insert this controls in a table or a div html tag? The third method help us - we can use both of RenderContents and CreateChildControls overloads. Standard implementation of RenderContents looks like this:

protected override void RenderContents(HtmlTextWriter writer) {     foreach(Control control in Controls)     {         control.RenderControl(writer);     } }

We can call control.RenderControl method in the required sequence and enclosed controls with addition html tags if required. Here is an example:

[ToolboxItemAttribute(false)]

public class HelloWorldWebPart3 : WebPart

{

    protected TextBox _txtName

    protected Button _btnSave;

 

    protected override void CreateChildControls()

    {

        _txtName = new TextBox();

        _btnSave = new Button {Text = "Save"};

        _btnSave.Click += btnSaveClick;

        Controls.Add(_btnSave);

        Controls.Add(_txtName);

    }

 

    private void btnSaveClick(object sender, EventArgs e)

    {

        //some code here

    }

 

    protected override void RenderContents(HtmlTextWriter writer)

    {

        writer.RenderBeginTag(HtmlTextWriterTag.Div);

        writer.Write("Please, enter your name:");

        _txtName.RenderControl(writer);

        writer.RenderBeginTag(HtmlTextWriterTag.Br);

            writer.RenderEndTag();

        _btnSave.RenderControl(writer);

        writer.RenderEndTag();

    }

}

Shared Services in SharePoint 2010

Shared Services in SharePoint 2010

Shared Service Provider (SSP) in SharePoint 2007 has been replaced by Shared Services in SharePoint 2010. SSP in SharePoint 2007 was confusing and had its share of limitations which SharePoint 2010 seems to solve by introducing Shared Services.

Key differences between SSP and Shared Services

SSP in 2007	Shared Services in 2010
MOSS only	Available in WSS
Different services shared the same db	Services can have its own db
Internal to MOSS	Public APIs to create own Shared Services
Only one application of service	Multiple instances of service allowed
Restricted to the farm	Cross farm support

SharePoint 2010 provides the following Shared Services ( not an exhaustive list )

Access Services : Allows viewing, editing, and interacting with Access databases in a browser.
Business Connectivity Service : Provides read/write access to external data from line-of-business (LOB) systems, Web services, databases, and other external systems. Also available in SharePoint Foundation.
Managed Metadata Service : Provides access to managed taxonomy hierarchies, keywords, social tags and Content Type publishing across site collections.
Secure Store Service : Provides capability to store data (e.g. credential set) securely and associate it to a specific identity or group of identities.
State Service : Provides temporary storage of user session data for Office SharePoint Server components.
Usage and Health data collection : This service collects farm wide usage and health data and provides the ability to view various usage and health reports.
Visio Graphics Service : Enables viewing and refreshing of published Visio diagrams in a web browser.
Web Analytics Service Application : Enable rich insights into web usage patterns by processing and analyzing web analytics data .
Word Conversion Service Application : Provides a framework for performing automated document conversions

Deploying an ASP.NET HttpHandler to SharePoint 2010

 How to deploy an HttpHandler to SharePoint 2010 that uses code-behind.  The answer is that you don’t really use code-behind like you would in an ASP.NET application where the code and assembly are in the same folder.  With SharePoint, you need to deploy your code to the Global Assembly Cache (GAC).
You can create the code for an HttpHandler very easily in Visual Studio.  I am going to steal borrow some code from Ted Pattison’s walkthrough, “Creating a Custom HttpHandler in Windows SharePoint Services 3.0” on MSDN (includes a video as well).

using System;
using System.Web;
using Microsoft.SharePoint;

namespace ASHXHandlerDemo
{
    public class HelloHttpHandler : IHttpHandler
    {
        public bool IsReusable
        {
            get { return false; }
        }
 
        
        public void ProcessRequest(HttpContext context)
        {
            SPSite siteColl = SPContext.Current.Site;
            SPWeb site = SPContext.Current.Web;
            context.Response.ContentType = "text/plain";
            context.Response.Write("Hello HttpHandler from the site " +
                                   site.Title +
                                   " at " +
                                   site.Url);
        }
    }
}

The question is how to call that code?  When an HTTP request comes in, how do you map that request to this code? 
The easiest way is to create a .ASHX file and deploy it to the LAYOUTS directory in the SharePoint root (aka “14 hive”).  To do this, right-click your SharePoint project in Visual Studio 2010 and choose “Add SharePoint Layouts Mapped Folder”. 

In that newly created folder, add a new file with a .ASHX extension with the following contents.  The .ASHX file just points to the code in the GAC using the fully-qualified assembly name.

<%@ Assembly Name="Microsoft.SharePoint, Version=14.0.0.0, Culture=neutral, PublicKeyToken=71e9bce111e9429c" %>
<%@ Assembly Name="ASHXHandlerDemo, Version=1.0.0.0, Culture=neutral, PublicKeyToken=684a624f7b7a49ae" %>
<%@ WebHandler Language="C#"  Class="ASHXHandlerDemo.HelloHttpHandler" %>

The solution looks like this in Visual Studio 2010.

When you build and deploy your solution from Visual Studio, the code is compiled into an assembly (a .DLL) and registered in the Global Assembly Cache.  The output is:

Difference between Farm and Sandbox solutions in SharePoint

Farm Solutions:

Farm solutions, which are hosted in the IIS worker process (W3WP.exe), run code that can affect the whole farm. When you debug a SharePoint project whose Sandboxed Solution property is set to "farm solution," the system's IIS application pool recycles before SharePoint retracts or deploys the feature so as to release any files locked by the IIS worker process. Only the IIS application pool serving the SharePoint project's site URL is recycled.

Sandbox Solutions:

Sandboxed solutions, which are hosted in the SharePoint user code solution worker process (SPUCWorkerProcess.exe), run code that can only affect the site collection of the solution. Because sandboxed solutions do not run in the IIS worker process, neither the IIS application pool nor the IIS server must restart. Visual Studio attaches the debugger to the SPUCWorkerProcess process that the SPUserCodeV4 service in SharePoint automatically triggers and controls. It is not necessary for the SPUCWorkerProcess process to recycle to load the latest version of the solution.

How to add WFE(Web Front Servers) in SharePoint 2010

Solution:

You need to join the new server to the farm, then go to Services on Server (in Central Administration) and enable Microsoft SharePoint Foundation Web Application Service. Then you'll see that in IIS your websites and application pools appeared

Managed Accounts in SharePoint 2010

Microsoft SharePoint Server 2010 provides a number of compelling improvements designed especially for the system administrator, of these, commonly overlooked, are Managed Accounts.  A Managed Account is effectively an Active Directory user account whose credentials are managed by and contained within SharePoint.  In addition to storing the credentials of the object, Microsoft SharePoint Server 2010 can also leverage Active Directory Domain Policies to  automatically reset passwords while meeting the requirements established by policy.
How credentials are stored…
Managed Account credentials are encrypted using a farm encryption key that is specified when you run PSConfig[ui].exe at farm creation based on the passphrase.  The passphrase is stored in a secure registry location so that it can only be accessed by the farm account and encrypted so that only the farm account has access (we won’t get into the encryption specifics here). The farm encryption key subsequently, is stored in the Configuration Database.   This scenario is what enables farm administrators to join machines to the farm without specifying the credentials as had to be done in previous versions of the product.
The last sentence of the paragraph above illustrates one of immediate benefits of using Managed Accounts, for example, suppose an administrator would like to create a new Web application using Windows PowerShell and/or SharePoint Central Administration – the administrator only needs to specify the Application Pool account (Windows PowerShell) or select the account in the SharePoint Central Administration user interface as opposed to both having to know the domain\username and associated password.
Example (Windows PowerShell)
$provider = New-SPAuthenticationProvider -ASPNETMembershipProvider "LdapMember" -ASPNETRoleProviderName "LdapRole"
$webApp = New-SPWebApplication -Name "Claims" -ApplicationPool "Claims Application Pool" -ApplicationPoolAccount "CONTOSO\administrator"
  -Url http://claims.contoso.com -Port 80 -AuthenticationProvider $provider
Get Managed Accounts (SharePoint Central Administration)

1. To view existing Managed Accounts using SharePoint Central Administration, select Security from the SharePoint Central Administration homepage.
2. On the Security page select Configure managed accounts under General Security.
3. The Managed Accounts page will list all Managed Accounts registered in SharePoint.

Register Managed Accounts (SharePoint Central Administration)

1. To register new Managed Accounts using SharePoint Central Administration, select Security from the SharePoint Central Administration homepage.
2. On the Security page select Configure managed accounts under General Security.
3. On the Managed Accounts page select Register Managed Account.
4. On the Register Managed Account page (see illustration below) specify the credentials and select the password change policies as desired.

Get Managed Accounts (Windows PowerShell)

1. To view existing Managed Accounts using Windows PowerShell, open the SharePoint 2010 Management Shell and enter Get-SPManagedAccount at the prompt.  For additional information on using the Get-SPManagedAccount CmdLet enter Get-Help Get-SPManagedAccount at the prompt.

Register Managed Accounts (Windows PowerShell)

1. To register Managed Accounts using Windows PowerShell open the SharePoint 2010 Management Shell and use the Set-SPManagedAccount CmdLet (see below for syntax).

Syntax
New-SPManagedAccount [-Credential] <PSCredential> [-AssignmentCollection <SPAssignmentCollection>] [-Confirm [<SwitchParameter>]] [-WhatIf [<SwitchParameter>]]
Configure Managed Accounts (Windows PowerShell)

1. To configure Managed Accounts using Windows PowerShell open the SharePoint 2010 Management Shell and use the Set-SPManagedAccount CmdLet (see below for syntax).

Syntax
Set-SPManagedAccount -Identity <SPManagedAccountPipeBind> [-AssignmentColle
ction <SPAssignmentCollection>] [-Confirm [<SwitchParameter>]] [-EmailNotif
ication <Int32>] [-PreExpireDays <Int32>] [-Schedule <String>] [-WhatIf [<S
witchParameter>]] [<CommonParameters>]
Set-SPManagedAccount -Identity <SPManagedAccountPipeBind> [-AssignmentColle
ction <SPAssignmentCollection>] [-AutoGeneratePassword <SwitchParameter>] [
-Confirm [<SwitchParameter>]] [-EmailNotification <Int32>] [-PreExpireDays
<Int32>] [-Schedule <String>] [-WhatIf [<SwitchParameter>]] [<CommonParamet
ers>]
Set-SPManagedAccount -Identity <SPManagedAccountPipeBind> -ConfirmPassword
<SecureString> -NewPassword <SecureString> [-AssignmentCollection <SPAssign
mentCollection>] [-Confirm [<SwitchParameter>]] [-EmailNotification <Int32>
] [-PreExpireDays <Int32>] [-Schedule <String>] [-SetNewPassword <SwitchPar
ameter>] [-WhatIf [<SwitchParameter>]] [<CommonParameters>]
Set-SPManagedAccount -Identity <SPManagedAccountPipeBind> -ExistingPassword
<SecureString> [-AssignmentCollection <SPAssignmentCollection>] [-Confirm
[<SwitchParameter>]] [-EmailNotification <Int32>] [-PreExpireDays <Int32>]
[-Schedule <String>] [-UseExistingPassword <SwitchParameter>] [-WhatIf [<Sw
itchParameter>]] [<CommonParameters>]
For additional information on using the Set-SPManagedAccount CmdLet enter Get-Help Set-SPManagedAccount at the prompt.

Difference between Application Server and Web Server 

Application Server:

 Application server maintains the application logic and serves the web pages in response to user request. That means application server can do both application logic maintanence and web page serving. 

Web Server: 

Web server just serves the web pages and it cannot enforce any application logic. Final conclusion is: Application server also contains the web server.