Solution Package

A solution package is a distribution package that delivers your custom SharePoint Server 2010 development work to the Web servers or the application servers in your server farm. Use solutions to package and deploy custom Features, site definitions, templates, layout pages, Web Parts, cascading style sheets, and assemblies.

A solution package is a CAB file with a .wsp file name extension and a manifest file. It is recommended that you use Visual Studio 2010 Tools for SharePoint 2010 to develop and package SharePoint solutions. You can also create solution packages manually by using a tool such as Makecab.exe.

Components that can be packaged in a solution include:

• .NET Framework assemblies, typically Web part assemblies and event receiver assemblies.
  
• Deployment files such as resource files, pages, or other helper files.
  
• Features, which allow you to activate and deactivate code in a Web site and provide functionality that include elements such as custom lists, libraries, fields, and content types.
  
• New templates and site definitions.
  
• Configurations that must be performed at the Web-server level — for example, deploying customizations to the Web.config files for the registration of Web Parts. You can also modify these configurations with a Feature that is distributed with a Feature.
  
• Web content such as Web pages and images that are called by Web pages. If you must deploy Web content in a disconnected environment, you should use a content deployment package.

What problems WSP solves?Suppose you developed a custom solution for sharepoint and now is the time to deploy that to production. Your solution included set of Features, site definitions, assemblies, Web Part packages, class resources etc etc. Now the production has 3 Web Front Ends, an Application server and a SQL backend.

In an ideal world, the infrastructure (i.e. the farm) is under the control of Administrators and you handed over your solution to them for deployment. Now the Administrator has no idea what your solution does, what are these resources, where to put them and what configuration is necessary to make them work. He is simply baffled at what you just handed over to him, coz he knows that he has to do that for all the 3 Web Front Ends and the Application server one by one. This is problem no. 1.

In a real world, ofcourse it will be you yourself who will be deploying the solution to production (yeah, we all know that). So, even if you know exactly how the solution works and where should you put what, it is going to be tedious and error prone to get everything right for all the Front Ends and Application Servers. You miss one file or one configuration setting at one place and you could be fired  . Why, coz when you deployed everything, you tested and you were hitting Web Front End1 all the time and it was sublime, however, when your Boss tested, he managed to hit Web Front End2 because of load balancing among the 3 Web Front Ends, which was exactly the server where you messed up a configuration setting or was missing a file and the application failed. This is problem no. 2

So, to resolve these two problems we use solution files (.wsp). Read on.

Definition and Benefits: Wsp is a single file that contains all your resources including Features, site definitions, assemblies, Web Part packages, class resources etc etc. This file is used to deploy your solution to the entire farm in one go. You do not need to go to separate servers one by one for deployment. Timer Jobs will be created on each Web Front End in the farm. When the timer service on each server will run, it will execute the timer jobs and completes the deployment.

Now the farm Admin is happy coz he needs not know whats inside the wsp. He simply has to take the .wsp file and deploy once and for all, no need to go to each and every Web Front End or Application Server (solves problem no.1). And, you are happy coz you dont need to worry that all the files are gonig to all the places, and i.e. all the right places, making sure all configuration settings are OK, and last but not the least, your Boss tested successfully (solves problem no.2).

Deployment is a process of Distributing, Unpacking and Installing solutions to a SharePoint server farm.
Solution File is an Easy, Safe, Consistent and Reusable way of Deployment.
Sounds great, isn’t it.

Now let’s see how to build wsp files.

Building Solution Packages (.wsp files):There could be three ways to build a solution package (.wsp file).

1. Manually
2. DDF File
3. WSPBuilder

Manually, you dont want it.

DDF stands for Diamond Definition File, Diamond Directive File…………whatever you may want to call it. Using DDF is tedious. It’s the ancient way of building WSPs. You have to write a Manifest.xml manually (this file tells what to put on the server farm and where to put it), then you have to write a .ddf file manually (its an instruction file that tells the compiler what to put in the wsp package i.e. in .wsp file), and then compile using makecab.exe which will read your .ddf file and give you a .wsp file. So, this is the old way of doing things, what’s new then.

It is WSPBuilder. What WSPBuilder does:

1. Generates the solution package (.wsp file) for you automatically with a click, Period.

So, you save all the hassle of writing Manifest.xml. WSPBuilder will automatically generate it for you and put that in the .wsp file. No need for DDF file. No need for makecab.exe.

