All kidding aside, the control has a few somewhat odd quirks:

1. There are no events for when the view type changes from week, day or month. This is a simple string value that is set (by you) when the page loads. Not only this; but the value is case-sensitive (all lowercase).
2. The control doesn’t seem to work outside of a Web Part. If the control is used in a user control; binding an SPCalendarItemCollection to the datasource appears to have no affect. I found a workaround, but I really feel there has to be an easier answer, plus I’d have to forego all of the AJAX-ness that made me want to use the control to begin with!
3. If you DO decide to use the SPCalendarView in a Web Part; it must be derived from the SharePoint Web Part class, not the ASP.NET Web Part class.

OK, now that I’ve named a few of the limitations; how many of you just gave up? Hold on! I have some good news….

After digging through a lot of JavaScript in the SharePoint ECMA Script Library, I was able to pin point the issue and in short; the control was never really designed to work outside of a Web Part. The control is very heavy on the AJAX, in fact the data is stored in a JSON fragment on the page then loaded after the page is loaded. The AJAX implementation of the control can be found in the SP.UI.ApplicationPages.Calendar.js file at the SharePoint root. In this file you’ll see the following function definition:

SP.UI.ApplicationPages.ElementUtility.$3f = function ($p0) {
    return $get('WebPart' + $p0);
}

Notice that the function is assuming that the control that is being requested for binding is ALWAYS a Web Part (remember, the calendar data is in a JSON fragment and loaded in JavaScript AFTER the page loads). The function always prepends the string ‘WebPart’ to the ID of the control when supplying the argument to the $get function. Obviously if we are using the SPCalendarView in a user control or application page, this is going to fail. So how do we fix it?

Since SharePoint 2010 has the handy SP.SOD class; we can write a function that executes when the page loads and will redefine the above function.

Let’s assume we have a user control that’s hosting the SPCalendarView and let’s place the following code above our SPCalendarView declaration in the ASCX file to use an anonymous function to redefine the offending function like so:

<script type="text/javascript">
SP.SOD.executeOrDelayUntilScriptLoaded(function () {
    SP.UI.ApplicationPages.ElementUtility.$3f = function ($p0) {
        return ($p0.substring(0, 3).toUpperCase() == "WPQ")
                   ? $get('WebPart' + $p0)
                   : $get($p0);
    }
}, "SP.UI.ApplicationPages.Calendar.js");
</script>
<SharePoint:SPCalendarView
  ID="calSample"
  runat="server">
</SharePoint:SPCalendarView>

This little fragment of code will check to see if the provided ID is a Web Part and if it is not; it will try to get the element without adding the ‘WebPart’ prefix to the ID. Furthermore, we’ve addressed the issue that allows use to utilize the SPCalendarView control without modifying any of the OOB JavaScript files in the SharePoint root. Wrapping the whole bit in an SP.SOD.executeOrDelayUntilScriptLoaded function call ensures that the JavaScript file will have been loaded before we try to redefine it.

You might need to make some small changes to the script in your implementation, but with this little JavaScript fragment, you can harness the power of the SPCalendarView control in your custom SharePoint applications.

If, on the other hand, you do end up deleting Fab 40 Sites after migration, you may end up with the dreaded “Missing Server Side Dependencies” error message in your Health Analyzer.

After much research we determined that the issue was not a orphaned feature, but simply that the original site was still in the content database because it was still in the Recycle Bin.  Simply removing the site from the Recycle Bin cleared up this Health Analyzer rule in this case.  SharePoint will probably clear this up for you in about 30 days after migration when it cleans out the Recycle Bin, but if you would like to resolve this error message without waiting you can do so by deleting the deleted sites from your Recycle Bin manually.  Just be sure you truly never want to restore those sites.  Hope this helps.

It’s SharePoint’s world. We just develop in it.

This sentiment is all too familiar to many SharePoint devs I have spoken with, including myself. Solid developers—but mired in the constraints of a platform whose boundaries are not always clear.

Here’s the thing. SharePoint is not a platform for developers—it’s a productivity tool that empowers end users. The fact that there are as many places in its pipeline for .NET nerds to stick their considerable proboscises into as there are is actually pretty generous.

Any platform derives its value from the altitude of its starting point. The price of the ticket to this altitude is the loss of control over exactly where you can go from there.

