Tuesday, September 23, 2008

SPPropertyBag

SPWeb object of SharePoint exposes a Field called Properties which is of type SPPropertyBag a sub class of StringDictionary. It allows you to store Key value String Data within a web

Below are some quick points that will help you in using it.

  • As Mentioned Before it is a StringDictionary, which can only store String values.
  • You need to call the Update() method of the SPWeb.Properties.Update() to persist the value.
  • Same applies while you are removing a value from it.
  • Below code gives you a quick start.
  • If you want to manage this through UI. Refer this link. It's a fantastic option you will love.


 

using (SPSite oSite = new
SPSite("http://mysite"))

{


using (SPWeb oWeb = oSite.RootWeb)

{


//Add a Item to Bag

oWeb.Properties.Add("SPPropertyBag","I can Store a StringValue Here");


//Be sure to Call the Update Method on Properties


//If you miss this your value wont get Presisted for the Next Run

oWeb.Properties.Update();


 


// To Reterive the Value


String sMyItem = oWeb.Properties["SPPropertyBag"];


 


//Remove the Value


//Be sure to Call the Update Method on Properties


//If you miss this your value wont get Presisted for the Next Run

oWeb.Properties.Remove("SPPropertyBag");

oWeb.Properties.Update();

             }

         }

    

    

Friday, September 19, 2008

Deploying InfoPath forms using Features – the Right Way

Same version of the Post is avaliable in this Link. Formatting Adjusted.

A week back couple of my friends was asking is there a proper way to deploy the InfoPath forms to the server, Way other than File -> Publish - > SharePoint server with or without forms server. I did a quick search and was not lucky, came to a lackadaisical conclusion that there is no other way. But whenever I deploy workflows with InfoPath form I see a new solution that adds itself to the Solution Store. By this I know for sure there is some other way to deploy InfoPath forms. First thing want I wanted was to get the Solution out of SharePoint and see what's there inside, Again for this there is a tool through which you can do it [I lost the url from where I got it] or hardly 10 lines of code is all what you need.

To my surprise there is indeed a way to do it, well let's see how. What I got out of that solution is a feature, what's in it [Image speaks louder than words, image with comments even louder ;) ]

Feature.xml

#########All usual Stuff ###########

<?xml
version="1.0"
encoding="utf-8"
standalone="yes"?>

<Feature
Id="8ad77502-3602-6e81-c4de-8c7f674c4466"

Title="IPDeplotyment"

Description="$Resources:ipfscore,XsnFeatureDescription;"

Version="1.0.0.0"

Scope="Site"

DefaultResourceFile="ipfscore"

#########Here is the hero who does what we need ###########

ReceiverClass="Microsoft.Office.InfoPath.Server.Administration.XsnFeatureReceiver"

ReceiverAssembly="Microsoft.Office.InfoPath.Server, Version=12.0.0.0, Culture=neutral, PublicKeyToken=71e9bce111e9429c"

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

<ElementManifests>

<ElementManifest
Location="Elements.xml" />

<!-- Name of the IP Form

Note:Actual workflow generated feature has a different name-->

<ElementFile
Location="solution.xsn" />

</ElementManifests>

<Properties>

<!-- The Name of the Feature - Infact after you have deployed the WF to sharepoint there will be a

feature by this name that gets added -->

<Property
Key="FeatureName"
Value="FT-01-8ad77502-3602-6e81-c4de-8c7f674c4466" />

<!-- This is going to the File name with which you have Publised from IP Client / Added to the Workflow.xml

if you are going to deploy the IP forms that are not coupled with the WF you can safely ignore the below tag-->

<Property
Key="OriginalFileName"
Value="IPDeplotyment.xsn" />

</Properties>

<ActivationDependencies>

<!-- Just to make sure that you have Enterprise feature turned on-->

<ActivationDependency
FeatureId="C88C4FF1-DBF5-4649-AD9F-C6C426EBCBF5" />

</ActivationDependencies>

</Feature>

Element.xml

################### You are Right its again another File Provisioning in to SharePoint Lib #####################

<?xml
version="1.0"
encoding="utf-8"
standalone="yes"?>

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

############# Be sure to put the location as FormServerTemplates############

