Getting The Full, Absolute URL Of A ListItem In Office 365

I don't know why Microsoft made it such a pain in the ass to get the url for most of the proxy objects on the SharePoint server object model, but in Office 365 it is even worse. Here is an example of how to get a ListItem actual URL and the modified date of the item. Following I will throw the values into a dictionary.

[csharp]

Dictionary urlDict = new Dictionary();
foreach (List list in ListsToProcess)
{
ListItemCollection items = list.GetItems(CamlQuery.CreateAllItemsQuery());
list.Context.Load(items);
list.Context.ExecuteQuery();
foreach (SharePointListItem item in items)
{
list.Context.Load(item, x => x["FileRef"], x => x["Modified"]);
string startUrl = list.Context.Url;
list.Context.ExecuteQuery();
string fullUrl = startUrl + item["FileRef"];
string lastModified = item["Modified"].ToString();
if (!urlDict.ContainsKey(fullUrl))
{
urlDict.Add(fullUrl, lastModified);
}
}
}

[/csharp]

Share

Fixing Access Denied Errors With SharePoint 2010 Timer Jobs

It is important to realize before we get started that this error was also present within SharePoint 2007. When creating timer jobs, it is important to understand the relationships between the SPSecurity.RunWithElevatedPrivileges method and the associated SPWebApplication object. When using SPSecurity.RunWithElevatedPrivileges, it will not allow modification of the SPWebApplication since it is persisted to the configuration database. However, other proxy objects are exempt from this such as SPSite ‘s and SPWeb ‘s. SPSecurity.RunWithElevatedPrivileges allows the elevation to just the content database, NOT the configuration database (which has the SPWebApplication property bag) which is generally more locked down.

The easiest way to fix this is to impersonate the user account for proxy objects (assuming you are using a current context to reference the application property) with an account that has the wss_content_application_pools database role for the config database since this will have elevated rights for stored procedures and what not. This will allow you to modify your timer jobs easily. If you want to be really lazy, just use the same account as the central admin app pool which inherently provides the required access to the configuration database.

Share

Writing Object Use to Standard Output

A preponderance of fundamental SharePoint proxy objects implement the IDisposable pattern, and therefore the disposal state of such objects becomes a subject of interest, this is predominantly important when using mock object schemes. Recently, I had to do just this and it’s not actually very complicated, but I needed to remember it so decided to post it. While the goal was to make the method analogous to type, the approach can be easily schemed to SharePoint proxy objects, since as you can see it’s a very simple approach.

In the below, the new static extension method TraceUsing in class Extensions is being defined. Since we are going to follow a object, the instance represents type “T” and the Action parameter set to type “T” lets you specify an action to be performed on “T”. In my specific case, the parameter supply to Action was just a write to standard output saying that we are currently using an arbitrary object (to an HtmlTextWriter in my case).

[csharp]
public static class Extensions
{

public static void TraceUsing(this T instance, Action action)
{
try
{
action(instance);
}
finally
{
var disp = instance as IDisposable;
if (disp != null)
{
disp.Dispose();
}
}
}
}

[/csharp]

Share