Happy SharePoint developers understand its power and embrace its constraints. If all you notice is how much the SharePoint infrastructure seems to get in your way, or you mope through your tasks under a cloud of “we don’t have to do it this way in regular ASP.NET”, you are sure to miscalculate your code’s relationship with its host, and many of the little decisions you make every day as a developer will be skewed, or even straight up wrong.

When you know and embrace your platform, however, something excellent happens. The big picture comes into focus, and you are set free to see new patterns and approaches to your work. Specifically, you gain a better understanding of what code belongs within the constraints of SharePoint, and what code does not. For example? Sahil Malik has long been an advocate for SharePoint solutions as lightweight clients to WCF services that house the real .NET nitty-gritty of the application. And my new favorite MVP du SharePoint, Jason Kaczor, relates here how he eschews Web Parts altogether, and develops nimble HTML5 code that accesses SharePoint data via its OData feeds.

Wait. You didn’t know that SharePoint exposes its data in OData feeds?

Know and embrace your platform.

function openMySweetModalDialog(id) {
    var options = SP.UI.$create_DialogOptions();
    options.width = 500;
    options.height = 250;
    options.url = "/_layouts/SharePointModalDialog/SweetDialogPage.aspx?id=" + id;
    options.dialogReturnValueCallback =
        Function.createDelegate(null, whenMyModalDialogCloses);
    SP.UI.ModalDialog.showModalDialog(options);
}

function whenMyModalDialogCloses() {
    alert('That was totally sweet.');
}

But this is SharePoint—which means (for us developer types, at least) that we’re couched firmly in the world of ASP.NET WebForms. The ECMAScript we sling around here tends to get put there by server-side code, especially if it calls for a touch of dynamism.

And a modal dialog is, by nature, a dynamic element—if you are using it right, there will likely be some parameters to pass in. An item’s ID number, for example.

So launching our dialog from the code-behind in just such a case should be a simple matter of formatting a JavaScript string with our parameter value, and then using the page’s ClientScript control to register us up some startup action:

public partial class MySweetAppPage : LayoutsPageBase
{
    protected void Page_Load(object sender, EventArgs e)
    {
        OpenMySweetModalDialog(5);
    }

    protected void OpenMySweetModalDialog(int id)
    {
        // create ECMAScript to call the dialog function and pass the id
        var script = string.Format(@"openMySweetModalDialog('{0}'); ", id);

        // emit script to run on page load
        Page.ClientScript.RegisterStartupScript(
            typeof(LayoutsPageBase), Guid.NewGuid().ToString(), script, true);
    }
}

Well that was easy. In fact, I have half a mind to check that in untested, I feel so very positive about it. What’s that, you say?

Don’t go into that dark basement?

Fine. I’ll run it once. You know, just to underscore the excellence of my l33t 5k1llz and give myself a warm, high-fivey sort of feeling.

Figure 1. Crickets.

Here’s The Charlie Brown Football-Kicking Part

So now I’m laid out on my back, the wind knocked clean from my lungs, a foaming anger brewing over what a cruel mistress SharePoint is to have yanked this football away from me. Halfway through actualizing my happy place and realigning my nerd chakra, I decide that this mystery warrants a little DOM sniffing.

First, some good news. The sky is still blue, and still firmly above our heads: the RegisterStartupScript call works, because our humble line of script has been rendered to the markup in all its glory:

Still further good news. The SharePoint Modal Dialog Framework is not a lie that our parents have us wash down with warm milk and a hug—calling our function from the JavaScript console actually does invoke the popup as intended:

Then what manner of pigskin-yanking tomfoolery stands in the way of our function landing the punt while the page is loading?

Order Up

Did you know? Before our page can call upon a modal dialog framework to, say, create a modal dialog, our page has to have loaded said modal dialog framework.

It also turns out that this framework is defined in SharePoint’s aptly-named sp.ui.dialog.js file. Pray tell, then, O scriptacious gods of portal app pop-upage: how can we ensure that the execution of our dialog invocation is delayed until this fine script file is duly at the ready?

Oh, how they do provide.

How Sweet It Is

So, when we put that little nugget to work for us, the official right way to invoke a SharePoint dialog from server-side code looks something like this:

protected void OpenMySweetModalDialog(int id)
{
    // wrap our call in a parameter-less function, and  
    // delay its execution until sp.ui.dialog.js is loaded
    var script = string.Format(
        @"function reallyOpenDialogForRealYouGuys() {{ 
            openMySweetModalDialog('{0}'); 
        }}; 
        SP.SOD.executeOrDelayUntilScriptLoaded(reallyOpenDialogForRealYouGuys, 'sp.ui.dialog.js'); ",
        id);

    // emit script to run on page load
    Page.ClientScript.RegisterStartupScript(
        typeof(LayoutsPageBase), Guid.NewGuid().ToString(), script, true);
}

A press of my well-worn F5 key, and:

There. How you like me now, webpage?

Scenario:

You have been tasked to create a farm solution that must be configurable upon deployment. Configuration settings must be stored centrally, allowing SharePoint farm administrators to modify configuration settings from Central Administration. Globally stored settings will be accessed by features with Web application, site collection and Web scopes.

Solution:

I’ll begin by stating that there are numerous ways to satisfy the requirements, but I am going to focus on one potential approach. Consider the following:

1. Custom Actions are very handy ways to plug navigational elements into the SharePoint UI. Understanding and identifying the appropriate location for a custom action can greatly assist in the management of your solution. For example, the following CAML wrapped up in a farm feature can add links (UrlAction elements) to configuration pages. The Location attribute will determine where a these elements will be presented. The screenshots below demonstrate how we can surface links to configuration screens right from Central Administration, by specifying that the links are located in Microsoft.SharePoint.Administration.Default location. 

   

   

   Notice that the URLs of the UrlAction elements navigate to an application page that will provide a Web form for administrators to manage these settings. A second CustomActionGroup is used to provide an expanded set of actions when navigating to the general settings page by clicking the POC Management heading. In this example, we’ve defined our own custom action location. This location is then referenced using the AdminControlPanel control on the settings page. The result is a behavior that is congruent with other primary areas of configuration in Central Administration:

   

   

2. Application Pages are used to create Web forms for administrators to interact with configuration settings. An application page used in conjunction with a custom action can truly make your custom solution feel seamlessly integrated with SharePoint. This Web form would then save the settings to a central repository for all features to reference. One likely candidate for storing such data would be to use an SPPersistedObject.

We’ve really only scratched the surface when it comes to building configurable solutions. Other examples may include:

1. A custom list definition with custom settings. In such an example, a custom action could be made available on the advanced list settings screen. The application page used for managing the settings could then save the settings to the property bag of the parent SPWeb.
2. A custom Web feature with custom settings. In such an example, a custom action could be made available on the Site Settings screen. The application page used for managing the settings could then save the settings to the SPWeb’s property bag.

The benefits of building solutions that are configurable usually outweigh the required additional development effort. As good stewards of SharePoint development, we should always look to build solutions that leverage SharePoint as a platform, while ensuring that we’ve provided administrators with the proper tools to manage our solutions.

$sa = Get-SPServiceApplication –Identity <UPA GUID>
$sa.NetBiosDomainNamesEnabled="True"
$sa.update()

After this is completed, you must create a new synchronization connection. Be aware, in our experience, deleting an existing connection will purge your existing profiles. That works great if done before any profiles have been updated. Our issue was what to do to apply this same fix but preserve existing profiles and their information. The fix? A combination of enabling NetBiosDomainNames on the UPA and resetting Profile Synchronization using PowerShell. First, the situation: We have a profile store with over 2000 profiles in it. Approximately 800 of which have been updated by end users. Due to a previous issue with the UPA, this is the second incarnation of the UPA at this client. Unfortunately after this one was created the synchronization connection was created before the NetBiosDomainNamesEnabled property was flipped. Now we had new profiles coming into the UPA with the first part of the FQDN instead of the NetBIOS name.

You can find the link to TechNet on how to “Reset Profile Synchronization by using Windows PowerShell” here.  This is part of bigger article on maintaining the SharePoint 2010 Profile Synchronization.

Here is the TechNet article verbatim:

Here are some addendums to this for our use:

In Step #9, we modified the script to find the User Profile Service Application

$syncdb = Get-SPDatabase | where {$_.name -eq "User_Profile_Service_Application_Sync_DB"}

