If you wonder how .asmx files relate to SharePoint solutions you can find some information about that here: AJAX Style Web Parts in SharePoint the Easy Way.

Your .asmx file will consist of a single line like the one below. Getting the assembly’s strong name is a challenge of it’s own but having to keep it up to date is what will worry you most:

<%@ WebService Language="C#" Class="AjaxWP.AjaxWS, AjaxWP, Version=1.0.0.0, Culture=neutral, PublicKeyToken=d76004e99c897b9f" %>

Change that line to the one below to let MSBuild do the work for you:

<%@ WebService Language="C#" Class="AjaxWP.AjaxWS, $SharePoint.Project.AssemblyFullName$" %>

The final step is to tell MSBuild to replace tokens in .asmx files. You can do that for a specific project or for all projects you build on that machine.

Replacing Tokens for a Specific Project

To let MSBuild replace tokens for a specific project add a TokenReplacementFileExtensions element to your .csproj file like shown below. To which PropertyGroup element you add it doesn’t matter – it just has to be added before the Import elements.

<?xml version="1.0" encoding="utf-8"?>
<Project ToolsVersion="4.0" DefaultTargets="Build"
  xmlns="http://schemas.microsoft.com/developer/msbuild/2003">
  <!-- ... -->
  <PropertyGroup>
    <SignAssembly>true</SignAssembly>
    <TokenReplacementFileExtensions>asmx</TokenReplacementFileExtensions>
  </PropertyGroup>
  <!-- ... -->
  <Import Project="$(MSBuildToolsPath)\Microsoft.CSharp.targets" />
  <Import Project="$(MSBuildExtensionsPath32)\Microsoft\VisualStudio\v10.0\SharePointTools\Microsoft.VisualStudio.SharePoint.targets" />
</Project>

Replacing Tokens for All Projects

To let MSBuild replace tokens for all projects edit C:\Program Files (x86)\MSBuild\Microsoft\VisualStudio\v10.0\SharePointTools\Microsoft.VisualStudio.SharePoint.targets – be shure to make a backup copy first. Open the editor as administrator and in the file extend the TokenReplacementFileExtensions element by adding “;asmx” like shown below.

<?xml version="1.0" encoding="utf-8"?>
<Project xmlns="http://schemas.microsoft.com/developer/msbuild/2003">
  <!-- ... -->
  <PropertyGroup>
    <TokenReplacementFileExtensions>$(TokenReplacementFileExtensions);xml;aspx;ascx;webpart;dwp;asmx</TokenReplacementFileExtensions>
  </PropertyGroup>
  <!-- ... -->
</Project>

External References

Microsoft’s documentation on replaceable parameters

What are Non-Web Parts?? I just invented that term to pool everything that is not supervised by a WebPartManager instance–most notably static Web Parts and user controls. But the more interesting question is: how do you make those things work with a ribbon?

The Server Side

While the XML defining your tabs makes it to the client as long as you installed your Non-Web Part as a feature it’s tabs will never show up. Initiating that would have been the WebPartManager’s job server side. Calling MakeTabAvailable() and MakeContextualGroupInitiallyVisible() will take care of this. Just remember that you need a reference to Web.Command.UI.dll as these methods and IsTabAvailable() are defined in SPRibbon’s base class Ribbon.

But now the tabs or rather the ContextualGroup shows up as soon as the page loads–the lack of supervision by a WePartManager making itself felt again. To prevent this you have to associate your ContextualGroup with a VisibilityContext and disable it.

Summing everything up the server side code will look like this:

protected void Page_Load(object sender, EventArgs e) {
 SPRibbon ribbon = SPRibbon.GetCurrent(this.Page);
 if (ribbon != null) {
  if (ribbon.IsTabAvailable("My.Tab") == false) {
   // Don't specify VisibilityContext here or Tab will never show!
   ribbon.MakeTabAvailable("My.Tab");
  }
  // Adding disabled VisibilityContext to ContextualGroup makes it initially invisible
  ribbon.MakeContextualGroupInitiallyVisible("My.ContextualGroup", "My.VisibilityContext");
  ribbon.DisableVisibilityContext("My.VisibilityContext");
 }
} // Page_Load()

The Client Side

