I found LINQPad a very useful tool to create and test LINQ queries outside visual studio. LINQPad is also a great way to learn LINQ. It supports LINQ to objects,
LINQ to Sql, LINQ to Entities etc. It shows the lambda expression view and SQL view for your queries written in query comprehension syntax.
You can connect LINQPAD to Sql server/SQL CE databases and start developing quarries using LINQ expressions without having to create any Data Contexts.
I’ve connected LINQPAD to AdventureWorks database which contains following sub schema.
Once connected to the database you can start developing LINQ to SQL queries. I am fetching a product with its higher rating reviews as a hierarchical projection using C# query comprehension expression syntax.
Once the query is executed the results tab displays the results as a hierarchical graph as shown below.
The Lambda Expression tab shows how the compiler converted our queary to Lambda expression.
Also the SQL tab shows the generated SQL statement by the LINQ query.
In addition to C# expressions you can also develop C# statements and display output at any stage using Dump() extension method provided. The following C# Statement fetch all document information for a given product. Note that the Dump method display the result set graphically which makes it so much easier to develop/debug LINQ quarries.
LINQPaD run as a standalone exe and no installation is required. It runs on .NET 3.5. Hope this helps.
Site definition can be considered as a blueprint of a SharePoint site. When developing business solutions on WSS platform sometimes we will have to create our own site definitions to incorporate functional business modules. Site Definitions gives you lots of flexibility in terms of maintaining and upgrading your solutions compared to Site Templates. Its also gives us the flexibility of choosing custom layouts and the ability to pre program the sequence of the feature activation order when you create a new site based on the definition.
In this post I will outline the steps that we have to follow when Creating a custom Site definition with a Custom master page. I am a fan of WSPBuilder as a development tool by Carsten Keutmann because it light to use over WSeWSS 1.3 and does not abstract too much from how the solution artifacts get deployed to your farm environment. Also its great for team development plays nice with TFS and Nightly Build Automation with MSBuild.
I will not be able to cover the details of how to create a custom master page here. So I will be using one of the out of the box default master page as a sample.
Lets get Started.
1. Create a WSPBuilder Project
I am using Visual studio 2008 with WSPBuilder extensions 1.0.6. Once extensions are installed VS will light up with new WSPBuilder project types as shown
below. Select WSPBuilder project and give your project a name.
2. Create 12 hive folder Structure within your solution.
One of the nice feature I like about WSPBuilder is that we can develop against 12 hive folder hierarchy in dev environment.
Standard 12 hive folder structure is shown in left. The folders that we are interested for this task of deploying a custom site definition are highlighted. All standard and custom site definitions with their default pages/schemas lives in SiteTemplates folder. All Features and feature manifests resides in FEATURES folder. So we will create this structure within our solution relative to 12 hive holder (C:\Program Files\Common Files\Microsoft Shared\web server extensions\12\)
Once folders are created inside the solution it should look as follows.
3. Create the site definition.
Create a sub folder inside SiteTemplates folder. This folder will contain all out custom site definition files. I call mine DevSiteTemplate. Instead of creating the definition files from scratch i will copy standard team site definition from 12 hive (C:\Program Files\Common Files\Microsoft Shared\web server extensions\12\TEMPLATE\SiteTemplates\sts) into my DevSiteTemplate folder. You can delete Defaultdws.aspx file as we do not need it for our requirement.
4. Update master page reference in default.aspx file
We are going to use our own master page in our site definition. Therefore we need to change default.master -> custom.master in our default.aspx page. Our custom master page will be created little later and SharePoint will replace custom.master reference with our master page during runtime page rendering based on the site definition schema (onet.xml) which we defined later on.
5. Update Configurations in onet.xml file
A Site definition can have many configurations. Because we have used Standard Team site definition as our base definition we can remove unused configurations. Std. Team site definition contains three configurations
0 : Default 1:Blank 2:DWS
We are going to use the Default Configuration (0) . Therefore we can remove Blank and DWS Configurations as well as their module sections
Following code segment shows the original onet.xml file contents
After removing the configurations onet.xml file should look as follows
6. Create the Custom Master page Feature
We need to add new feature to apply the master page to our site definition. The advantage of creating a separate feature for master page instead of depend on the site definition is that it can be operated independent from our site definition. In other words its all about loose coupling and reusability.
Right Click the project and Add a new “Web” Scope blank feature. I call it DevSiteMaster. WspBuilder will create feature folder for us with in the FEATURES folder along with the feature.xml file and element.xml file.
feature.xml describes the feature and its id,scope and metadata. feature.xml file reference the element.xml file which describes the real work load for the feature.
Create a folder named MasterPages inside the feature folder to add our custom master page. Now we need to add our custom master page to our solution. For this demo I will be using one of the out of the box master page (default.master) from 12 hive Global folder (C:\Program Files\Common Files\Microsoft Shared\web server extensions\12\TEMPLATE\GLOBAL). Copy default.master page into the MasterPages folder. Then rename default.master to devsite.master.
Now our solution folder structure should look like below.
Now we need to add our custom master page to our solution. I will be using one of the out of the box master page (default.master) for this example from 12 hive Global folder (C:\Program Files\Common Files\Microsoft Shared\web server extensions\12\TEMPLATE\GLOBAL).
7. Update Feature.xml and Element.xml files
Update the WspBuilder generated feature file with the settings required for our master page feature. Add the ElementFile section which reference our custom master page.
<?xml version="1.0" encoding="utf-8"?> <Feature Id="a349b379-6fda-41bf-9fe2-cfad70c99f0b" Title="DevSiteMaster" Description="Custom master page feature for DevSiteMasters" Version="184.108.40.206" Hidden="FALSE" Scope="Web" DefaultResourceFile="core" xmlns="http://schemas.microsoft.com/sharepoint/"> <ElementManifests> <ElementManifest Location="elements.xml"/> <ElementFile Location="MasterPages\devsite.master"/> </ElementManifests> </Feature>
Update element.xml file and a module element to copy our custom master page from our MasterPages folder path to master page gallery of the underlying web. Now when DevSiteMaster Feature get activated the job defined in our element.xml file get executed. As a result our custom master page get added into the master page gallery of the underlying sub web.
<?xml version="1.0" encoding="utf-8" ?> <Elements xmlns="http://schemas.microsoft.com/sharepoint/"> <Module Name="DevSiteMasterPage" Url="_catalogs/masterpage" Path="MasterPages" RootWebOnly="FALSE"> <File Url="devsite.master" Type="GhostableInLibrary"/> </Module> </Elements>
8. Update onet.xml file and add the DevsiteMasterPage feature into the list WebFeatures.
The Features specified in the SiteFeatures and WebFeatures section that get activated as part of site provisioning process based on the site definition. Also they get activated in the order specified. We need to define our custom master feature under WebFeatures. If our master page feature had been a “Site” scoped feature we would specify under siteFeatures section.
<WebFeatures> <Feature ID="00BFEA71-4EA5-48D4-A4AD-7EA5C011ABE5" /> <!-- TeamCollab Feature --> <Feature ID="F41CC668-37E5-4743-B4A8-74D1DB3FD8A4" /> <!-- MobilityRedirect --> <!-- devsite custom master page--> <Feature ID="a349b379-6fda-41bf-9fe2-cfad70c99f0b" /> </WebFeatures>
9. Update onet.xml default configuration to use our Custom master page.
Update default configuration and specify the that our confiugration should used our custom master page by setting the CustomMasterUrl and MasterUrl points to our custom master page living in the master page galley. By setting these values we effectively telling SharePoint that when ever .aspx refers to custom.master page replace that with devsite.master page which is our custom master page.
<Configuration ID="0" Name="Default" CustomMasterUrl ="_catalogs/masterpage/devsite.master" MasterUrl="_catalogs/masterpage/devsite.master">
10. Create WEBTEMP*.xml file for the Custom SiteDefinition.
WebTemp*.xml add our custom site definition into the catalogue of site definitions so that we can use pick the site defintion to provision from create site and workspace application pages. It is important that the Template Name exactly match our site definition name as shown below. Create a folder called xml inside 1033 folder and create webtemp*.xml file inside the folder named xml. This file name must begin with “webtemp” prefix as required by SharePoint. In this demo I call it WebTempDevSite.xml
<?xml version="1.0" encoding="utf-8"?> <Templates xmlns:ows="Microsoft SharePoint"> <Template Name="DevSiteTemplate" ID="75999" SetupPath="SiteTemplates\DevSiteTemplate" > <Configuration ID="0" Title="Dev Site" Hidden ="false" ImageUrl="/_layouts/images/stsprev.png" Description="A Custom Site Definition based on Team site" DisplayCategory="Custom Templates" > </Configuration> </Template> </Templates>
Our final solution structure should now look as follows.
All done! Our solution is now ready for package up into .wsp solution file and deploy into the SharePoint Farm. WSPBuilder will take the heavy lifting from here including creating manifest files,DDF files and packaging up our solution. Therefore Right Click our project and select Deploy option from WSPBuilder menu.
This action will build and package our solution, add it to the SharePoint solution store and deploy the solution by invoking STSADM.
Once succesfully deployed we should be able to create site based on our custom site definition as follows.
The visual studio solution associated with this post can be downloaded from here. Hope this helps with creating a custom site Definitions with a custom master page using WSPBuilder.
I recently wanted to apply a theme for a SharePoint Site via Feature. I wanted to achieve this with a SharePoint solution so that it helps our team development / Continuous integration approach . WSS allows you to attach features to site definitions via feature stapling so that we don’t have to touch the the site definition files or artefacts to enhance site definition. This is the best practice for modifying out of the box site definitions.
In this post I am going to go through the steps I have taken to achieve this task with VSeWSS 1.3 toolkit and visual studio 2008 .
1. Create a new Empty SharePoint project
2. Select Full Trust level so that your assembly get deployed to GAC during deployment.
3. Visual studio creates an empty project. Now we need to add our theme files to the solution. Theme files get deployed to 12 hive templates/Themes folder. Therefore Add a new item to the project and select “Template” item as shown below. Once template folder is created you may delete the sample .txt file.
4. Create a Themes folder inside the Templates folder and add your theme folder along with theme files as shown below. During deployment this folder hierarchy get created inside the 12 hive.
5. Switch to WSP View. It reflects logically how things will get packaged into the WSP solution package.
6. Now we need to add a new feature for the theme. Therefore click new feature in WSP view and select “Web” scope with a Feature Receiver. This will create a feature receiver class for us to override feature event handing.
7. Once feature get created rename the feature name in WSP view. I called mine “iTimeMax Theme”. Note that when you rename features in WSP View it does not get reflected in the solution view. You will need to rename it in the solution view manually.
8. Update your feature receiver class as follows.When this feature get activated we need the theme get applied to the underlying site and when deactivated we need the theme removed from the underlying site.
[SharePointPermission(SecurityAction.LinkDemand, ObjectModel = true)]
public override void FeatureActivated(SPFeatureReceiverProperties properties)
SPWeb web = properties.Feature.Parent as SPWeb;
[SharePointPermission(SecurityAction.LinkDemand, ObjectModel = true)]
public override void FeatureDeactivating(SPFeatureReceiverProperties properties)
SPWeb web = properties.Feature.Parent as SPWeb;
9. Update Feature.xml file and specify where it should find the feature receiver class as shown below. Use the sn.exe util with –Tp switch to generate the public key token for your assembly.
<?xml version="1.0" encoding="utf-8"?>
<Feature Id="32de8e0c-8a20-469b-b40a-edb47710de42" Title="iTimeMaxTheme" Scope="Web"
Version="220.127.116.11" Hidden="FALSE" DefaultResourceFile="core"
ReceiverAssembly="iTimeMax.RI.UpdateTheme, Version=18.104.22.168, Culture=neutral, PublicKeyToken=9f4da00116c38ec5"
10. now we need a second farm level feature for feature stapling. This feature will attach our theme feature to the underlying site definition. Once create rename the feature and element manifest file as required. I call it iTimeMaxFeatureThemeStapler.
11.Update the Element file with FeatureSiteTemplateAssociation element where we specify which feature should be stapled with which site definition. In this case we need our iTimeMax Theme feature with feature id “32de8e0c-8a20-469b-b40a-edb47710de42" staple to Standard team site definition “STS#0”
<?xml version="1.0" encoding="utf-8"?>
<Elements Id="0140e1af-0c03-4297-b7d9-4444d7d04f5d" xmlns="http://schemas.microsoft.com/sharepoint/" >
12. Now our Solution View file structure and WSP view feature organisation should reflect as below.
13. All Done! Now we need to deploy this feature. Right Click the project and Select “Deploy” option to deploy the WSP solution to the SharePoint site. WSeWSS deploy option build, package and deploy the WSP solution.
14. Note that our Farm level feature is activated
15. Now we can go a head and provision a new team site from the standard team site definition.
16. Once site provisioning is complete, our custom theme get applied as shown below. Also if you go the site settings page of the newly created site you will see that our “Web” scope feature is automatically activated.
Feature stapling is particularly useful when you want to add functionality to standard site definitions because editing standard site definition files is not a recommended practice. Also it gives you the ability to reuse your customizations across many site definitions in a loosely coupled manner and reduce administrative overheads.
Recently when I was trying to deploy SharePoint solution with vs2008 and VSeWSS 1.3 I got this cryptic error which made it difficult to identify the cause of the error due to its cryptic nature. After going thought the solution files in detail It worked out that you get this error when you are missing any files in the VS2008 solution which are referenced by the manifest.xml file.
The missing file was referenced by the manifest.xml file inside the VSeWSS “pkg” folder as shown below.
After the placing the missing file in the file system the deployment succeeded as expected.