This week I’ve been scouring the web to figure out how to display a lookup field on a page layout as text, without the automatic link to the lookup item.

First, you have to add the field you want as an additional field on the lookup. Click on into the list settings, then the lookup field settings, and add the field you want to display sans link. (for me it was the same field I was looking up: the Title)

[image: blog1.jpg]

To make sure this works like you want it to, check the list settings. You should now see a new column in your list titled something like “LookupFieldName:Title”.

Next, you need to do a little URL encode magic to pull it into your page layout. I would have never figured this out had it not been for Emerson Bruce’s helpful post on a feature that doesn’t seem to be documented anywhere. So you just add this bit to your page layout.

Notice the “x003a” in the Property attribute? That’s html speak for a colon. So with that, you should have the title text without the link.

A couple weeks ago I needed to create a custom site definition to be reused by international offices at my company. After doing a bit of research, and consulting with the SharePoint admin guru J.D. Wade, I decided to create a minimal site definition and do all of the heavy lifting through custom features that would be stapled to the site definition.

When I go, I go all out. So when I decided to go minimal on the site definition, it was going to be all or nothing. In general, this wasn't a problem. I only needed to create a few lists and apply some custom content types to them. The trick came when I found I needed to add web parts to the default page, and also to a couple of sub pages. You can do this without too much trouble in the onet.xml of a site definition. But like I said, I'm no cheater. After a lot of searching, I found these two posts which gave me the basics.

However, this solution limited me to only adding web parts that have .webpart or .dwp definitions. I also needed to add a few list view web parts, so I added this functionality to the code.

Enough of me rambling on, I'm sure you're just dying to see how this beauty works.  Well...by all means, allow me.

Read the rest of this post »

Feature deploying files into SharePoint such as web parts or master pages is something that most developers and admins of any caliber should be familiar with.  Also called "provisioning", it's the bread and butter of customizing SharePoint, if you will.  Part of the basics. However, there are some serious issues with how SharePoint accomplishes this out of the box. 

The first issue I found a year or so ago.  I was deploying some web parts through a feature, and went to deactivate the feature.  After deactivation, much to my dismay, I found the web parts still deployed in the web part gallery.  Not a huge deal, but an annoyance to be sure.  So I rolled up my sleeves, dove into the SharePoint object model, and developed a custom event receiver that removed the web parts previously deployed when deactivated.

I found the second issue I found a few weeks ago.  I was working on deploying a custom master page and I started hitting problems.  Aside from hitting the first problem again, I found that overwriting a master page (or page layout) was impossible using the out of the box SharePoint file provisioning.  At first I was trying to override default.master, but then realized the errors of my ways (may the SharePoint gods forgive me). Never overwrite a default master page.  Just copy it, rename it, and build your new one from there.  You will save yourself future headaches and pain.  But I digress, this did get me thinking of the problems with upgrading the master page in the future.  If I can't overwrite a page that's already deployed, if I make a change to the master page and upgrade my solution, that means the upgraded master page won't get deployed.  Seems rediculous, but it's true.  I tested it thoroghly to make sure.  I even tried using the IgnoreIfAlreadyExists flag, but found later that that flag doesn't do what I thought it did anyway.  So what to do...

Once again I had to roll up my sleeves and dive into the SharePoint object model and create a feature receiver to solve my woes. And with the trusty Google at my side, I was able to pound out a good solution.  Thanks to Johan Leino's post on handling the IgnoreIfAlreadyExists attribute, I found most of the code I needed.  He wrote a feature receiver that uses LINQ to parse the elements.xml of a normal file provisioning feature.  Then if the IgnoreIfAlreadyExists attribute is there, his feature receiver will overwrite the current file.  I took that, then added code to deploy a new file, as Johan's code only handled updating a file that already exists.  Finally I added the deactivating functionality so that the files that are deployed on feature activation are removed after feature deactivation¹. The beauty of this solution is that it supports all the file properties that a normal SharePoint provisioning feature supports.  Just use the normal elements.xml files that you would with any other file provisioning feature, but in your feature.xml, point to the feature receiver assembly instead.  And voila, you have a beautiful, upgradable file provisioning solution!

I've attached my final .cs file as well as sample feature.xml and elements.xml files for your SharePoint developing pleasure.

Click here to download:

FileContentDeployment.zip (3 KB)

The only issue I have is that when you don't specify the path attribute in the module element of the elements.xml the feature throws an error on activation.  Obviously to solve this you just add Path="" into the module element, but I'd like to fix the .cs file so it checks that the path attribute exists before it tries to read from it.  Unfortunately I'm a newbie when it comes to LINQ, so any help on that would be appreciated.  Just let me know in the comments.