While there is no way of enabling a VisibilityContext on the client side everything will be taken care of automatically when you call SelectRibbonTab(). This lonely line is the necessary client side JavaScript to show the ContextualGroup you just managed to hide:

SelectRibbonTab('My.Tab', true);

SelectRibbonTab() is defined in Init.debug.js and will also take care of loading the ribbon initially.

The last step is to decide when your ContextualGroup should be visible. Hiding it when another Web Part is selected seems to come as close as possible. Of course this isn’t a perfect solution as you don’t notice when an element outside a Web Part is selected.

Implementing this solution in your Ribbon XML to control visibility of a ContextualGroup would look like this:

<?xml version="1.0" encoding="utf-8"?>
<Elements xmlns="http://schemas.microsoft.com/sharepoint/">
 ...
  <CommandUIHandlers>
   <CommandUIHandler
    Command="My.ContextualGroup.Command"
    CommandAction=""
    EnabledScript="javascript:function isContextualGroupEnabled() {
      return SP.Ribbon.WebPartComponent.get_pageComponentIdOfActiveWebPart() === null;
     }
     isContextualGroupEnabled();"
    />
  </CommandUIHandlers>
 ...
</Elements>

SP.Ribbon.WebPartComponent is definied in SP.Ribbon.debug.js. A ContextualGroup is visible if it’s EnabledScript returns true. You would use similar code to control a tab’s visibility using the Ribbon XML or to control visibility using a page component.

Caveat: I haven’t got this to work–the tab won’t show and I don’t have the time to pursue this topic right now. But you would use the API like this:

function createMyTab() {
 debugger;
 var ribbon = SP.Ribbon.PageManager.get_instance().get_ribbon();
 if (ribbon !== null) {
  var contextualGroupIds = ribbon.get_contextualGroupIds();
  if (Array.contains(contextualGroupIds, 'My.ContextualGroup') === false) {
   ribbon.addContextualGroup('My.ContextualGroup', 'Use this ContextualGroup', 'Magenta', 'My.ContextualGroup.Command');
   // Tab object creates default Scaling object
   var tab = new CUI.Tab(ribbon, 'My.Tab', 'A Tab', 'Use this tab', 'My.Tab.Command', true, 'My.ContextualGroup', null);
   ribbon.addChildAtIndex(tab, 0);
   // CUI.GroupProperties isn't defined? CUI.Group's constructor parameters contain values already anyway
   var group = new CUI.Group(ribbon, 'My.Group', 'A Group', 'Use this group', 'My.Group.Command', null);
   tab.addChild(group);
   var layout = new CUI.Layout(ribbon, 'My.Layout', 'A Layout');
   group.addChild(layout);
   var section = new CUI.Section(ribbon, 'My.Section', 2, 'Top'); //2==OneRow
   layout.addChild(section);
   var controlProperties = new CUI.ControlProperties();
   controlProperties.Command = 'My.Button.Command';
   controlProperties.Id = 'My.ControlProperties';
   controlProperties.TemplateAlias = 'control1';
   controlProperties.ToolTipDescription = 'Use this button';
   controlProperties.ToolTipImage32by32 = '/_layouts/$Resources:core,Language;/images/formatmap32x32.png';
   controlProperties.ToolTipImage32by32Left = '-64';
   controlProperties.ToolTipImage32by32Top = '-352';
   controlProperties.ToolTipTitle = 'A Button';
   var button = new CUI.Controls.Button(ribbon, 'My.Button', controlProperties);
   var controlComponent = new CUI.ControlComponent(ribbon, 'My.ControlComponent', 'Large', button);
   var row1 = section.getRow(1);
   row1.addChild(controlComponent);
  }
  contextualGroupIds = ribbon.get_contextualGroupIds();
  if (Array.contains(contextualGroupIds, 'My.ContextualGroup')) {
   ribbon.showContextualGroup('My.ContextualGroup');
  }
 }
 SelectRibbonTab('My.Tab', true);
}

And yes–this sample contains more interesting bugs than my typos and the missing Template and command definitions . But if you are comfortable with the XML to define ribbons the API doesn’t hold many surprises other than the ControlComponent intermediary and the connection of the Layout object–at least that’s what I’ve seen so far.