$syncdb.Unprovision() $syncdb.Status=‘Offline’

$upa = Get-SPServiceApplication | where {$_.name -eq "User Profile Service Application"}

$upa.ResetSynchronizationMachine()

$upa.ResetSynchronizationDatabase()

$syncdb.Provision()

• Replace with the name of your sync DB and your UPA.
• This script does not show any status or progress, so you may adjust your script to show you it is working.

  

We did not find step #14 necessary.

Step #17 is not necessary if your UPA is on a different server than your Central Admin.

Now make sure you flip the property on the UPA:

1. Copy the following code and paste it into a text editor, such as Notepad:

   $upa = Get-SPServiceApplication | where {$_.name -eq "User Profile Service Application"}
   $upa.NetBiosDomainNamesEnabled = "True"
   $upa.Update()

2. Replace with the name of your UPA.
3. Save the file as ANSI-encoded text file and name the file EnableNetBiosDomainNames.ps1
4. At the Windows PowerShell, type the following command:

   .\EnableNetBiosDomainNames.ps1

   Notice there are now no Synchronization Connections:

   

Step # 18 in the TechNet Article:

Run a full profile synchronization.  For more information, see Perform a nonrecurring profile synchronization.

I would recommend a full crawl on your search service application as well to make sure all People results are accurate.

This seems to have worked well for us and allowed us to clean up our UPA. I hope it works well for you too.

SharePoint 2010 introduced the ECMAScript Client Object Model. One of the things that it included was the Dialog Framework. This allows modal dialogs to be easily displayed inside of SharePoint. This is typically done by specifying a web page to be displayed as the dialog on top of the current web page. In this first example, a page named BasePage.aspx is displaying a dialog that is popupForm.aspx.

Displaying Dialogs

It is fairly trivial to display a dialog. All you have to do is initialize an options object and call SP.UI.ModalDIalog.showModalDialog. In this example, the page popupForm.aspx will be displayed as the modal dialog. When the dialog is closed, the method named “callbackMethod” will be called.

Passing Arguments in the URL

In many cases, you will want to pass a value to the dialog. The first way to do this is to pass it in as a query string. All that needs to be done is to append the appropriate item and value to the URL. In this example, “7” would be passed to the dialog in a query string named “ItemID”.

The value would be retrieved by the dialog in the code behind just as any query string would be retrieved. In this example, the code behind written in C#.

Passing Arguments in the Options Object

The other way to pass arguments to the use the args field in the options object. In this example, a value of 7 would be passed to the dialog as an argument.

The value would be retrieved in javascript using the window.frameElement.dialogArgs property.

Returning a Value from the Modal Dialog

When the user closes the modal dialog, at least one value is returned to the base form. This value is passed to the callback function specified in the options object. This value is the dialog result. The value will depend on how the dialog was closed.

• If the dialog was closed by calling window.frameElement.cancelPopUp, the result will be SP.UI.DialogResult.cancel.
• If the dialog was closed by called window.frameElement.commitPopup, the result will be SP.UI.DialogResult.ok.
• If the dialog was closed with window.frameElement.commonModalDialogClose, the result is specified in the first parameter.

Side Note: The method named cancelPopUp capitalizes the ‘U’. The method named commitPopup does not.

Here is an example of how the callback would handle the result in JavaScript.

Handling the Callback


function callbackMethod (dialogResult, returnValue) {
    if(dialogResult == SP.UI.DialogResult.ok){
        // The user clicked the OK button.                 
        // handle commitPopup         
    } else{
        // The user clicked the Cancel button.                 
        // handle cancelPopup         
    }
}

If the dialog needs to be closed from the code behind and not from client side code, the JavaScript is simply inserted in the response.

Returning an Argument

If you want to return an argument from the dialog, it is passed as the first parameter to the commitPopup. In this example, the dialog would return 7.

The value is received in the second parameter of the callback method. In the following example, the return value is placed into a hidden field on the base page.

And in terms of this blog, I prefer to write about the latest version of SharePoint. 2010, as of this missive. Because, from a sort of Buddhist perspective, SharePoint 2007 has been done, and is now just an idea. It has been the legacy version for about a year now. And the corner of the Internet where developers write about MOSS and WSS, I’m fairly certain, is full.

