Home - Level Orange

Level Orange

A blog about CAS issues, custom authentication providers for SharePoint and other random thoughts - brought to you by Joseph Krupinski

12/14/2007

Encode URLs and Query Strings

There are many times that you will want to pass query parameters in a query string. The best practice approach to do this is to make sure that you URL Encode them so that any special characters are safely translated. You can decode them on the receiving side.

Encoding Example:

string PageWithQueryString = @"Bad & {Worse}";

PageWithQueryString = @"NewPage.aspx?ID=" + Server.UrlEncode(PageWithQueryString);

Response.Redirect(PageWithQueryString, false);

Decoding Example:

string QryString = Server.UrlDecode(Request.QueryString["ID"].ToString());

Table of Characters:

ASCII Value	URL-encode	ASCII Value	URL-encode	ASCII Value	URL-encode
æ	%00	0	%30	`	%60
	%01	1	%31	a	%61
	%02	2	%32	b	%62
	%03	3	%33	c	%63
	%04	4	%34	d	%64
	%05	5	%35	e	%65
	%06	6	%36	f	%66
	%07	7	%37	g	%67
backspace	%08	8	%38	h	%68
tab	%09	9	%39	i	%69
linefeed	%0a	:	%3a	j	%6a
	%0b	;	%3b	k	%6b
	%0c	<	%3c	l	%6c
c return	%0d	=	%3d	m	%6d
	%0e	>	%3e	n	%6e
	%0f	?	%3f	o	%6f
	%10	@	%40	p	%70
	%11	A	%41	q	%71
	%12	B	%42	r	%72
	%13	C	%43	s	%73
	%14	D	%44	t	%74
	%15	E	%45	u	%75
	%16	F	%46	v	%76
	%17	G	%47	w	%77
	%18	H	%48	x	%78
	%19	I	%49	y	%79
	%1a	J	%4a	z	%7a
	%1b	K	%4b	{	%7b
	%1c	L	%4c	\|	%7c
	%1d	M	%4d	}	%7d
	%1e	N	%4e	~	%7e
	%1f	O	%4f		%7f
space	%20	P	%50	€	%80
!	%21	Q	%51		%81
"	%22	R	%52	‚	%82
#	%23	S	%53	ƒ	%83
$	%24	T	%54	"	%84
%	%25	U	%55	…	%85
&	%26	V	%56	†	%86
'	%27	W	%57	‡	%87
(	%28	X	%58	ˆ	%88
)	%29	Y	%59	‰	%89
*	%2a	Z	%5a	Š	%8a
+	%2b	[	%5b	‹	%8b
,	%2c	\	%5c	Œ	%8c
-	%2d	]	%5d		%8d
.	%2e	^	%5e	Ž	%8e
/	%2f	_	%5f		%8f

Posted at 12:53 PM by NORTHAMERICA\v-joekr | Category: Misc Tech | Permalink | Email this Post | Comments (0)

Intro to Features

This will not be an extensive look at features but I figured it was about time to at least write a feature and explain a little about them.

What is a feature?

Wow, I am so glad you asked that. A feature in MOSS is simply a set of files, be it code, XML, web pages or CAML that will be "installed" into the SharePoint system. This being said, what you can do is actually add or "staple" this feature to a site definition so that when a new site is created, the feature will be activated as well. What you can put in a feature is really whatever you can dream up. You can add web parts, master pages, lists, fill lists with data, event receivers attached to the lists, etc. Hopefully, you are starting to understand the real scope of this here. As you can see, this is the recommended way of deploying your SharePoint Changes through the normal SDLC.

A feature can be installed on many levels or "scopes".

Farm
- A farm feature is always activated and would be things like links to _layouts pages
Web Application
- These would be items like Admin Links and global assemblies
Site Collection
- These could be items like Web Parts, Workflows and Content Types
Site
- These could be things like item receivers and list instances.

There are three types of file groups that are involved in a feature

The first and most obvious file will be the Feature.xml file. This file will be in a subdirectory (usually your feature name) under the 12 hive (\program files\common files\microsoft shared\web server extensions\12\templates\features. We are going to call our feature ItemReceivers in our example.
The second is the Element Manifest XML file. This file is referenced by the Feature.xml file and houses pointers to all the files that will be provisioned as well as any setup for those files including CAML code.
The third are the files referenced by the Element Manifest file. These files would include aspx pages, dll's, and anything else you would likely deploy to SharePoint

We are now going to write an example feature that will attach an Item Event Receiver to a list.

Feature

The first thing that you obviously have to do is decide on what you are going to build and add as a feature. We are going to deploy the item receiver that we built here as a feature.

Feature File

In building the feature file you will first need to generate a unique GUID for the feature itself. You can find instructions for this here. After this you will have to point to write the base XML for the feature file. It will look something like this:

</ElementManifests>

</Feature>

Manifest File

Your manifest file will act exactly as it sounds by outlining all files and placement of these files and will look something like this:

<Name>Field Added</Name>

<Type>FieldAdded</Type>

<Assembly>MSIT.ItemReceivers, Version=0.0.0.0, Culture=neutral, PublicKeyToken=6546c52e1a7f48a0</Assembly>

<Class>MSIT.ItemReceivers.UpdateContactsEvent</Class>

</Receiver>

<Name>Field Updated</Name>

<Type>FieldUpdated</Type>

<Assembly>MSIT.ItemReceivers, Version=0.0.0.0, Culture=neutral, PublicKeyToken=6546c52e1a7f48a0</Assembly>

<Class>MSIT.ItemReceivers.UpdateContactsEvent</Class>

</Receiver>

</Receivers>

</Elements>

Please note that the Assembly and Class information were retrieved using the mechanism described here.

Important: Please note that there are a couple limitations to using the "Receivers" approach. You cannot associate this to a particular list instance only a type of list. You will probably want to make your own type anyway; however, this is a limitation. Also, you can only scope this at a site level. Both of these limitations can be overcome by using solution packages which will be discussed in a later post.

Manually Deploying your Feature

The first thing you will have to do is make sure that the files are copied to the correct place. You will open the command prompt and navigate to your bin folder for SharePoint.

xcopy "c:\[PathToFeatureFiles]" "c:\program files\common files\microsoft shared\web server extensions\12\templates\features" /s /y

Please GAC the assembly of your receiver by following the instructions here.

You then will need to install the feature to your SharePoint Server

stsadm -o installfeature –filename Receivers\feature.xml

Finally, you will have to activate your feature for the site

stsadm -o activatefeature -filename Receivers\feature.xml -url http://[YourSite]

Deploying your Feature as a Solution Package

This is a topic for a future post and I will modify this link to have the link at that time.

Posted at 12:46 PM by NORTHAMERICA\v-joekr | Category: MOSS | Permalink | Email this Post | Comments (0)

12/11/2007

SharePoint Blog Navigator Web Part

Intro

Ok, ladies and gents, I just couldn't take it any longer! The out of the box navigation for blogs is less than ideal and although I will be soon investigating different content query web parts to accomplish the same thing, I went ahead a build a new one. For the finished product and POC please visit http://www.codeintegrators.com/blog to see it in action. Essentially, I wanted a grouping of blog articles in some sort of tree view as a web part. Simple right? The answer to this is actually yes. What I will plan to do here is simply write a quick code base and deploy to my site. At that point, I can just add my web part and ta-da, workie workie.

Implementation

Create a CAML query based on the "Posts" list that just orders the posts by publish date. This will look something like:

using (SPWeb spWeb = SPContext.Current.Web)

{

string DocumentLib = "Posts";

string sUrl = spWeb.Url;

string PostDate = string.Empty;

SPList list = spWeb.Lists[DocumentLib];// here DocumentLib is name of the name of documentlibrary we are passing

SPQuery docQuery = new SPQuery();

docQuery.ViewFields = @"<FieldRef Name=""LinkTitle""/>";

docQuery.ViewFields += @"<FieldRef Name=""PublishedDate""/>";

string CamlQ =

@"<OrderBy>

</OrderBy>";

docQuery.Query = CamlQ;

Loop through these posts creating a string representation of XML that looks something like:

sBlogs = @"<?xml version=""1.0"" encoding=""utf-8"" ?>";

sBlogs += @"<BlogPosts>";

SPListItemCollection docList = list.GetItems(docQuery);

foreach (SPListItem item in docList)

{

DateTime PublishedDate = DateTime.Parse(item["PublishedDate"].ToString());

if (PostDate != PublishedDate.ToString("MMMM yyyy"))

{

//Make sure not first time through loop

if (PostDate != string.Empty)

{

sBlogs += @"</PostMonth>";

}

PostDate = PublishedDate.ToString("MMMM yyyy");

sBlogs += @"<PostMonth name=""" + PostDate + @""">";

}

sBlogs += @"<PostName name=""" + item["LinkTitle"].ToString() + @""" url=""" + sUrl + @"/Lists/Posts/Post.aspx?ID=" + item.ID.ToString() + @"""/>";

}

sBlogs += @"</PostMonth>";

sBlogs += @"</BlogPosts>";

}

return sBlogs;

}

Create an XML Data Source and attach your bindings accordingly

XmlDataSource xBlogPosts = new XmlDataSource();

xBlogPosts.EnableCaching = false;

XmlDocument xXMLDoc = new XmlDocument();

TreeNodeBinding tnbTop = new TreeNodeBinding();

TreeNodeBinding tnbMonth = new TreeNodeBinding();

TreeNodeBinding tnbName = new TreeNodeBinding();

string sXMLDoc = string.Empty;

try

{

if (!Page.IsPostBack)

{

//Create XML

sXMLDoc = GetBlogPosts();

//Load XML DataSource

xXMLDoc.LoadXml(sXMLDoc);

xBlogPosts.Data = xXMLDoc.InnerXml;

You will then set your XPath to narrow down your tree

xBlogPosts.XPath = "BlogPosts/PostMonth";

Create a Treeview and set the XML Datasource be the binding

//Create TreeNode Bindings

tnbTop.DataMember = "BlogPosts";

tnbTop.Text = "Blog Posts";

tnbMonth.DataMember = "PostMonth";

tnbMonth.TextField = "name";

tnbName.DataMember = "PostName";

tnbName.TextField = "name";

tnbName.NavigateUrlField = "url";

//Associate TreeView Bindings

tv.DataBindings.Add(tnbTop);

tv.DataBindings.Add(tnbMonth);

tv.DataBindings.Add(tnbName);

//Bind

tv.DataBind();

tv.CollapseAll();

Add the tree view through the RenderChildren method as explained in an earlier post here.

this.Controls.Add(tv);

Make sure you dispose your objects that you explicitly instantiate

xBlogPosts.Dispose();

xBlogPosts = null;

xXMLDoc = null;

tnbTop = null;

tnbMonth = null;

tnbName = null;

tv.Dispose();

tv = null;

Build and deploy your finished webpart
Add the webpart to the page(s) in question

Finishing touches

For full sample of the code, simply email me or send comment. I have uploaded the cs file, however, anonymous access is not yet enabled. I was tired of writing the code in the blog all the time, so figured I would try a different approach this time.

The end product looks something like:

Pretty cool huh?

Posted at 1:43 PM by NORTHAMERICA\v-joekr | Category: MOSS | Permalink | Email this Post | Comments (0)

Attaching a Receiver using Code

Intro

So I have built a new receiver (You can review the article found here). Now what?

Well, the answer is that you have to attach it somehow. In this post, I plan to demonstrate how to do this via code. In a later approach I will be reviewing feature based development.

Implementation

The first thing we are going to do is create a new project in visual studio. In this case we will make it a console application just for a POC:

We then of course are going to add the Microsoft.SharePoint.dll reference. You can find this in my previous article located here.

Finally we are going to write the following code:

using System;

using System.Collections.Generic;

using System.Text;

using Microsoft.SharePoint;

namespace MSIT.Samples

{

class Program

{

static void Main(string[] args)

{

SPSite spSite = null;

SPWeb spWeb = null;

SPList spList;

try

{

spSite = new SPSite("http://r2-basemachine:1111");

spWeb = spSite.OpenWeb();

spList = spWeb.Lists["Contacts"];

//spList = spWeb.Lists["ContactType"];

string asmName = "MSIT.ItemReceivers, Version=0.0.0.0, Culture=neutral, PublicKeyToken=6546c52e1a7f48a0";

string className = "MSIT.ItemReceivers.UpdateContactsEvent";

spList.EventReceivers.Add(SPEventReceiverType.ItemAdded, asmName, className);

spList.EventReceivers.Add(SPEventReceiverType.ItemUpdated, asmName, className);

spList.Update();

}

catch

{}

finally

{

spList = null;

spWeb.Dispose();

spSite.Dispose();

spWeb = null;

spSite = null;

}

You simply run this code and run IISReset and you are golden (ready for test)

Posted at 11:06 AM by NORTHAMERICA\v-joekr | Category: MOSS | Permalink | Email this Post | Comments (0)

12/10/2007

Building MOSS Item Event Handlers

Intro

So you have a list in MOSS, now what? I want to have a unique index field or I want to update contents of the list with other lists, or I want to start a process, etc. To extend a list, one of the many things you can do is to build an event handler for that list. Similar to other .NET objects, a SharePoint List has Event Handlers that can be tied to certain actions triggered by usage of that object. It is important to know that there are two kinds of execution patterns depending on the event that is coded for.

Synchronous Event Handlers:

The first is synchronous event handlers. These would be where you could stop the execution of the thread before completion. If you take a look at the Item Adding event for instance, you could check to see if you are violating a specific business constraint and stop the execution or add process if the validation fails. Pretty much a rule of thumb on these is that they all end in "ing" so Item Adding, Item Updating, Item Deleting, etc. Think of the power of this if I get to write any .NET code on this particular delegate.

Asynchronous Event Handlers:

The second would be asynchronous event handlers. These would be when a new thread would be started to run this code. If you take a look at Item Updated, we could possibly retrieve data from another list and cross populate into your list based on a lookup field or any number of items. This is the exact sample that we will be addressing in this article.

Writing the code:

The first thing we will do is open visual studio and create a new project. It can be a simple class library:

We are then going to add the Microsoft.SharePoint.dll as a reference:

Now we are ready to write our code. Remember for this that we are going to simply take the contents of one list and based upon a lookup value, populate based on contents of another list.

using System;

using System.Collections.Generic;

using System.Text;

using Microsoft.SharePoint;

namespace MSIT.ItemReceivers

{

class UpdateContactsEvent : SPItemEventReceiver

{

public override void ItemUpdated(SPItemEventProperties properties)

{

UpdateContents(properties);

}

public override void ItemAdded(SPItemEventProperties properties)

{

UpdateContents(properties);

}

void UpdateContents(SPItemEventProperties properties)

{

using (SPWeb spWeb = properties.OpenWeb())

{

//Get Lookup List

SPList ContactType = spWeb.Lists["ContactType"];

//Get List Item to be updated

SPListItem Contact = properties.ListItem;

string sContactType = string.Empty;

sContactType = Contact["ContactType"].ToString();

//Get ListItem of Lookup List

SPListItem ContactTypeItem = null;

foreach (SPListItem ContactTypeLoop in ContactType.Items)

{

//We are doing a contains because this is an array lookup but we could explicitly do something like:

//If (ContactTypeLoop["ContactType"].ToString() == Contact["ContactType"].ToString().Split(';')[1].Replace('#','')

if (sContactType.Contains(ContactTypeLoop["ContactType"].ToString()))

{

ContactTypeItem = ContactTypeLoop;

break;

}

if (ContactTypeItem == null)

{

throw new Exception();

}

//Update Original ListItem

Contact["ExtraData"] = ContactTypeItem["SendChristmasCards"].ToString();

Contact.Update();

}

Build and GAC the Receiver

What you are going to have to do now is GAC the assembly. Instructions can be found in my blog posting here.

Associate Receiver to List

Finally, the moment of truth, let's attach the code to the list that we want. There are two main ways we can accomplish.

Code Approach

The instructions for Code Approach can be found here.

Feature Approach (Recommended)

The instructions for Feature Approach can be found here.

Posted at 2:27 PM by NORTHAMERICA\v-joekr | Category: MOSS | Permalink | Email this Post | Comments (0)

Finding Assembly Information

Once again, in an attempt to segment information to prevent information overload, this is a simple one. In MOSS development, you will many times have to reference assemblies by class name and assembly name along with the public key token. To accomplish this I use a tool called .NET reflector which can be located here.

If you drag your assembly on the user interface of the tool, you can click on it and see the assembly information as such:

If you drill down to the actual class, you can see the class information as such:

Promised it would be short but invaluable if this is the first time you've seen the tool.

Posted at 2:24 PM by NORTHAMERICA\v-joekr | Category: Misc Tech | Permalink | Email this Post | Comments (0)

GAC’ing an assembly

Probably not a blog-able subject but wanted something to link to so here goes.

First thing to do here is strong-name your assembly. Simply go to properties on the project and signing section.
Build your assembly by pressing F7 or however you wish
From here you can use gacutil, add gacutil to a post-build event or simply navigate to dll and drop it into "c:\windows\assembly"

Posted at 12:50 PM by NORTHAMERICA\v-joekr | Category: Misc Tech | Permalink | Email this Post | Comments (0)

Find GUID of List

Ok, I have decided to compartmentalize some of these into just a couple searchable topics that I can link to in other things so this is simply going to find out the GUID of an existing list. There are several ways we can do this including simply writing a quick code snippet. Technically, we should even be able to write a quick Console App that spits out the GUID based on a URL. However, we can simply look at the URL after going to the list we want.

See (If you look at the URL you will see a URLEncoded GUID at the List=: )

Posted at 7:17 AM by NORTHAMERICA\v-joekr | Category: MOSS | Permalink | Email this Post | Comments (0)

Generating a new GUID

Inevitably in MOSS if you are doing custom development there will come a point where you will have to generate new GUIDs for your features, lists, fields and whatever else. There is a quick and easy way of doing this from Visual Studio.

Simply open Visual Studio and go to Tools à Create GUID

Choose Registry Format and then Copy. Done and Done. Know that certain GUIDs in MOSS will complain if you have curly braces {} and some will not.

If you are more of a command-line person you can get to the same screen by typing:

guidgen

in the Visual Studio Command Window

Posted at 7:02 AM by NORTHAMERICA\v-joekr | Category: Misc Tech | Permalink | Email this Post | Comments (0)

11/29/2007

Implementing a New Authorization Provider

Membership Provider Setup

Tools Needed and other Assumptions

The following is assuming you have a working Central Administration Site and Website you wish to apply the custom membership provider to. You will also need access to the latest of the following files:

Security.dll (Custom Membership and Role Provider)

In implementing the custom membership provider we are also assuming that you will have access to the custom provider database. Please note anything bold and red is configurable.

We also must note that these instructions apply to the changes that need to be made to the MOSS Server and will need to be done on each WFE that you wish to host the custom membership on.

Once you have completed the following directions to configure the custom provider for your site, the Sharepoint Designer application will not be able to connect to it. For this reason, I recommend you extend your web application to the "intranet" zone with AD credentials and let the designers know the URL to connect to for Sharepoint Designer.

Please keep in mind that without the SP1 of the .NET 2.0 Framework, the below will throw http Cookie exceptions in the Event viewer. If you cannot implement the Service Pack, please change CacheRolesInCookie to equal False.

GAC

The first thing we will do is GAC the following files:

Security.dll

Machine.config

We are now going to modify the machine.config located at C:\WINDOWS\Microsoft.NET\Framework\v2.0.50727\CONFIG\machine.config. We will make the following entries:

</providers>

</membership>

</providers>

</profile>

</providers>

</roleManager>

These entries will take the place of the existing <Membership>, <Profile>, and <Role Manager> tags.

Central Administration Web.config

Add the Membership and Role Providers directly under <System.Web>

<add connectionStringName="LocalSqlServer"

passwordAttemptWindow="10"

enablePasswordRetrieval="false"

enablePasswordReset="true"

requiresQuestionAndAnswer="true"

applicationName="sqlmembershipproviderName"

requiresUniqueEmail="false"

passwordFormat="Hashed"

description="Stores and retrieves membership data from the Microsoft SQL Server database"

name="sqlmembershipproviderName"

type="Security.sqlmembershipproviderName, Security, Version=1.0.0.0, Culture=neutral, PublicKeyToken=d003b67fe3e7980d" />

</providers>

</membership>

<roleManager defaultProvider="AspNetWindowsTokenRoleProvider"

enabled="true"

cacheRolesInCookie="true"

cookieName=".ASPROLES"

cookieTimeout="30"

cookiePath="/"

cookieRequireSSL="false"

cookieSlidingExpiration="true"

cookieProtection="All" >

</providers>

</roleManager>

Replace the <PeoplePickerWildcards/> with the following keys

</PeoplePickerWildcards>

Add the following directly under </appsettings>

<add name="SQLDB"

connectionString="Data Source=SQLServer;Initial Catalog=WSS_Membership;User ID=sa; Password=password"

providerName="System.Data.SqlClient" />

</connectionStrings>

Web Application Web.config

Add the Membership and Role Providers directly under <System.Web>

</providers>

</membership>

</providers>

</roleManager>

Replace the <PeoplePickerWildcards/> with the following keys

</PeoplePickerWildcards>

Add the following directly under </appsettings>

</connectionStrings>

Set Authentication Provider for Web Application

Log in to your central administration site and go to Application Management à Authentication Providers. This can be accessed at http://ServerName/_admin/authenticationproviders.aspx.

Make sure that you are in the right web application that you wish to implement the provider for.

Click on the default zone which should be the only one listed at this moment.

Choose forms authentication type and type in [membershipproviderName],[sqlroleproviderName] in the appropriate boxes. Choose Save.

Set Policy Administrator for your web application

Since you have now changed the authentication for your web application, no one can actually log in quite yet. What you want to do is set the administrator for the account. I do not recommend setting more than one or two at this level.

Log in to your central administration site and go to Application Management à Policy for Web Application. This can be accessed at http://ServerName/_admin/policy.aspx.

Click on "Add Users" and choose Default zone

Choose Next

Use the People Picker to set your administrator

Choose Full Control and click on Finish.

Posted at 8:11 AM by NORTHAMERICA\v-joekr | Category: MOSS | Permalink | Email this Post | Comments (0)

RSS Feed

1 - 10

Categories

12/14/2007

What is a feature?

A feature can be installed on many levels or "scopes".

There are three types of file groups that are involved in a feature

Feature

Feature File

Manifest File

Manually Deploying your Feature

Deploying your Feature as a Solution Package

12/11/2007

Intro

Implementation

Finishing touches

Intro

Implementation

12/10/2007

Intro

Synchronous Event Handlers:

Asynchronous Event Handlers:

Writing the code:

Build and GAC the Receiver

Associate Receiver to List

Code Approach

Feature Approach (Recommended)

11/29/2007

Membership Provider Setup

Tools Needed and other Assumptions

GAC

Machine.config

Central Administration Web.config

Web Application Web.config

Set Authentication Provider for Web Application

Set Policy Administrator for your web application

‭(Hidden)‬ Admin Links