Most of this is in CUI.debug.js. But the pointers to this kind of API like addChild() methods are not in classes like CUI.Tab or CUI.Group where you would look for them. Instead they are in base classes like CUI.Component.

Microsoft created themselves an infrastructure to implement class hierarchies in JavaScript. Check the calls to registerClass() near the end of CUI.debug.js to get an idea of the inheritance hierarchy. Here are some examples:

null
CUI.ContextualGroup

null
CUI.Component
CUI.RibbonComponent
CUI.Tab

null
CUI.Control
CUI.Controls.Button

null
CUI.Component
CUI.ControlComponent

null
CUI.Component
CUI.Root
CUI.Ribbon

50.000 lines of obfuscated JavaScript in CUI.debug.js, Init.debug.js, SP.debug.js, and SP.Ribbon.debug.js can be a bit overwhelming at first. Just assume the non-obfuscated identifiers mark public interface members aka the API. Happy hacking!

Getting Line Numbers in Your Stack Trace

As you probably know you will only get line numbers in your stack trace if Windows can access the respective .pdb file. But if you have GACed your assemblies there is no place arranged to store the corresponding .pdb files. This isn’t a problem if you are debugging with Visual Studio as it is smart enough to find it’s own .pdb files. But you don’t have Visual Studio on your testing machines…

While you can find outlandish attempts on the Net to GAC the .pdb files as well there’s a much simpler solution. Just add two entries to the registry under “HKEY_LOCAL_MACHINE\SYSTEM\CurrentControlSet\Control\Session Manager\Environment”:

• _NT_EXECUTABLE_IMAGE_PATH
• _NT_SYMBOL_PATH

Set both values to the directory where you plan to store your .pdb files, for example “c:\PDB-Files” and restart IIS. After doing this for the machine you use to deploy your solutions add similar entries to your WFE’s registries. Of course they will point to the original directory, for example “\\11.111.55.555\c$\PDB-Files”.

When you deploy a solution simply copy the corresponding .pdb files to the dedicated folder. This will even work for release builds as they come with .pdb files, too. But due to optimizations the line numbers will not always be correct.

Monitoring Your SharePoint Logs

When testing a solution you usually want to monitor your SharePoint logs more closely. And of course you want to watch all your WFE’s logs in one place and have everything updated in real-time.

There are various tools for this. I choose ULS Viewer (see External References) for it’s features. Here’s how to set it up to monitor all your WFE’s logs:

• Create a mapped folder for each SharePoint log directory of your WFEs.
• In ULS Viewer: select File | Open From | ULS. The “Setup the ULS Runtime Feed” window appears.
• In the “Setup the ULS Runtime Feed” window:
  • Select “Use directory location for real-time feeds”.
  • Specify one of your log directories and click OK.
• Repeat the previous three steps for all your log directories.

I decided to show each log in it’s own tab because the Server column is always empty and one wouldn’t know from which WFE an entry originated if everything was in one tab. The drawback is that filtering gets more laborious but this is compensated by using stored filters. When writing this I found that you can even save and re-load workspaces–all your tabs with all their filters and configurations. So you’ll have to configure this only once–Yay!

Unfortunately I also found that having an empty filter value makes the program crash and others found problems with non-US date formats. But even with it’s bugs and strange UI the program has too many benefits to use something else:

• Monitor multiple logs, even from different machines
• Open multiple persisted log files in one tab
• Configurable notification system
• Bookmarking
• Smart Highlight: highlights all fields that have the same value as the one your mouse is hovering over
• And of course the features you’d expect anyway like filtering, sorting, and highlighting entries

Be aware that there is another program called ULS Viewer available on CodePlex. The one I’m using is Microsoft’s own tool and they kindly released it a while ago–although unsupported. Unfortunately this means there is no source code available and it doesn’t look like there will be an update anytime soon.

External References

Enable Stack Trace Line Numbers
SharePoint 2010 ULS log viewer
ULS Viewer, for SharePoint 2010 Troubleshooting

• Visual Studio and the program to be extended load different versions of your extension
• Visual Studio 2010 uses the wrong debugger

I’ll use SharePoint and a .dll file as an example but you can substitute “SharePoint” with “program to extend” and “.dll” with your type of extension.

Visual Studio and the Program to be Extended Load Different Versions of Your Extension

