Skip to main content

Elumenotion Blog

Go Search

 
Elumenotion > Elumenotion Blog
Posts and musings about SharePoint, eLumenotion, and random whatnot.
SharePoint Developer Productivity Tip #2 – Easy Site Column Features

Almost every SharePoint project involves custom site columns. You can create a site column via the browser, but unless the column is trivial and only used in a single site, you should always deploy site columns using features. The reason for this is that when you create a site column via the browser, SharePoint always creates a new globally unique identifier. If you create a site column with the browser on one site, and then repeat the work on another site, you will have two unique site columns because even though the site columns on both sites are otherwise identical, they have different ID's.

The different IDs are a problem if you ever need to aggregate the data across the site collections, if you want to use the column in search scopes, and if you are using records center. Even if you have none of these needs, you certainly don't want to have to create the same site column by hand over and over again on every site where it is needed. And, if your solution requires any custom site columns, it probably requires many of them.

The features schema for site columns, or Fields, isn't trivial. You can see it here: http://msdn.microsoft.com/en-us/library/ms437580.aspx . I could create my <Field> definitions by hand, but I am much too lazy for that! The browser makes it so easy! Fields in the SharePoint object model are handled by the SPField class. The SPField class has a property, SchemaXml, which contains the XML definition for the field. This XML is exactly the same as the XML required in a feature's element manifest to define the field.

The fastest and easiest way to make a site column feature is to:

  1. Create the site column on a development site in the browser.
  2. Use a tool to copy the resulting SPField instance's XmlSchema property value.
  3. Paste it into your element manifest.

It doesn't get much easier than copy and paste. There are a number of tools out there that you can use to do this, but the one I use is SharePoint Manager 2007 by Carsten Keutmann. Carsten is also the creator of WSPBuilder and I am a big fan of his work. I use the free SharePoint Manager 2007 for many different tasks, some of which I will write about in subsequent SharePoint Developer Productivity Tips!

To get the SchemaXml, simply navigate to the field in SharePoint Manager 2007, select the Schema Xml tab, and copy the text.

Here is the copied schema from the core About Me site column:

<Field ID="{e241f186-9b94-415c-9f66-255ce7f86235}"

Name="Notes"

SourceID="http://schemas.microsoft.com/sharepoint/v3"

StaticName="Notes"

Group="_Hidden"

DisplayName="About Me"

ReadOnly="FALSE"

Type="Note"

Sortable="FALSE"

RichText="TRUE"

RichTextMode="FullHtml"

FromBaseType="TRUE" />

SharePoint Developer Productivity Tip #1 – Visual Studio Project Templates

At the second meeting of the new Atlanta SharePoint User Group, Dan Attis spoke on SharePoint development environments. His talk reminded me that I have meant for some time now to post a series about specific techniques that I use to make life as a SharePoint developer more productive. This post is the first in a series and it covers the subject of project templates.

I use a project template that allows creation of Web Forms and Controls with the visual designer, is configured for WSPBuilder and code signing, and has some standard assembly references. If you aren't interested in the details of how to make your own, you can just download mine from here (http://www.elumenotion.com/Downloads/WSPTemplate.zip) and place it into your Documents\Visual Studio 2008\Templates\ProjectTemplates folder or you can keep reading!

A Visual Studio project template defines the base configuration of a new project. If you've ever used VS, you have used a project template. When I am starting from scratch, I usually use the C# Class Library project template because it makes the fewest assumptions about what I am doing and therefore imposes the fewest restrictions. One problem with this approach is that the Class Library template lacks the item templates for ASP.NET. Among these are the templates for Web Forms and User Controls. I like the productivity tools provided by these item templates, especially the visual designers. Fortunately, it is easy to add the Web Form and User Control item templates to a Class Library!

In Solution Explorer, right-click the project node and choose Unload Project to expose the project file for editing and then edit the file.

The file opens in the editor. Insert the <ProjectTypeGuids>{349c5851-65df-11da-9384-00065b846f21};{fae04ec0-301f-11d3-bf4b-00c04f79efbc}</ProjectTypeGuids> element beneath <ProjectGuids> element and save the file.

Right-click the project in Solution Explorer and select Reload Project. Now when you add a new item to the project you have the option to include any of the standard ASP.NET Web items.

I use the WSPBuilder tool to create web solution packages that I can install and deploy on SharePoint farms. WSPBuilder is simple to use, but it requires that the project files are in folders within the project that match the deployment target's structure (the 12 hive). The next step is to create the folders shown below.

When you run WSPBuilder it creates a solution manifest based on the files that are actually in the project. So, if I don't include any files in a particular folder, the presence of the folder in the solution won't affect the package. So, I usually just start out with the set of folders I am most likely to use ahead of time.

Most projects require a few feature receivers or other code that has to deploy to the Global Assembly Cache. This requires that the assembly has a strong name, which in turn requires a strong-name key. The next step is to configure code signing. You can read more about that process here: http://msdn.microsoft.com/en-us/library/ms247123.aspx.

WSPBuilder will also specify in the solution manifest that the assembly should deploy to the GAC if it finds it in a GAC folder beneath the project root. To enable this create the folder in the project and set the output path. To learn how to do this, see: http://msdn.microsoft.com/en-us/library/kb4wyys2.aspx. At this point, the project structure looks like the following:

Finally, before I can write any code, I need to add references to the SharePoint and various System.Web assemblies.

That's a lot of work to go through every time I want to create a new solution. In a team environment over the course of a year you could waste days doing this by hand. Worse, different members of the team might do things differently resulting in confusion for all. If you save the result as a project template you can avoid ever having to do these steps again. You can also share the template with your teammates. To export the project as a template, select File|Export Template and complete the wizard. The result is a ZIP file. If you give it to a teammate and they put it into their Documents\Visual Studio 2008\Templates\ProjectTemplates folder, they will have it as an option when they create a new project.