The Pledge

Regardless of the above granola sprinkles, I do my fair share of work in MOSS 2007. Because, like it or not, this platform was designed for businesses whose aim is probably something other than backing up the Brinks truck for the latest greatest version of portal software every few years.

The tooling advances that 2010s SharePoint and Visual Studio have provided are wondrous and pampering. They make it easy to forget that we used to need a Server version of Windows to have a SharePoint instance to develop against, and that, often, the contemporary browser of SharePoint 2007, Internet Explorer 6, was the main target for your work.

And as soon as you get up out of that ridiculous fetal position, I’ll walk you through how I get all of this done without having to step into what only appears to be an ordinary phone booth^[1].

The Turn

As I mentioned above, the foundation for a MOSS 2007 development machine is a Server version of Windows. I use 2008 R2, installed to a Virtual Hard Disk (.vhd) that I boot my laptop to directly. Running this late model of Windows Server lets me leverage IE9 to test for modern browser conditions. And because it is shiny, anachronism be damned.

But it also leads me straight to the rub of this setup: How can I also test my work for IE6 compatibility?

Internet Explorer, of course, does not allow multiple versions to be installed simultaneously on the same machine. Many well-meaning, golden-hearted folk have attempted to circumvent this web dev-lemma with offerings like IETester and MultipleIE. The former comes close in some cases to accurately emulating the adorable quirks of the browser we love to hate. If you need to ship pixel-perfect branding, though, close just won’t cut mustard. And I’m not sure what’s going on with MultipleIE, but whatever it is, it was not going on in my Windows Server 2008 R2 environment.

So, at this point in devising my rig, the best option seemed to be to virtualize, running IE6 on a Windows XP VM within my already-virtual server. Now, I see what you’re thinking there, but this is no time for a cheap Inception reference. We need to go deeper.

The release of Windows 7 (the client edition of my chosen Windows Server version) brought us the virtual security blanket we call Windows XP Mode. This would be the ideal fix—a virtual Windows XP machine, running bona fide IE6, with the latest Internet Explorer running on the host system so I can eat my cake, too.

The Prestige

But I’m running Windows Server—XP Mode is only supported for client editions of Windows. And maybe I’m a joker for even trying, but enabling Hyper-V on an already virtual Windows Server made my laptop angry in that special kind of way. You know, when you genuflect for the entire time that the subsequent restore is chugging? That way.

I had all but given up on achieving an IE6-friendly MOSS 2007 development setup on Windows Server 2008 R2, turning my attention instead to strategically unclenching, and to assuring my family that I was still a willing participant in whatever lives they had going on in the meantime.

Okay, now—do you see that? Right where I let go and let God? That’s about when I happened on VMLite.

The good people over at VMLite have worked some manner of dark magick that leverages VirtualBox to deliver a Windows XP Mode machine without requiring hardware virtualization, allowing it to hum along contentedly in more or less whatever odd hosting arrangement you can dream up.

Figure 1. My fully operational SharePoint 2007 battle station

Finally, I was afforded the luxury of testing my SharePoint 2007 work in a very particular CSS insane asylum. One that we can hope will very soon be done, and will very soon be just an idea.

1. If you’re from the United States and you’re awesome, that’s a Bill & Ted reference. If you’re English or just super into the Nerdist, it’s a Doctor Who nod. Dimensionally transcendental, in either case. ↩

In my opinion, the ECMA Script Library in SharePoint is one of the most welcomed features of the product. My background is in Web application development, so I have been using AJAX technologies for quite some time. In the past, leveraging AJAX techniques from SharePoint was all on the hands of the developer. We’d have to build custom Web services to handle our actions and then consume the Web services from JavaScript. Enabling ASP.NET AJAX in SharePoint 2007 wasn’t difficult, but it had its fair share of “gotchas”. The community responded with great projects such as SPServices which is a huge step forward; but the issue remains that SharePoint needed a more AJAX centric core. With SharePoint 2010, we have it.

So how does it work? If you’ve looked at the SharePoint managed client object model or ASP.NET AJAX, you’ll already be familiar with the pattern:

1. Requests are created using the context of the user.
2. Queries for operations are constructed.
3. Queries are executed asynchronously.
4. Callback functions execute on the success or failure of the operation.