Use Process Explorer (see External References section) to check from where Visual Studio (process devenv.exe) and SharePoint (one of the w3wp.exe processes or the OWSTIMER.EXE process) load your .dll file. Chances are that the locations don’t match.

One problem I found was that SharePoint loaded the correct version of the .dll file from the GAC (C:\Windows\assembly\GAC_MSIL\…) but Visual Studio loaded it from C:\Windows\assembly\temp\… which is used for uninstalling assemblies from the GAC. Re-started Visual Studio–problem solved. OWSTIMER.EXE loaded the .dll file from the wrong location, too. Killed the process (it will be re-started automatically)–problem solved.

SharePoint only: another nice twist comes from creating extensions that are used by Central Administraton and normal sites. Visual Studio will only recycle the application pool for normal sites leaving you with Central Administration using an outdated version of your .dll file. Check the timestamp in Visual Studio’s modules window and if it doesn’t match recycle Central Administration’s application pool or restart IIS.

Visual Studio 2010 Uses the Wrong Debugger

Visual Studio 2010 uses the wrong debugger–what??? Visual Studio 2010 is the first version that has two .NET debuggers at it’s disposal: one for .NET 4.0 and one for all previous versions of .NET. If you are debugging an extension Visual Studio may get it’s debugger choice wrong. A telltale sign of this scenario is an empty modules window when you are attached to the process in question. This issue will be fixed in SP1 for Visual Studio.

If you are developing for SharePoint you can use this workaround:

• If you are debugging detach from all processes.
• “Attach to Process” window: select the process you want to debug. It will probably list “Managed (v2.0…)” and “Managed (v4.0…)” as types.
• “Attach to Process” window: click “Select”. The “Select Code Type” window appears, probably with “Automatically determine the type of code to debug” selected.
• “Select Code Type” window: select “Debug these code types”, check “Managed (v2.0…)”, and click OK.
• “Attach to Process” window: click “Attach”. Your modules window shouldn’t be empty anymore and your breakpoints should work.

If it doesn’t work the first time try checking “Managed (v4.0…)”, attach (this should not work), detach, then attach again with “Managed (v2.0…)” checked.

I have also seen Process Explorer showing a process had loaded my .dll file and Visual Studio not listing it for this process. And of course the breakpoints didn’t show as solid dots but only as circles. But they worked once the respective statement was executed. So as long as the modules window isn’t empty you should be OK regarding this type of error.

Just remember to revert the setting back to “Automatically determine the type of code to debug” when you start working on a different type of program.

When working on extensions for other programms you can probably create a .config file specifying the debugger version to use. See the External References section for details.

External References

Debugging external application
GAC Temp and Tmp
Process Explorer

Trying to access your application’s web.config you’ll then usually call ConfigurationManager.OpenExeConfiguration(). But this throws an exception “Failed to resolve the site ID” because the web.config’s site doesn’t use the same application pool as the event receiver. The reason for this is of course that you use application pools to isolate applications and explicitly want this behavior.

The solution is to open web.config as a normal file–the account your application pool uses should have sufficient permissions for this. Here’s a code example:

// ...

public override void SiteDeleting(SPWebEventProperties properties) {
   string webConfigPath 
      = properties.Web.Site.WebApplication.IisSettings[SPUrlZone.Default].Path.FullName;
   XmlDocument webConfig = new XmlDocument();
   webConfig.Load(webConfigPath + "\\web.config");
   string appSettingsXPath = "configuration/appSettings/add";
   //XmlNodeList appSettings = webConfig.SelectNodes(appSettingsXPath);
   XmlNode mySetting = webConfig.SelectSingleNode(appSettingsXPath + "[@key='MyKey']");
   if (mySetting != null) {
      string s = mySetting.Attributes["value"].Value;
   }
}

Depending on your scenario it may be more appropriate to pass the value by using the feature’s properties. This is an often overlooked option.

Of course getting a wrong .config file is not limited to writing extensions for SherePoint’s Central Application but a more general problem. A Big Thank You to my colleague Matthias for the tip off!

Another oddity I found when creating a SiteDeleting event receiver was that using Debugger.Break() caused some really weird behavior. Attach to the respective w3wp process instead. At least Visual Studio 2010 doesn’t ask you anymore if you really want to attach.

