SharePointers

I've found a lot of bad info on how to do this and it's not well documented so hopefully this helps someone: first create a JavaScript function so that your links aren't super long: <script type="text/javascript">             function OpenForm(absSiteUrl, siteRelFormUrl, siteRelSaveUrl)             {                         var formUrl = absSiteUrl + siteRelFormUrl;                         var saveUrl = absSiteUrl + siteRelSaveUrl;                         var formSvcUrl = absSiteUrl + "_layouts/FormServer.aspx?XsnLocation=" + formUrl;    ...

If you have MySites and a Search Center running in your farm, you may have overlooked a not-so-obvious configuration setting. When setting up MySites for a User Profile service application, your Search Center URL must point to the "Pages" folder where the Search Center publishing pages are located instead of the Search Center web URL. Otherwise, a People Search from a MySite will forward the request to to http://[searchcenter]/PeopleResults.aspx?k=searchquery (which doesn't exist) instead of http://[searchcenter]/PeopleResults.aspx?k=searchquery which is where the PeopleResults.aspx page is actually located. TLDR: Use http://[searchcenter] /Pages/ for your Search Center url in UPA MySite Settings.

I've been struggling lately with the proposed solutions for including the javascript for CommandUIHandler's CommandAction and EnabledScript attributes.  Thus far I have only seen the following examples: JavaScript directly into the attributes (messy), Including a ScriptLink command action (bad because then the script file is included in every page where the feature is activated causing bloated pages) Creating a page component (overcomplicated) Instead of all this, I created a pattern which loads the js file on the fly with javascript and keeps your ribbon development more compact (note I have JQuery loaded in the master page, if you don't have this then you'll have to either load jquery dynamically or reference the elements without JQuery): <commanduihandler    CommandAction="javascript:                              ...

This is a command that will quickly let you know which w3wp.exe you should be debugging on Server 2008 (IIS7, since the App Pool isn't listed in Visual Studio's 'attach to process' dialog). go to \Windows\System32\inetsrv and run "appcmd list wp" and you'll get a list that associates App Pool and PID

If you want to use the SPWeb.Files.Add() method that allows you to pass in a HashTable of metadata for the document, you will need to use the internal name of the metadata field, not the display name.   Here's a PowerShell script to get that for you quickly: $web = Get-SPWeb http://intranet.sharepointdev.com $list = $web.Lists["Shared Documents"] foreach($item in $list.Items) {     $file = $item.File     #output all the SPFile property names     foreach($key in $file.Properties.Keys)     {         write-host("File Key: " + $key)     }         #output the associated item's fields     foreach($field in $item.Fields)     {         write-host("Item Field: " + $field.InternalName)     }     break; }

There are several components/processes that are involved in the execution of sandboxed solutions.    For a developer, it's critical to understand how coding/debugging various types of solutions changes based on the type of solution.  Here's how the execution goes in a nutshell: When the sandboxed code is called, the Execution Manager (running in the w3wp.exe) makes a call to an application server running the User Code Service (SPUCHostService.exe).  The User Code Service then tells the Worker Service  (SPUCWorkerProcess.exe) to load the sandbox code.  The code is then verified to ensure only calls to the subset of the API allowed by the Sandbox API are called.  The worker process then executes the code against the Worker Proxy (SPUCWorkerProcessProxy.exe) which has full access to the SharePoint API (but the sandboxed code has already been disallowed from using the non-subset portion of the API by the Worker Service). When debugging sandboxed solution...

I've been spending a lot of time lately working with SharePoint 2010's "Refinement Panel" web part. This capability was available only as a third-party add-in or Codeplex solution back in the MOSS days, but I was very excited to learn that it had been incorporated natively in 2010. It's frustrating, however, to have to constantly explain to customers that Refinement goes only 500 results deep unless you have FAST, which requires Enterprise CALs. The standard search provides a Refinement Panel that defaults to an Accuracy Index of 50 and goes to a maximum of 500. This means that the Refinement capability will only work for the first 50-500 results returned. So if a company is stuck with Standard CALs and no FAST, how do they get around this limitation? Surely a mid to large size company will have many more than 500 list items, documents and other artifacts returned in a global search of all content sources, including SharePoint sites, File Shares, etc. So in our hy...