Enumerating All SPWebs In SPFarm.Local Into Strongly Typed Collection

So when enumerating the SPWebs within a SPFarm to build a strongly typed SPWeb collection for whatever purpose your enumeration might look like this:

[csharp]

public static List WebsPreppedForIteration()
{
var collection = new List();
foreach (SPSite x in SPFarm.Local.Services.OfType().SelectMany
(svc => ((svc).WebApplications.Where
(webApp => !webApp.Properties.ContainsKey(“Microsoft.Office.Server.SharedResourceProvider”)).SelectMany
(webApp => webApp.Sites.Cast()))).Where
(x => !Equals(x.RootWeb.Title, “Central Administration”)))
{
collection.AddRange(x.RootWeb.Webs.Cast());
}
return collection;
}

[/csharp]

I saw this in a code review today. The part I am wondering about is the SPWebApplication property bag to query the key for WCAM as opposed to do a clunky string SPWeb.Title comparison. Putting the keys out to standard output hasn’t yielded anything particularly evident, and I’m getting frustrated with the under-the-hood, unnecessary foreach loop with a fancy shirt on (the second LINQ query against the Title property(,

Does anyone know the key for WCAM?

Share

Returning The SharePoint Start Workflow Link

Building the “Start Workflow” link is pretty straight forward. I am pretty sure there are better ways to do it, but here is an approach when you have to build the link using a string return. How it works is pretty straightforward. Consuming a SPListItem and SPWorkflowAssociation parameter, the SPListItem exposes the ParentList and ID properties and the SPWorkflowAssociation provides the InstantiationUrl and Id properties. The only field level stuff is I was passing a finish url in the query string (_finalurl in the below). When the link is built, it is cleaned up using the inherent SPHttpUtility.UrlKeyValueEncode method.

[csharp]
private string _finalurl;

public static string QueryStringAppend(string url, string args)
{
if (string.IsNullOrEmpty(url))
{
return url;
}
var num = url.LastIndexOf(“?”);
switch (num)
{
case -1:
return (string.Format(“{0}?{1}”, url, args));
}
return num == (url.Length – 1) ? url + args : string.Format(“{0}&{1}”, url, args);
}

protected string BuildWorkflowStartLink(SPListItem listItem, SPWorkflowAssociation workflowAssociation)
{
var builder = new StringBuilder();
builder.Append(SPHttpUtility.UrlPathEncode(string.Format(“{0}/{1}”, Web.Url, workflowAssociation.InstantiationUrl), true));
builder.Append(“?List=”);
builder.Append(listItem.ParentList.ID.ToString());
builder.Append(“&ID=”);
builder.Append(listItem.ID.ToString());
builder.Append(“&TemplateID=”);
builder.Append(workflowAssociation.Id.ToString(“B”));
string url = _finalurl ?? Request.QueryString[“Source”];
url = QueryStringAppend(url, string.Format(“{0}={1}”, FinishIdName ?? “ID”, listItem.ID));
if (!string.IsNullOrEmpty(url))
{
builder.Append(“&Source=”);
builder.Append(SPHttpUtility.UrlKeyValueEncode(url));
}
return builder.ToString();
}
[/csharp]

:)

Share

Using TFS for Mixed C#/Managed C++ SharePoint Projects

Currently, I am doing a massive TFS migration for a health insurance company, and as part of the migration I am verifying build events for all their projects. Actually I am verifying almost 10 gigs of them, so it’s going to take me the better part of a month! Now aren’t you jealous.

I was migrating some managed C++ / C# SharePoint projects and noticed something very, very interesting.

With mixed language managed C++ projects, particularly, or at least in my case, when bundled with other C# projects, it might be noticeable that some of the compiled C++ projects don’t make it to the drop location. However, some do. While it appears sporadic, those that are referenced from the C# projects are still copied. After investigation I found the root cause is that managed C++ projects actually don’t consider some MSBuild properties. In this case, the problem is the lack of observance of the OutDir property. To understand this, consider the way that Team Build harvests outputs for managed C++ projects for the drop location, they override the OutputDirectory property (in vsprops). So if CustomizableOutDir is set to true, getting those compilations to the drop folder because a manual push.

How to fix it? Get TFS 08 SP1 which has a modified CustomizableOutDir property that lets you work around this! If this option is not on the menu, you can work with CompilationOutputs item group, or something similar, so that you can ultimately override some task with a Copy task to support cloning the files to the drop location.

Share