The idea is to simply augment your Web Part with a Web Service and then call it’s methods from JavaScript. This demo Web Part will just display a timestamp and a URL when you press a button–you’ll have to find more interesting applications yourself.

Creating the Project

One shouldn’t have to explain this. But to promote the new Visual Web Part there is no project template in Visual Studio 2010 for the traditional Web Part.

The only benefit you get from Visual Web Parts is being able to manipulate their UI in a designer. Not very convincing as it makes your project more complex and Web Part UIs tend to be pretty simple. Of course this is a general issue and not limited to AJAX style Web Parts. And if you used SmartParts you will probably prefer Visual Web Parts.

Anyway my solution is:

• create an Empty SharePoint Project
• add your Web Part as a new item

Here is a screenshot of the final solution:

Creating the Web Service

The easy way to implement AJAX style Web Parts is to simply add the Web Service class to the Web Part–no additional DLLs needed. It could be even more easy but as Microsoft wants to educate you to use WCF services instead of the traditional Web Services there is no template for them when working on a Web Part project.

So you have to manually add a class and convert it like this. The highlighted lines make GetInfo() callable from JavaScript and the EnableSession attribute would give you access to the session state:

using System;
using System.Web.Script.Services; // Needs reference to System.Web.Extensions.dll
using System.Web.Services; // Needs reference to System.Web.Services.dll
using Microsoft.SharePoint;

namespace AjaxWP {

    [WebService(Namespace = "http://tempuri.org/")]
    [WebServiceBinding(ConformsTo = WsiProfiles.BasicProfile1_1)]
    [ScriptService]
    class AjaxWS : System.Web.Services.WebService {

        //[WebMethod(EnableSession = true)]
        [WebMethod]
        [ScriptMethod]
        public string GetInfo() {
            //throw new Exception("Just a test ...");
            string s = DateTime.Now.ToString("s")
                + ", " + SPContext.Current.Web.Url;
            return s;
        }
    }
}

Now create a one-line .asmx file like this for example in your Layouts subfolder. The class attribute contains the strong name of your assembly as Web Part assemblies are usually deployed to the GAC.

<%@ WebService Language="C#" Class="AjaxWP.AjaxWS, AjaxWP, Version=1.0.0.0, Culture=neutral, PublicKeyToken=d76004e99c897b9f" %>

Creating the Web Part

And finally the calling Web Part’s code. While it consists of nearly 100 lines it’s actually just a few simple steps:

• OnInit() makes the Web Service callable by JavaScript on the page by letting the ScriptManager create a JavaScript proxy.
• OnPreRender() generates the JavaScript. Calling Web services from JavaScript is always asynchronous and follows the same pattern:
  • Create a method that calls your Web Service’s method providing the required parameters and two callback methods.
  • Create a callback method for successful calls. It’s parameter will contain the Web Service’s response.
  • Create a callback method for error cases. It’s parameter will contain an error object. The example code has additional info.
• Call your JavaScript method. In this case the button’s OnClientClick event is responsible for this.

using System;
using System.ComponentModel;
using System.Text;
using System.Web.UI;
using System.Web.UI.WebControls;
using System.Web.UI.WebControls.WebParts;

namespace AjaxWP.AjaxWP {

    [ToolboxItemAttribute(false)]
    public class AjaxWP : WebPart {

        private Panel _infoPanel;

        protected override void CreateChildControls() {
            base.CreateChildControls();
            Button getInfoButton = new Button();
            Controls.Add(getInfoButton);
            getInfoButton.ID = "getInfoButton";
            // "return false" prevents postback
            getInfoButton.OnClientClick = "javascript:getInfo(); return false;";
            getInfoButton.Text = "Get Info";
            Panel infoPanel = new Panel();
            Controls.Add(infoPanel);
            _infoPanel = infoPanel;
            infoPanel.ID = "infoPanel";
        } // CreateChildControls()

