How I solved an “obsolete GetPostBackReferenceEvent” compilation error in SharePoint 2010

While happily writing code and enjoying a fresh Spring breeze through my office window today, I received an ominous email from a user at a client’s company. The email said the user was trying to edit the membership of a group in SharePoint when they saw this:

An error occurred during the compilation of the requested file, or one of its dependencies. Warning as Error: 'System.Web.UI.Page.GetPostBackEventReference(System.Web.UI.Control)' is obsolete. 'The recommended alternative is ClientScript.GetPostBackEventReference. http://go.microsoft.com/fwlink/?linkid=14202.'

This seemed very odd to me because the URL of the page was “/_layouts/people.aspx,” which is obviously an out-of-the-box page that’s supposed to work. Also, this error was only happening on one of the three zones we’d configured for this web application. The page loaded fine in the other two zones. I did some searching online but didn’t find anything useful other than one guy saying he’d restored the DLLs in the SharePoint ‘ISAPI’ folder from a backup and that fixed the problem for him.

In hopes of getting a better error, I enabled debugging in the web.config file for the zone where the user was seeing this, including setting “<compilation debug=’true’ />.” The next time I loaded the site the problem was gone. So it appears that causing ASP.NET to recompile the web app was sufficient to solve the problem. When I finished testing I turned debug mode off and everything still worked.

Quick Tip: Getting Your SharePoint Farm’s Build Version with PowerShell

Assuming you have the appropriate permissions and server access to run PowerShell cmdlets against your SharePoint 2010 or 2013 farm, here’s a super quick way to get the current build verison of your farm:

(Get-SPFarm).BuildVersion.ToString()

Sample output from 2 farms of mine:

  • SharePoint Server 2010: 14.0.6129.5000
  • SharePoint Server 2013: 15.0.4420.1017

Using XML Configuration Files with Your SharePoint PowerShell Scripts

Like most developers, I’m pretty lazy. I like to automate things whenever possible so that (a) I don’t have to perform manual steps over and over, and (b) I’m ensuring a certain degree of consistency.

One area where I particularly love automation is SharePoint configuration and administration. It’s extremely frustrating to deploy something to SharePoint, get an error when you know it worked just a couple of days ago, and spend time tracking down the issue only to find you forgot something trivial like activating a feature or putting a setting in a web.config file. Maybe you didn’t have enough coffee that morning? Probably…. at least, that’s what I usually blame it on.  :-)

Automation can drastically reduce issues like I just described plus make your life much easier by just running a PowerShell script and letting it do the work for you.

Of course, like most programs that do work for you, PowerShell scripts tend to require a certain amount of configuration as you move them across environments (e.g. development to test) and so on. There’s not really a concept of “app.config” or “web.config” built into PowerShell like we might be accustomed to in the .NET universe. HOWEVER, PowerShell does have the ability to easily read an XML-based configuration file into a strongly typed .NET object (System.Xml.XmlDocument) so you can easily access your settings. This effectively gives you the concept of an app.config or web.config file except you make up your own schema to fit your requirements.

Interested in learning how to do this? Check out a YouTube video I made that demonstrates how to do it.

In the video I walk you through how to use this technique to perform configuration tasks against a site and web application in SharePoint 2013. Enjoy!

Programmatically Determine the URL(s) of FBA-Enabled Zone(s) in SharePoint 2010

I recently had a case where I needed to programmatically determine which zone in my SharePoint 2010 web application had forms-based authentication enabled and then return the public/default URL of that zone.

The reason was a custom application page in SharePoint was sending out emails with links back to SharePoint, and in this case those links needed to always redirect users to the FBA-enabled zone so we send them through a custom login/registration process we’d configured on that zone. Administrators using this custom application page might be accessing the page from one of the non-FBA-enabled  zones on the web application – hence the reason to programmatically determine the correct URL to include in the email.

Here’s the code I ended up using to find the URL:

using Microsoft.SharePoint;
using Microsoft.SharePoint.Administration;

public static string GetFbaZoneUrl(SPWeb web)
{
    string url = null;

    foreach (var zone in webApp.IisSettings.Keys)
    {
        var settings = webApp.IisSettings[zone];
        var fbaProvider = webApp.IisSettings[zone].FormsClaimsAuthenticationProvider;

        if (fbaProvider != null)
        {
            // We found the zone on the web app where FBA is enabled.
            // This is the zone whose URL we want.
            SPAlternateUrl fbaUrl = webApp.AlternateUrls.GetResponseUrl(zone, false);
            if (fbaUrl != null)
            {
                url = fbaUrl.IncomingUrl;
            }
            break;
        }
    }

    if (url != null && !url.EndsWith("/"))
    {
        url += "/";
    }

    return url;
}

As you can see in the code, I break from the loop after finding the first FBA-enabled zone in my web application because I know there will never be more than one in my case. If for some reason you have multiple zones configured to use FBA, you could modify this code slightly to return a list of all FBA URLs or filter down to the one(s) you want by some criteria (such as the membership/role provider names). The AlternateUrls property of the SPWebApplication object allows me to grab the response URL (i.e. the default URL) for a given zone.

Test and Debug SharePoint CAML Queries with PowerShell

As a SharePoint developer, I’m a big fan of PowerShell. One of the main reasons I like it is because I can essentially write and test .NET code to work out issues and bugs before I go through the cycle in C# of writing the code, compiling it, deploying it to SharePoint, and then testing it.

In the spirit of sharing development tips and techniques, I published a short video on YouTube demonstrating how I use PowerShell to test and debug CAML queries for SharePoint: http://youtu.be/Umcfew-_92E

How to Import a Web Part on a Page in SharePoint Online

One minor annoyance of SharePoint Online in Office 365 is the fact that the web part adder panel and upload button aren’t present by default when adding web parts to a page. If you have something like a .webpart file for a Content Query Web Part that you’ve preconfigured and want to import into the page, this is a problem.

I’ve uploaded a short video on YouTube describing two ways to do a web part import in SharePoint Online. Both are pretty simple.

Another New Year Already?

Wow, I can’t believe it’s already 2013!! This past year went by WAY faster than I was expecting. I’m going to try to start the year off right… by posting my goals and predictions for the year on my blog like all good bloggers.

Goals for 2013

  • Get some awesome on-demand training courses posted online.
  • Speak at a conference or two.
  • More blog posts and more SharePoint Pro Magazine articles (fell behind on this in 2012 due to the book).

Predictions for 2013

  • More small and mid-size companies will move to Office 365 and “the cloud.”
  • More mobile apps will be developed that integrate with SharePoint and leverage its capabilities.
  • We’ll see apps being developed and sold in the SharePoint 2013 app store.
  • We’ll see an increase in demand for SharePoint training because of a broader developer base (thanks in part to the app store).
  • No matter how cool SharePoint 2013 is, SharePoint will continue to be occasionally frustrating to work with… just as it always has been.

Here’s to a great 2013!