<Module
Name="XSN"
Url="FormServerTemplates"
RootWebOnly="TRUE">

<File
Url="solution.xsn"
Name="IPDeplotyment.xsn"
Type="GhostableInLibrary" />

</Module>

</Elements>

Well here is the stripped out version of the above file

<?xml
version="1.0"
encoding="utf-8"
standalone="yes"?>

<Feature
Id="8ad77502-3602-6e81-c4de-8c7f674c4466"

Title="IPDeplotyment"

Description="$Resources:ipfscore,XsnFeatureDescription;"

Version="1.0.0.0"

Scope="Site"

DefaultResourceFile="ipfscore"

ReceiverClass="Microsoft.Office.InfoPath.Server.Administration.XsnFeatureReceiver"

ReceiverAssembly="Microsoft.Office.InfoPath.Server, Version=12.0.0.0, Culture=neutral, PublicKeyToken=71e9bce111e9429c"

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

<ElementManifests>

<ElementManifest
Location="Elements.xml" />

<ElementFile
Location="IPDeplotyment.xsn" />

</ElementManifests>

<Properties>

<Property
Key="FeatureName"
Value="FirstIPFeatureWayDeployment" />

</Properties>

<ActivationDependencies>

<ActivationDependency
FeatureId="C88C4FF1-DBF5-4649-AD9F-C6C426EBCBF5" />

</ActivationDependencies>

</Feature>

Element.xml

<?xml
version="1.0"
encoding="utf-8"
standalone="yes"?>

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

<Module
Name="XSN"
Url="FormServerTemplates"
RootWebOnly="TRUE">

<File
Url=" IPDeplotyment.xsn"
Name="IPDeplotyment.xsn"
Type="GhostableInLibrary" />

</Module>

</Elements>

Steps in Short:

  • Develop your IP form.
  • Publish it to the network location as how you do to upload to the Central Administration Upload Form Templates.
  • Create one Feature.xml, Element.xml as defined in the article [Sorry how workflow does ;)].
  • Put in the IP form and create a feature out of it.
  • Its all.

Wednesday, September 17, 2008

SharePoint Tools

Below is the List of the SharePoint tools that will boost your productivity. I love them and use them. You too will...

Writing CAML Queries directly in C#.

CAML.NET     http://codeplex.com/camldotnet

Custom STSADM command and Command to Get the Content Type Xml Schema

CUSTOM STSADM http://www.andrewconnell.com/blog/articles/MossStsadmWcmCommands.aspx

SQL like CAML Queries - My Favorite one

CAML Queries in SQL Syntax http://www.ideseg.com/SharePointYetAnotherCAMLQueryTool2.aspx


 


 


 

SharePoint Permission Dependency Chart

This Image speaks for Itself .. If you want more Visit this link.


Adding Server Side code to the Publishing Page Layouts - PageParserPaths

This article is to give a brief introduction for the Functionality of PageParserPaths tag in the Web.Config file of SharePoint. (It serves as a Reference for me In future and for someone out there looking for a similar implementation).

All the Layout pages in the SharePoint 2007 are derived from the class

Microsoft.SharePoint.Publishing.PublishingLayoutPage .

This works very well for most of the cases and customization. But there will be very chance that for some reason you want the actual page instance to have a completely different class. Might be a case where you are using a third part tool or a component. In this case if you try to change the base class or put in some custom server side code in to the page layout file, SharePoint will complain you with a parser error.

This Article describes the approach that will help you to put in the code for the layout pages. It works like charm.

On additions to the above article is that in case if you are concerned about allowing all the pages having the server code as defined by below tag

<PageParserPath VirtualPath="/_layouts/masterpage/*" CompilationMode="Auto" AllowServerSideScript="true"

IncludeSubFolders="true"/>

You can make a particular page to have server side code as below

<PageParserPath VirtualPath="/_layouts/masterpage/yourpage.aspx" CompilationMode="Auto" AllowServerSideScript="true"

IncludeSubFolders="true"/>

While configuring a single page, make sure that you remove the attribute IncludeSubFolders="true". If you leave this tag as it is, all you are going to get is a plain HTTP 500 error code which is hard to debug. Validation that SharePoint makes here is IncludeSubFolders="true" can be present only if the attribute VirtualPath ends with /*.