        private void CreateJavaScript() {
            StringBuilder sb;
            string script;
            if (Page.ClientScript.IsClientScriptBlockRegistered(
                this.GetType(), this.ToString() + "ClientScript") == false) {
                sb = new StringBuilder();
                sb.Append("<script type='text/javascript'>");

                #region getInfo() function
                sb.Append("\r\n");
                sb.Append("\r\nfunction getInfo()");
                sb.Append("\r\n{");
                //sb.Append("\r\n debugger;");
                sb.Append("\r\n AjaxWP.AjaxWS.GetInfo(");
                sb.Append("\r\n  onGetInfoSuccess, onGetInfoFailure");
                sb.Append("\r\n );");
                sb.Append("\r\n}");
                #endregion getInfo()function

                #region onGetInfoFailure()function
                sb.Append("\r\n");
                sb.Append("\r\nfunction onGetInfoFailure(error)");
                sb.Append("\r\n{");
                ///sb.Append("\r\n debugger;");
                sb.Append("\r\n var stackTrace = error.get_stackTrace();");
                // If web.config <customErrors mode="On" /> this will always be
                // "There was an error processing the request.":
                sb.Append("\r\n var message = error.get_message();");
                //sb.Append("\r\n var statusCode = error.get_statusCode();");
                //sb.Append("\r\n var exceptionType = error.get_exceptionType();");
                //sb.Append("\r\n var timedout = error.get_timedOut();");
                sb.Append("\r\n alert(message);");
                sb.Append("\r\n}");
                #endregion onGetInfoFailure()function

                #region onGetInfoSuccess() function
                sb.Append("\r\n");
                sb.Append("\r\nfunction onGetInfoSuccess(result)");
                sb.Append("\r\n{");
                //sb.Append("\r\n debugger;");
                sb.Append("\r\n var infoPanel = document.getElementById('"
                    + _infoPanel.ClientID + "');");
                sb.Append("\r\n infoPanel.innerHTML = result;");
                sb.Append("\r\n}");
                #endregion onGetInfoSuccess()function

                sb.Append("</script>");
                script = sb.ToString();
                Page.ClientScript.RegisterClientScriptBlock(
                    this.GetType(), this.ToString() + "ClientScript", script);
            }
        } // CreateJavaScript()

        protected override void OnInit(EventArgs e) {
            base.OnInit(e);
            // Make Web service accessible by JavaScript
            ServiceReference sr = new ServiceReference();
            sr.Path = "_layouts/AjaxWP/AjaxWS.asmx";
            ScriptManager sm = ScriptManager.GetCurrent(Page);
            sm.Services.Add(sr);
        } // OnInit()

        protected override void OnPreRender(EventArgs e) {
            base.OnPreRender(e);
            // Create JavaScript in OnPreRender as ClientIDs are determined now
            CreateJavaScript();
        } // OnPreRender()

    }
}

That’s it. Visual Studio 2010 will take care of deploying everything to the correct location and adding the required SafeControl element to web.config. Just make shure you are Site Collection administrator of the site you specified as target site, add the Web Part to the page, and press the button.

While trying this out put a breakpoint in CreateChildControls(). It will not be hit when you press the button–no ASP.NET postback involved! Had you used an UpdatePanel instead of typing in all this JavaScript there would be an ASP.NET postback causing for example the View State to be sent around. See the MSDN article from the external references section for details and for information about how to use JSON in your Web Service.

Another noteworthy point is the value you get from SPContext.Current.Web.Url–this will always be the root Site Collection’s URL. If your Web Service’s method needs the correct URL simply pass it as a parameter.

And a bonus tip for everybody who read this to the end: as double-clicking a Web Service code file in Visual Studio generates an “Error loading workflow” you should open it by selecting “View Code” from the context menu.

External References

UpdatePanel Tips and Tricks

That’s Visual Studio 2010′s 64-bit host process to execute SharePoint commands and a new instance will be created when you press F5.

public static SPUser GetMySiteOwner(SPWeb mySite) {
 SPUser result = null;
 string mySiteUrl = mySite.Url;
 if (mySiteUrl.EndsWith("/") == false) {
  mySiteUrl += "/";
 }
 Uri mySiteUri = new Uri(mySiteUrl);
 UserProfileManager upm = new UserProfileManager(
  SPServiceContext.GetContext(mySite.Site));
 for (int i = 0; i < mySite.SiteUsers.Count; i++) {
  string loginName = mySite.SiteUsers[i].LoginName;
  if (upm.UserExists(loginName)) {
   UserProfile up = upm.GetUserProfile(loginName);
   if (up != null) {
    Uri personalUrl = new Uri(up.PersonalUrl.AbsoluteUri);
    Uri publicUrl = new Uri(up.PublicUrl.AbsoluteUri);
    if (mySiteUri.LocalPath.StartsWith(personalUrl.LocalPath)
     || mySiteUri.PathAndQuery.StartsWith(publicUrl.PathAndQuery)) {
     result = mySite.SiteUsers[i];
    }
   }
  }
 }
}