So let’s look at an example:

I need a JavaScript function that will copy a file from a source URL to a destination URL. The source file is in the current site that the user will be browsing. I want the file to be overwritten if it already exists.

Using the ECMA Script Library we can accomplish this goal:

/// <reference path="D:\Program Files\Common Files\Microsoft Shared\Web Server Extensions\14\TEMPLATE\LAYOUTS\MicrosoftAjax.js" />
/// <reference path="D:\Program Files\Common Files\Microsoft Shared\Web Server Extensions\14\TEMPLATE\LAYOUTS\SP.js" />
/// <reference path="D:\Program Files\Common Files\Microsoft Shared\Web Server Extensions\14\TEMPLATE\LAYOUTS\SP.Core.js" />
function copyFile(sourceUrl, destinationUrl) {
    var ctx, file, notifyId;

    ctx = SP.ClientContext.get_current();

    file = ctx.get_web().getFileByServerRelativeUrl(sourceUrl);
    ctx.load(file);

    // Set a notification to the user that we are going to copy the file.
    notifyId = SP.UI.Notify.addNotification('Copying file...', true);

    ctx.executeQueryAsync(
        function (sender, args) {
            // File loaded. Now we want to copy the file. We'll use a nested AJAX call
            file.copyTo(destinationUrl, true);

            ctx.executeQueryAsync(
                function (sender, args) {
                    // File copied successfully!
                    SP.UI.Notify.removeNotification(notifyId);

                    // Let the user know that the operation was successful
                    SP.UI.Notify.addNotification('File copied successfully', false);
                },
                function (sender, args) {
                    // Unable to copy file.
                    SP.UI.Notify.removeNotification(notifyId);

                    showError(args.get_message());
                });
        },
        function (sender, args) {
            // Unable to locate file.
            SP.UI.Notify.removeNotification(notifyId);

            showError(args.get_message());
        });
}
function showError(msg) {
    var statusId;

    statusId = SP.UI.Status.addStatus('File Copy Error:', msg);
    SP.UI.Status.setStatusPriColor(statusId, 'red');

    // Remove the error message after 5 seconds
    window.setInterval(function(){SP.UI.Status.removeStatus(statusId);}, 5000);
}

That code sample is a bit lengthy, but you can see that we can use the ECMA Script Library to create a reusable JavaScript function to work with files; and this is just the tip of the iceberg. We can then use jQuery or some other means to invoke this function from a click handler. The result; file management operations in SharePoint entirely from JavaScript. Truly wonderful….

I was faced with an example of this today. I was assisting in the building of a new SharePoint 2010 farm and I had noticed that the Usage and Health Data Service Application Proxy was stopped. Having seen this before, I knew that there wasn’t a way (at least that I know of) to start the service application proxy from Central Administration, so I would have to resort to the SharePoint 2010 Management Shell; which I am growing to love more and more by the day. A quick two lines of script, and the service application proxy was back online:

$svcAppProxy = Get-SPServiceApplicationProxy | Where {$_.Name -eq "Usage and Health Data Service Application Proxy"}
$svcAppProxy.Provision()

#End

Almost seems too easy, doesn’t it?

Now, I know this this is a pretty basic example but I feel it is worth noting for these two very important reasons:

1. It illustrates that PowerShell isn’t just for the developer. This was an administrative task and we’ll all need to be on board to support such a scenario.
2. PowerShell scripting doesn’t have to be intimidating. Gary LaPointe’s blog is a fantastic place to see just how far you can take PowerShell and automation with SharePoint. But as we saw above, PowerShell is great for small tasks too.

Writing PowerShell scripts doesn’t have to be a pain!

The thing that I always hated about batch files and STSADM was the fact that writing batch commands was such a cryptic experience. We’re used to nice IDEs, so if we are going to be expected to write scripts for these products; we’ll need good tools to write and test our scripts.

The community around PowerShell is growing and so are the tools. Personally, I’m a fan of PowerGUI by Quest Software. PowerGUI can load external PowerShell libraries (like SharePoint) and even has intellisense, as shown in the screen captures below:

Adding Snapin

PowerGUI Intellisense

As you can see, with the right set of tools; our script from above is pretty simple isn’t it?