SharePointers

We had a lot of sites that needed to have versioning turned on, here's a simple console app I wrote to do this, you just pass the url of the web as an argument: using System; using System.Collections.Generic; using System.Linq; using System.Text; using Microsoft.SharePoint; namespace Mirant.Utilities.SiteVersioningActivator {     class Program     {         static void Main(string[] args)         {             if (args.Length != 1)                 throw new Exception("URL of the site is required as a parameter");             string webUrl = args[0];             using (SPSite site = new SPSite(webUrl))             {                 using (SPWeb web = site.OpenWeb())  ...

This is definitely from the "I can't believe I hadn't blogged this already department". When you try to use the SPListItem.Url property you wind up getting a url that's relative to the site (even though it starts with a '/'). I've written this method that will return a list item url and takes into account the fact that the urls differ when they're lists or document libraries: private string GetItemUrl(SPListItem listItem)         {             string result;             string itemUrlTemp = listItem.Url.Replace("Lists/", "");             string siteRelativeListUrl = itemUrlTemp.Substring(0, itemUrlTemp.IndexOf('/'));             if (listItem.ListItems.List.BaseTemplate == SPListTemplateType.DocumentLibrary)                 result = SPEncode.UrlEncodeAsUrl(String.For...

SPFile.MoveTo(), at first glance, looks to be a very straightforward method where a file can be moved from one folder to another. Trying to use it and have an alert triggered by your newly copied file? Forget it. MoveTo() copies the binary to the target library as expected, but fails to recreate the item metadata (created, modified, users, dates, etc.) and will not trigger the alerts that your users set up for the target library. To work around this problem, you can create your own method that uses the SPFileCollection.Add(), which allows you to specify metadata, as described here: http://www.u2u.info/Blogs/Patrick/Lists/Posts/Post.aspx?ID=1141

I updated my page layouts that I deployed as a feature, but found that I could not overwrite the Layout File. The solution was to add a new page layout and then you would have to associate the new layout with every page on your site that used it. Obviously with a site of any size you'd have a lot of manual work to get this done, so doing it programmatically makes for a much better (and thorough) approach. After you've got your new page layouts, you could do something like this (in your event receiver class): public override void FeatureActivated(SPFeatureReceiverProperties properties) { //replace current page layouts with new page layouts on all pages SPWeb web = SPContext.Current.Web; SwapPageLayout(web, "FullWidthContentWithTitleV1.aspx", "FullWidthContentWithTitleV2.aspx"); } private void SwapPageLayout(SPWeb web, string oldPageLayoutName, string newPageLayoutName) { PublishingWeb pubWeb = PublishingWeb.GetPu...

Because SharePoint will display active links to MySites that might not exist, I was asked to "pre-create" all of the MySites before an upcoming rollout to prevent any confusion from "broken" links. I found a tool at codeplex called TIN that seemed to do what I needed, but it was a little clunky so I rewrote it. The new version is incredibly simple, but it might save somone some time so I thought I'd share. Basic features include: Bulk creation of MySites for entries in the ProfileManager Bulk deletion of MySites for entries in the ProfileManager List profiles from the ProfileManager and whether they have a MySite Robust logging and error handling Save-to-File for log results Multiple threads for long-running operations and smoother screen updates The source code isn't so beautiful, but here it is . Feel free to make any changes you like, and let us know if it worked for you. Also, if you do make changes and want to share, just send it in and we'l...