You can download the result here: http://www.elumenotion.com/Downloads/WSPTemplate.zip

SharePoint Saturday, April 18, 2009

If you are interested in SharePoint, you should come. It's an all day event at Microsoft with a boatload of great speakers including yours truly!

Read more and sign-up here: http://www.sharepointsaturday.org/atlanta/default.aspx

Registration for the 5th Annual Atlanta Code Camp is Now Open

The 5th annual Atlanta Code Camp is Saturday, March 14, 2009.

As one of the Code Camp Counselors I can say with confidence that this is going to be a great event! I'm very excited about the facility and the awesome speakers.

You can sign up here: http://atlantacodecamp.com/

But you better hurry. We opened up registration one hour ago and 62 of the 300 slots are already taken!

Why Your Vendor Screwed Up Your SharePoint Project

There have been some excellent posts in various blogs over the last couple of months about reasons why SharePoint projects fail. Jeremy Thake has a thought provoking post titled The SharePoint Implementation Market needs to grow up!, Kristian Kalsing has one titled Do we need SharePoint functional consultants?, and Paul Culmsee has numerous posts on the subject over at Clever Workarounds. I even have an old one in my blog, How to Sabotage Your Projects.

I think the most common reason SharePoint projects fail is simple: the people hired to do the work were not qualified. In this post I will explain why, and hopefully help you make better buying decisions.

Before I started Elumenotion two years ago, I spent years working for a very good Microsoft Gold Partner, one of the largest in the country. I worked in several roles over the years including Senior Consultant, Practice Leader, General Manager, and Sales Executive. I've had to hire the right people, build and maintain different practice areas, and manage utilization.

The Microsoft partner model is basically the same today as it was ten years ago. Microsoft has multiple partner levels with different benefits. To qualify as a partner, you earn competencies in different areas of specialization and earn points based on different criteria including the number of certified professionals you have on staff. Ten years ago, there were a handful of competencies. Today there are sixteen separate competencies. Some are narrow like the SOA and Business Process (BizTalk), some are very broad like Custom Development Solutions, and some fall in the middle, like Information Worker Solutions.

If you are hire a certified partner to implement SharePoint, chances are they hold either the Custom Development Solutions or Information Worker Solutions competencies. Let's take a look at the description of Information Worker Solutions.

Let that sink in for a minute. Let's count the Microsoft products that a vendor with this competency should be able to implement.

1.    SQL Server
2.    Performance Point
3.    Office 2007
4.    InfoPath
5.    SharePoint Designer
6.    Visual Studio
7.    Project Server
8.    Project
9.    Windows SharePoint Services
10.    Microsoft Office SharePoint Server
11.    FAST Search
12.    Windows Server

You can explode many of these into many specializations, SQL Server is huge, Office consists of half a dozen core applications and several minor applications… you get the idea.

Of course Microsoft Office SharePoint Server has a long list of complicated features: Web Content Management, Office Business Applications, Workflow, Business Data Catalog, Search, and many, many more.

These are just the technologies. As Kristian Kalsing points out each addresses a wide range of functional areas.

Now, imagine you are the manager of a Microsoft Gold Partner that does custom application development. Your office has 40 consultants and $10 million in sales per year. At that size, you are a respectable player in the city where you live. Custom application development covers a big list of technologies too. Some of your people are best at Windows Forms, some do middle-tier and server-side work, you probably have to have a good DBA or two, and some are cracker jack web developers who do ASP.NET, CSS, AJAX, etc.

Now add SharePoint to the mix and divide the number of people by the number of technologies. How many of those 40 people are really good at more than 2-3 of the items on the list?

Every one of those 40 people collect salaries. You have to pay them even when they are on the bench. Your sales people are paid on commission, and when they sell an engagement they expect you to staff it so they can get paid.

Now imagine that you are the customer. What makes you think that on the day you sign the contract with that vendor that the 2-3 people they have on staff who really understand the technology you need are actually available? They might be, but the odds aren't good. Did you check the vendor's references? How do you know that you will get any of the people responsible for that awesome win the reference tells you about?

If the manager at the vendor wants to keep his or her job, they will do the best they can with the people they have available.

Ten years ago we lived in a simpler world. It was possible, and fairly common for the best Microsoft professionals to implement a wide swath of the Microsoft platform. The partner model that Microsoft has today was built for those days, but those days are over. You can't give a crackerjack .NET developer a book and give them two weeks to ramp up on MOSS. Many have tried and many have failed. The same is true of SQL Server Analysis Services, BizTalk and of much of the rest of the Microsoft stack.

The Microsoft partner ecosystem is changing. The incumbents know that they can't afford to keep all of these skills in house. A model that resembles general contractors and subcontractors is emerging. Some of Elumenotion's best customers are other Microsoft Partners that recognize this fact. We think of ourselves as plumbers. Our larger consulting partners are builders. They have their own plumbers, but sometimes their people are busy and they call us. We have lots of other customers that are normal businesses. We only do SharePoint work for them even though we obviously could do more generalized ASP.NET work.

Elumenotion is not the least bit revolutionary in this regard. There are plenty of small vendors who only do SharePoint, just like there are many small specialty vendors in every other product offering from Microsoft.

Does this mean you shouldn't use a medium sized or large consulting firm for SharePoint? Of course not! What it does mean is that you should focus on the individual consultants they want to assign to your projects. You should subject each of them to the same scrutiny that you would a full time hire. If you don't have the skills in-house to make the decision, hire a plumber.