Newer versions of WSPBuilder will even Deploy, Upgrade, Uninstall solution packages along with many other features. I am trying to stick myself only to building and deploying solution packages and their schema.

Real World Example:Now, I want to do a real world example of a WSPBuilder and talk about some of the elementsin Manifest.xml file and how to manipulate them for our custom needs.

Why Manifest.xml, coz we said that “what to put and where to put” is specified in Manifest.xml. So, if this is automatically generated by WSPBuilder, it can know about “what to put” as we will be using WSPBuilder from within Visual Studio where our custom solution is, but how will it know “where to put”. Here is the reason why we want to discuss elementswithin Manifest.xml.

Download and Install WSPBuilder Extensions from here (latest version as of today is 1.0.6):
http://wspbuilder.codeplex.com/Release/ProjectReleases.aspx?ReleaseId=30858

Open any of your sharepoint projects in Visual Studio. I wrote a sharepoint event handlerpost here and will be using the same project for this example. So, I will create a solution package using “WSPBuilder Extensions for Visual Studio” to deploy my “Event Handler Feature” to a sharepoint farm.

Installation is very simple and I assume you did that successfully. In visual studio right click your project and you will see the following:

 You can now see lots of features available with this tool. Click Build WSP. Output screen will display something like this:

 

 If you received an error message about cablib.dll, look here.

Now go to your project directory on the file system. You will see that two new files are added there:

 Solutionid.txt contains just a GUID that is used in Manifest.xml. So, where is Manifest.xml. Lets find out. Rename your .wsp file and change the extension to .cab:

 Double click the .cab file and open. This is what you see:

Note the Path tab in the figure above. WSP will not show you folder structures but it will keep track of folders using this path value. 

So the wsp contains my ”Event Handler’s DLL”, “Feature.xml” and “Elements.xml” (remember that I am implementing my event handler as feature). Three of these files are part of my custom solution and not generated by WSPBuilder. The only thing WSPBuilder generated is the Manifest.xml. Lets see whats inside it and what it means (and ofcourse how to manipulate it):

What’s this Manifest.xml:
<?xml version="1.0"?>
<!-- Solution created by WSPBuilder. 2/12/2009 4:31:46 PM  -->
<Solution SolutionId="f33a01ff-84d9-481f-8c60-8f3e661c734b" xmlns="http://schemas.microsoft.com/sharepoint/">
  <Assemblies>
    <Assembly Location="EventHandler.SharePoint.SendEmail.Feature.dll" DeploymentTarget="GlobalAssemblyCache" />
  </Assemblies>
  <FeatureManifests>
    <FeatureManifest Location="EventHandler.SharePoint.SendEmail.Feature\feature.xml" />
  </FeatureManifests>
</Solution>

First element of a Manifest.xml is always a <Solution>. You can see the GUID from solutionid.txt being used in SoutionId attribute.

Other elements in Manifest.xml specify three things:

1. What is in the WSP
2. Where is it placed in the WSP
3. Where should it be placed in the server farm

Note these questions as I’ll refer to these below. Anwers to these questions will vary with theelement type. Every element has an associated default location with it that answers question no. 3 i.e. Where should it be placed in the server farm.

<Assembly>******************************************************
Lets examine these elements and their attributes one by one. Lets first take the element <Assembly>.

<Assemblies>
    <Assembly Location="EventHandler.SharePoint.SendEmail.Feature.dll" DeploymentTarget="GlobalAssemblyCache" />
</Assemblies>

• Assembly element is telling the installer that this is going to be an assembly. Answers question no. 1. 
• Location attribute is telling the installer to look for the “EventHandler.SharePoint.SendEmail.Feature.dll” at the root of the WSP file. Answers question no. 2.
• DeploymentTarget is telling the installer to deploy it to GlobalAssemblyCache (GAC). Answers question no. 3. 

So, the Manifest is telling the installer to get EventHandler.SharePoint.SendEmail.Feature.dll from the root directory from within the wsp and deploy it to Global Assembly Cache (GAC).

Other option would have been DeploymentTarget = “WebApplication”, in that case the dll would have been deployed to the bin folder of the web application.
********************************************************

<FeatureManifest>********************************************************
In the case above, DeploymentTarget was mentioned separately, however, this is not the case with <FeatureManifest> element. Let’s have a look:

<FeatureManifests>
    <FeatureManifest Location="EventHandler.SharePoint.SendEmail.Feature\feature.xml" />