UPDATE: I just came across this post by Becky Bertram about updating page layouts.  So apparently it should work, you just have to watch out for rogue SharePoint Designer tags.

1. This turned out to be a pain because there's a bug when deleting a master page from the master page gallery.  I wrote a post on the issue and the fix a few weeks ago. You just have to create a folder, move the files-to-be-deleted into that folder, then delete the folder.  In my case I had to do that through the object model, but if you are just testing and need a one time fix, you can do all that through SharePoint designer.

A couple weeks ago I posted some thoughts on standards for SharePoint development.  I was hoping to get some feedback from other SharePoint developers on what kinds of things you standardize.  However, in spite of some great retweets and lots of page views, no one left me any comments.  That leads me to one of two conclusions.

1. SharePoint developers are so busy that they don't have time for development standards, or...
2. No one reads this blog!

Granted, 2 is a valid option, especially since I post here semi-regularly at best (though I'm making a concerted effort to change that).  However, I am starting to think that 1 has a lot of weight to it. I was originally thrown into SharePoint development, not knowing anything about what SharePoint was or how it worked.  And not only did I develop, but I was expected to administrate the farm as well.  My team was under staffed for the job, and requests for updates and help were pouring in.  Sound familiar?

So this is my attempt to generate a bit more conversation.  Because I think standards are important, but we have to evaluate where we are first before we decide where we are going.  So where are you guys at?  Can you sympathize with 1?  Are you too busy for standards?  Do you even care about standards, or does it just sound like a waste of time?

Recently my team got burned by a SharePoint consulting company that did some shoddy work.  I don't blame them entirely, we should have been more specific about our requirements and standards.  But at the same time, their work has been making me groan all week.  They updated out of the box master pages through SharePoint designer, created site templates using .stp files through the GUI, and they hard coded static links into their custom web parts that broke when we deployed them to a different location. 

So all this has shown me the value of good standards and communication.  I'm starting with the standards part.  Here's my crack at a list of standards for developing custom SharePoint functionality.  Although I've been programming in SharePoint 2007 since the beta, I know I still have loads to learn, so I wanted to enlist the help of the internets on this one.  What is standard operating procedure for you when you develop in SharePoint?  What are the musts, and what are the nice to haves?  Give me all the gory object modely details.

My Current SharePoint Development Standards List
General

• All custom SharePoint work must be deployed through SharePoint solutions (.wsp files)
• We will not import or restore any backups of sites developed by third parties. This shouldn't be a problem as all custom work will be deployed through solutions and features anyway. I wanted to avoid importing hidden designer hacks, but J.D. Wade brought up a good point, we might need to import actual content, so we can't completely write this off.
• All functionality and customizations must be documented
• Site and list templates must be created through code and features (site and list definitions). STP files are not allowed as they are not updatable.

Code

• Web parts must be deployed using our custom feature receiver (we can provide source to third parties working with us).
• Custom code must be checked for memory leaks using SPDisposeCheck.
• For site definitions, use a minimal site definition with feature stapling.
• Use best practices when accessing data using the SharePoint object model. See Working with Large Lists, Common Coding Issues When Using the SharePoint Object Model, and Using Disposable Windows SharePoint Services Objects

12 Hive Deployment

• No out of the box SharePoint files in the 12 hive will be overwritten
• Images deployed must be deployed into an RGA/ProjectName folder

SharePoint Designer

• SharePoint designer updates are generally not allowed. The only exception to this rule is for creating DataForm web parts.
• DataForm web parts must be exported through the SharePoint GUI and solution packaged for deployment as a feature.
• Editing out of the box master pages is not allowed. Instead, duplicate an existing master page, make edits, then solution package the master page for feature deployment.
• No SharePoint Designer created workflows. These are not portable and cannot be packaged for solution deployment.

InfoPath

• custom ASPX forms are preferred over InfoPath forms. They are easier to support, debug, and upgrade.
• InfoPath forms must be browser compatible. We run all our InfoPath forms deployed through forms services through the browser.
• If the InfoPath form has code behind or needs full trust it must be solution packaged and deployed through central admin. (see my previous post for reference)
• If InfoPath form does not have code behind and does not need full trust the form can be manually published to a document library, but the process and location of the document library must be documented inside the form. Just add the documentation text into a section control at the top of the form and set conditional formatting on that section to always hide the section, that way users will never see it.

Update 08-17-2020: Richard Harbridge has taken this list and combined it with other SharePoint development standards from around the internets to form a bigger list of standards.