External References

• Modifying My Site Owner Security. This post has some background info on changing the MySite owner and also shows how to correct the site’s title as SharePoint has a timer job setting it to the site collection administrator’s name.

That doesn’t bother most people as they’ll just add a ContentPlaceHolder and use the page layout to fill in the Web Part zone. But that won’t work with Sharepoint 2010 team sites–those are wiki based and therefore you can’t apply page layouts.

Turns out there’s a much easier solution than using page layouts: just wrap everything in a user control. That means your user control will consist of only the XML to define the Web Part zone and your Web Part in it. In your masterpage you then reference your user control like you would reference a static Web Part–problem solved!

Disclaimer: while the above worked in my scenario there’s a reason why Microsoft doesn’t allow Web Parts in masterpages. Depending on your scenario you may have to invest additional work.

OK, some additional notes just so you didn’t follow the link to find only three paragraphs and a disclaimer:

• The ribbon caching can throw you for a loop. Instead of deleting IE’s cache manually every time you start your project add this line to your post build event command line:
  RunDll32.exe InetCpl.cpl,ClearMyTracksByProcess 8
  It will take care of those two pesky commandui.ashx?… files.
• The two commandui.ashx?… files are quite handy to check what the client actually received. The one with a qt=commandhandlers parameter should show the contents of your CommandUIHandlers element and the one with id=Ribbon.MyTabName.Tab and qt=ribbontab parameters should contain your tab definitions. Of course everything is in JASON. Searching the files in IE’s Temporary Internet Files directory is quite laborious but FireFox’s Firebug addon displays them nicely in it’s Net tab.
• Most examples show the ribbon XML being generated as a string. Don’t do that unless you have a compelling reason. A file is much easier to validate.
• Quite often you see examples using a page component–that’s a piece of object oriented JavaScript. But nobody knows how it’s really supposed to work and usually you are better off adding JavaScript to your ribbon XML or generating it in your Web Part. The page component is not mandatory. On the other hand I found the ribbon load times go up when there was a lot of JavaScript in the XML.
• To save some HTTP round-trips use image maps instead of individual files for your ribbon’s icons. You can find SharePoint’s image maps in it’s 14 hive under \TEMPLATE\LAYOUTS\<YourLcid>\IMAGES–most notably formatmap16x16.png, formatmap32x32.png, and rtecluster.png.
• If your ribbon shows up but disappears instantly chances are your EnabledScript isn’t returning true. It may seem to do so but step into the calling JavaScript where you’ll find eval() evaluating your function and probably returning ‘undefined’ because of syntactical errors.
• The ribbon infrastructure checks the activated features to determine which ribbons might show up on a page. Two consequences of this:
  • Don’t forget to activate your web part feature like I did or your ribbon will never show . An error message like 'The operation could not be completed because the Web Part is not on this page.' when calling SPLimitedWebPartManager’s GetStorageKey() or GetZoneID() while WebPartManager.WebParts contains your Web part is a telltale sign of this.
  • If your ContextualGroup has an EnabledScript attribute you’ll have to provide the referenced JavaScript even if your Web part is not on the page! See example XML below.

<!-- Providing stand-alone EnabledScript -->
<?xml version="1.0" encoding="utf-8"?>
<Elements xmlns="http://schemas.microsoft.com/sharepoint/">
 ...
  <CommandUIHandlers>
   <CommandUIHandler
    Command="Ribbon.My.ContextualGroup.Command"
    CommandAction=""
    EnabledScript="javascript:function handleMissingWebPart()
     {
      result = false;
      if (typeof isMyCommandEnabled == 'function') 
       result = isMyCommandEnabled('Ribbon.My.ContextualGroup.Command'); 
      return result;
     }
     handleMissingWebPart();"
   />
  </CommandUIHandlers>
 ...
</Elements>

Update 2010-11-07: Added note about using image maps.