</FeatureManifests>

• FeatureManifest is telling the installer that this is a feature. Answers question no. 1.


• Location is telling the installer to look for feature.xml file in EventHandler.SharePoint.SendEmail.Feature directory within wsp file. So, once again, you wont see “EventHandler.SharePoint.SendEmail.Feature” folder inside the .wsp file, it is calculated based on the path value as shown above. Answers question no. 2.


• Now how does the installer find out where to deploy this feature.xml. That is hidden in the element type as mentioned before. FeatureManifest element is used to specify features, so this element type has a location associated with it. That location is root of all the Features in sharepoint. Can you guess it now, yeah it is 12\TEMPLATE\FEATURES, where all sharepoint Features reside. Answers question no. 3.

So, the Manifest is telling the installer to get feature.xml from EventHandler.SharePoint.SendEmail.Feature directory from within the wsp and deploy it to
12\TEMPLATE\FEATURES\EventHandler.SharePoint.SendEmail.Feature\feature.xml.

*******************************************************

<TemplateFile>*******************************************************
Similarly, there could have been a TemplateFile element in the Manifest.xml had my solution contained a user control:

<TemplateFiles>
    <TemplateFile Location="ControlTemplates\SendEmailForm.ascx"/>
</TemplateFiles>

• TemplateFile is telling the installer that this is a Template File. (Answers question no. 1).


• Location is telling the installer to look for the control SendEmailForm.ascx file in ControlTemplates directory within the wsp file. Answers question no. 2.


• Now how does the installer find out where to deploy SendEmailForm.ascx control. That is hidden in the element type. TemplateFile element is used to specify template files, so this element type has a location associated with it. That location is the root of all the templates in sharepoint. Ofcourse you guessed it this time i.e. 12\TEMPLATE, where all sharepoint templates reside. Answers question no. 3.

Now, if you examine the TEMPLATE folder under 12 hive, you will notice that there is a CONTROLTEMPLATES directory with lots of user controls already in there.

So, the Manifest is telling the installer to get SendEmailForm.ascx from ControlTemplates directory from within the wsp and deploy it to 12\TEMPLATE\CONTROLTEMPLATES\SendEmailForm.ascx.
******************************************************

Conclusion (sort of  )
In the case of FeatureManifest, “EventHandler.SharePoint.SendEmail.Feature” folder was not available in FEATURES directory but mentioned in Manifest.xml, so the installer will create a new folder with that name and put “feature.xml” in it. In the case of TemplateFile, ”CONTROLTEMPLATES” directory was already available under “TEMPLATE” folder, but “CONTROLTEMPLATES” was also mentioned in Manifest.xml, even then the installer will not create a new directory and use the existing “CONTROLTEMPLATES” directory and put “SendEmailForm.ascx” in it.

So, if its an existing directory, use the same one, otherwise create new.

I hope by now you have got a good idea of how this works. Here is a list of Elements and the associated root locations:

Manifest Element	Root Location
WebTempFile	12\Template
Assembly	Web Application bin or GAC
FeatureManifest	12\TEMPLATE\FEATURES
RootFileResourceFile	12
ResourceFile	12\TEMPLATE\FEATURE
SiteDefinitionManifest	12\TEMPLATE\SiteTemplates
TemplateFile	12\TEMPLATE
ApplicationResourceFile	12\Resources

Manipulating Manifest.xml:Now, you may be thinking that directory structures could be specified as of our likinng in Manifest.xml. That’s not always true. Some may actually fail. For instance, if you specify “Location = MyFeature\EventHandler.SharePoint.SendEmail.Feature\feature.xml” for a <FeatureManifest> element, this will not work and you may actually receive an error message. Its coz Features can only locate directly under FEATURES directory. The immediate directory under FEATURES directory should have feature.xml in it. If you try to create ”MyFeature” directory, then “EventHandler.SharePoint.SendEmail.Feature” directory and this has feature.xml in it, this will not work.

However, if you want a different directory for your controls to separate them from sharepoint controls then you may specify the following directory structure without any problems:



<TemplateFiles>
    <TemplateFile Location="ControlTemplates\MyCustomControls\SendEmailForm.ascx"/>
</TemplateFiles>

This will create “MyCustomControls” directory in “CONTROLTEMPLATES” and put “SendEmailForm.ascx” in it.

Deploying using solution packages (.wsp files):Oh, I forgot, we still have to deploy the solution. So, first we add it to the Solution Store and then deploy it. Here are the commands to do so:



stsadm.exe -o addsolution -filename "c:\EventHandler.SharePoint.SendEmail.Feature.wsp"

Adding always involves STSADM command. You can deploy either by STSADM or Central Administration. If you wish you can deploy using the following STSADM command, but I am going to do it using Central Administration:

stsadm.exe -o deploysolution -name "c:\EventHandler.SharePoint.SendEmail.Feature.wsp" -immediate -allowGacDeployment -allowCasPolicies -force


Go to Central Administration -> Operations -> click Solution Management (under Global Configuration)
You will see your solution as “Not Deployed”, though added to the solution store:

Click the wsp file and click “Deploy Solution on the following screen:

Select “Now” and click OK:

Wait for sometime and (if everything goes fine), you should see the following screen with status as “Deployed”:

Now you can go and see your feature created under FEATURES directory in 12 hive (only if your custom solution created a Feature):

Your feature will also appear in “Site Features”:

That’s it. 

What really happens during SharePoint 2010 Solution Deployment/Retraction and Feature Activation/Deactivation Process?

Have you ever wondered what really happens when you deploy/retract SharePoint WSPs and Activate/Deactivate site collection or sub site level features at the farm level? As you execute different PowerShell commands or activate/deactivate features from browser interface, SharePoint 2010 makes several changes at the different places on the servers and databases.

This article provides high level overview of what really happens when you execute different farm level PowerShell commands. Hopefully it will be helpful. 

	Central Admin	Site/Web Level Features	GAC	Web.Config	14-RootFeatures	SharePoint Config DB, Objects Table – Solutions	SharePoint Config DB, Objects Table – Features	Web App Content DB, Features Table
Add-SPSolution	Solution Added but Not Deployed	N/A	N/A	N/A	N/A	Yes – Solution Definition Added	N/A	N/A
Install-SPSolution	Deployed to Web App	Installed Feature	Yes – DLLs Added	Yes – Safe Control Entries Added	Yes – Features Added	Yes – Solution Definition Still Exists	Yes – Feature Definition Added	N/A
Enable-SPFeature	Solution Still Deployed	Activated feature to Site/Web	Yes – Still Exists	Yes – Still Exists	Yes – Still Exists	Yes – Solution Definition Still Exists	Yes – Feature Definition Still Exists	YES – Feature Activation Link Added
Disable-SPFeature	Solution Still Deployed	Deactivated feature from Site/Web	Yes – Still Exists	Yes – Still Exists	Yes – Still Exists	Yes – Solution Definition Still Exists	Yes – Feature Definition Still Exists	NO – Feature Activation Link Deleted
UnInstall-SPFeature	Solution Still Deployed	Uninstalled feature	Yes – Still Exists	Yes – Still Exists	Yes – Still Exists	Yes – Solution Definition Still Exists	No – Feature Definition Deleted	N/A
UnInstall-SPSolution	Retracted from Web App	Uninstalled feature	No – DLLs Deleted	No – Safe Control Entries Deleted	No – Features Deleted	Yes – Solution Definition Still Exists	No – Feature Definition Deleted	N/A
Remove-SPSolution	Solution Deleted	N/A	N/A	N/A	N/A	Yes – Solution Definition Deleted	N/A	N/A

 

How to Show Events from Multiple Calendars in a Single View Using Calendars Overlay

We use the Calendars Overlay feature, available via the Ribbon, to roll up multiple calendars into a single presentation.

In my example, I have three sites: Site_1, Site_2, and Site_3. I have a Calendar list on each site, and their names are Calendar_Site_1, Calendar_Site_2, and Calendar_Site_3. But how do I show events from Calendar_Site_2 and Calendar_Site_3 on Calendar_Site_1 ?

Step 1. Open Calendar_Site_1 and click on the Calendars Overlay feature:

Step 2. Click New Calendar to add Calendar(s) from other sites:

Step 3. Enter Calendar Name, and select the type of calendar (SharePoint in the case of my example). Enter the URL of the website you just created and then select the new Calendar list and the default Calendar view. (Note that linking to Exchange calendars is the other option in the Calendars Overlay function.):

Step 4. Click OK

You can see that Calendar_Site_2 has been created in Additional Calendars:

Step 5. Repeat step 2 to create Calendar_Site_3:

Step 6. Click OK.

You can now see all three Calendar Lists shown in the same view:

Custom Page Layout for Publishing Sites Using Visual Studio 2010

I. Create a new content type

Your new content type must inherit from the Page content type.

Open Visual Studio 2010 (which features integrated Developer Tools for SharePoint  2010) and create a new Empty SharePoint Project:

Click OK when you finish naming your project, and remember to select your deployment type as farm solution.

Next, right-click on your project name in the Solution Explorer window, then click Add -> New Item. In the Add New Item dialog, choose the Content Type project item template:

Click Add when you finish.

The SharePoint Developer Tool will ask which parent content type your content type derives from. Choose the Pagecontent type:

The SharePoint Developer Tool will generate an element.xml file which contains your page content type definition. Note that your content type ID was generated by the SharePoint Developer Tool based on its parent's ID, so it should be kept as is.

Next, add some site columns to your element.xml file (these will be used by your page content type).

See my example:

   1: <?xml version="1.0" encoding="utf-8"?>

   2: <Elements xmlns="http://schemas.microsoft.com/sharepoint/">

   3:   <!-- new site column for custom page layout named Title -->

   4:   <Field ID="{7024BCAE-DBB8-4E09-88E6-49D3B22C9111}"             

   5:   Name="BBTitle" DisplayName="Title" Group="BambooSiteColumn"

   6:   Type="Text" Required="FALSE" Sealed="FALSE" Hidden="FALSE" />   

   7:  

   8:   <!-- new site column for custom page layout named Header -->

   9:   <Field ID="{4837C657-45B0-45A2-A548-945DB9D9189F}"

  10:   Name="BBHeader" DisplayName="Header" Group="BambooSiteColumn"

  11:   Type="HTML" Required="FALSE" Sealed="FALSE" Hidden="FALSE" />

  12:  

  13:   <!-- new site column for custom page layout named Body -->

  14:   <Field ID="{6C736E06-56C1-4AA1-AB0F-4712FAA2A8C4}"

  15:   Name="BBBody" DisplayName="Body" Group="BambooSiteColumn"

  16:   Type="HTML" Required="FALSE" Sealed="FALSE" Hidden="FALSE" />

  17:  

  18:   <!-- new site column for custom page layout named Footer -->

  19:   <Field ID="{933EB014-B49D-4358-9043-1ECC565D283F}"

  20:   Name="BBFooter" DisplayName="Footer" Group="BambooSiteColumn"

  21:   Type="HTML" Required="FALSE" Sealed="FALSE" Hidden="FALSE" />

  22:  

  23:   <!-- Parent ContentType: Page (0x010100C568DB52D9D0A14D9B2FDCC96666E9F2007948130EC3DB064584E219954237AF39) -->

  24:   <ContentType ID="0x010100C568DB52D9D0A14D9B2FDCC96666E9F2007948130EC3DB064584E219954237AF3900cfafe608e5a04292b41c5df1ac147f0b"

  25:                Name="MyPageContentType"

  26:                Group="Bamboo Custom Content Types"

  27:                Description="My page content type for my custom page layout"

  28:                Inherits="TRUE"

  29:                Version="0">

  30:     <FieldRefs>

  31:       <FieldRef ID="{7024BCAE-DBB8-4E09-88E6-49D3B22C9111}" Name="BBTitle" />

  32:       <FieldRef ID="{4837C657-45B0-45A2-A548-945DB9D9189F}" Name="BBHeader" />

  33:       <FieldRef ID="{6C736E06-56C1-4AA1-AB0F-4712FAA2A8C4}" Name="BBBody" />

  34:       <FieldRef ID="{933EB014-B49D-4358-9043-1ECC565D283F}" Name="BBFooter" />

  35:     </FieldRefs>

  36:   </ContentType>

  37: </Elements>

In my example, I have four site columns which are referenced by four FieldRef elements inside ContentType element. What you should note here is the FieldFef's ID and Name should match the Field's ID and Name (the site columns ID and Name)

Note: To generate a GUID, you can use the GUID Generator tool in Visual Studio 2010 (go to Start -> All Programs -> Microsoft Visual Studio 2010 -> Microsoft Windows SDK Tools -> GUID Generator).

II. Create a custom page layout

It's an application page (.aspx) which will be used as a page template in a Publishing site.

To create one, right-click on your project name in the Solution Explorer window, then click Add -> New Item. In theAdd New Item dialog, choose the Model project item template:

Click Add when you've finished.

The SharePoint Developer Tool will generate two files: element.xml and Sample.txt. Rename Sample.txt as an aspx page (my example is PublishingPageLayout.aspx).

Your project structure should now look like the image below:

Next, open your .aspx file and add content to it:

   1: <%@ Page language="C#" Inherits="Microsoft.SharePoint.Publishing.PublishingLayoutPage" %>

   2: <%@ Register Assembly="Microsoft.SharePoint" Namespace="Microsoft.SharePoint.WebControls" TagPrefix="SharePointWebControls" %>

   3: <%@ Register Assembly="Microsoft.SharePoint.Publishing" Namespace="Microsoft.SharePoint.Publishing.WebControls" TagPrefix="PublishingWebControls" %>

   4:  

   5: <asp:Content runat="server" contentplaceholderid="PlaceHolderPageTitle">

   6:     <SharePointWebControls:FieldValue id="PageTitle" FieldName="Title" runat="server"/>

   7: </asp:Content>

   8:  

   9: <asp:Content runat="server" contentplaceholderid="PlaceHolderPageTitleInTitleArea">

  10:     <SharePointWebControls:TextField ID="TitleField" FieldName="Title" runat="server" />

  11: </asp:Content>

  12:  

  13: <asp:Content runat="server" contentplaceholderid="PlaceHolderMain"> 

  14:     <SharePointWebControls:TextField ID="TextField1" FieldName="BBTitle" runat="server"/>

  15:     <br />

  16:     <PublishingWebControls:RichHtmlField ID="RichHtmlField1" FieldName="BBHeader" runat="server"/>

  17:     <br />

  18:     <PublishingWebControls:RichHtmlField ID="RichHtmlField2" FieldName="BBBody" runat="server"/>

  19:     <br />

  20:     <PublishingWebControls:RichHtmlField ID="RichHtmlField3" FieldName="BBFooter" runat="server"/>

  21: </asp:Content>

Your page layout should inherit the PublishingLayoutPage class which is contained in namespace Microsoft.SharePoint.Publishing.WebControls in the assembly Microsoft.SharePoint.Publishing. Remember to add a reference to Microsoft.SharePoint.Publishing in your project. It is found at C:\Program Files\Common Files\Microsoft Shared\Web Server Extensions\14\ISAPI. The controls, such as SharePointWebControls (TextField) and PublishingWebControls (RichHtmlField), should reference the site columns defined in your page content type.

Next, open your element.xml in your Model folder and add a File element inside the Module element to refer to your page layout:

   1: <?xml version="1.0" encoding="utf-8"?>

   2: <Elements xmlns="http://schemas.microsoft.com/sharepoint/">

   3:   <Module Name="MyModel" RootWebOnly="TRUE" Url="_catalogs/masterpage">

   4:     <File Path="MyModel\PublishingPageLayout.aspx" Url="MyModel/PublishingPageLayout.aspx" Type="GhostableInLibrary" >

   5:       <Property Name="PublishingAssociatedContentType" Value=";#MyPageContentType;#0x010100C568DB52D9D0A14D9B2FDCC96666E9F2007948130EC3DB064584E219954237AF3900cfafe608e5a04292b41c5df1ac147f0b;#" />

   6:       <Property Name="ContentType" Value="$Resources:cmscore,contenttype_pagelayout_name;" />

   7:       <Property Name="Title" Value="My Bamboo Publish Page Layout" />

   8:     </File>

   9:   </Module>

  10: </Elements>

The module needs to be configured to provision the file as content in the library, so we set the File's Type attribute to GhostableInLibrary.

The Property elements are used to specify the values of certain metadata fields in the Master Page Gallery.

Note: The property, with name PublishingAssociatedContenttype, should have its Value refer to your page content type. Its value is separated by character ;# (first part is content type name, and second part is content type ID).

That's all there is to it. Now, build your project and deploy it to your farm servers (or press F5 to test and debug the project on your selected Web application).

III. Using custom page layout

To use your custom page layout in a Publishing Site, first activate the feature at your site collection.

Go to Site Actions -> Site Settings -> Site collection features (under Site Collection Administration section):

Then, create a Publishing Site (if you don't have one) by going to Site Actions -> New Site:

Note: If you can't find the Publishing Site template, go to your Site collection features and activate the SharePoint Server Publishing Infrastructure feature:

Your publishing site should look like the image below:

Click on the Page tab -> Edit -> Page Layout:

Then, select your page layout to apply in your publishing site as a page template.