Here’s the URL to the built-in document set downloader page: {SiteUrl}/_layouts/DocSetExport.aspx?List={ListId}&ID={ItemId}.  It takes in the GUID of the list and the ID of the document set.  Here’s an example: https://sharepoint2010/sites/docman/_layouts/DocSetExport.aspx?List={4E2D11F5-7500-476A-B001-62A7BF92FD50}&ID=10

Adding a Custom Action to the Document Set List Item Menu using SharePoint Designer

To add a custom action, open the site in SharePoint Designer and navigate to the document set list.  Add a new list item menu custom action:

Provide a Name, Description, and Navigate to URL:

Save the custom action, and test it:

I want to mention that there is a drawback to this approach.  The custom action will show up for every list item, not just the document set.  The list item menu will appear on documents in the document set as well:

Adding a Custom Action to the Document Set Ribbon using SharePoint Designer

We can also use SharePoint Designer to add a button to the document set ribbon, but the user experience isn’t ideal.  You’re better off creating this custom action in a sandboxed (or farm) solution.  The reason for this is that custom actions created in SharePoint Designer operate on a list item, so the user has to select a list item before the ribbon button lights up to zip and download the document set.  Understanding the limitations, here’s how to do it:

Add a new view ribbon custom action:

Enter a Name and Description as before, but this time use JavaScript for the custom action.  We need script to get the ID of the document set rather than the ID of the selected item.  Enter the following for the Navigate to URL:

javascript:function getQS(key){var regex=new RegExp('[\\?&]'+key+'=([^&#]*)');var qs=regex.exec(window.location.href);return qs[1];}var url='{SiteUrl}/_layouts/DocSetExport.aspx?List={ListId}&ID='+getQS("ID");window.location.href=url;

Now when you select a document the zip and download button lights up:

Adding Custom Actions to the Document Set List Item Menu using a Sandboxed Solution

Next, I’ll show you how to create a sandboxed solution that provides a better user experience and is reusable across sites.  The solution deploys both the list item and document set ribbon and scopes the custom action to just the document set content type.  To get started, create a new empty SharePoint project in Visual Studio 2010.  Add a feature and name it DocSetDownload.  Add a new Elements item named CustomActions.  Add the following to the Elements.xml file

<Elements xmlns="https://schemas.microsoft.com/sharepoint/">
  <CustomAction
    Id="DocSetDownload.Ribbon"
    Title="Zip and Download"
    Description="Zip all documents in this document set and download."
    RegistrationType="ContentType"
    RegistrationId="0x0120D520"
    Location="CommandUI.Ribbon">
    <CommandUIExtension>
      <CommandUIDefinitions>
        <CommandUIDefinition
          Location="Ribbon.ManageDocumentSet.MDS.Share.Controls._children">
          <Button
            Id="Ribbon.ManageDocumentSet.MDS.Share.Controls.DocSetDownload"
            Sequence="20"
            Command="Ribbon.ManageDocumentSet.MDS.Share.DocSetDownload"
            Alt="Zip and Download"
            Image16by16="images/DocSetDownload16x16.png"
            Image32by32="images/DocSetDownload32x32.png"
            LabelText="Zip and Download"
            ToolTipTitle="Zip and Download"
            ToolTipDescription="Zip all documents in this document set and download."
            TemplateAlias="o1" />
        </CommandUIDefinition>
      </CommandUIDefinitions>
      <CommandUIHandlers>
        <CommandUIHandler
          Command="Ribbon.ManageDocumentSet.MDS.Share.DocSetDownload"
          EnabledScript="true"
          CommandAction="javascript:
          function getQS(key){
            var regex=new RegExp('[\\?&amp;]'+key+'=([^&amp;#]*)');
            var qs=regex.exec(window.location.href);
            return qs[1];
          }
          var url='{SiteUrl}/_layouts/DocSetExport.aspx?List={ListId}&amp;ID='+getQS('ID');
          window.location.href=url;
          " />
      </CommandUIHandlers>
    </CommandUIExtension>
  </CustomAction>
  <CustomAction
    Id="DocSetDownload.EditControlBlock"
    Title="Zip and Download"
    Description="Zip all documents in this document set and download."
    RegistrationType="ContentType"
    RegistrationId="0x0120D520"
    Location="EditControlBlock">
    <UrlAction Url="{SiteUrl}/_layouts/DocSetExport.aspx?List={ListId}&amp;ID={ItemId}" />
  </CustomAction>
</Elements>

Next, add a Module item named images to the project and add the custom images for the ribbon:

Deploy and test the solution.  You’ll see the custom action on the ribbon:

The custom action will also appear on the list item menu:

Download the sandboxed solution source Download the wsp file.

Additional Resources

SharePoint 2010 ECM Code Sample: Document Sets Ribbon and Export

A Document Set is a container for multiple documents and provides the ability to treat the set as a single unit and even share properties from the container across all documents.  This feature is very useful for processes where there is a “packet” of documents that move through a lifecycle such as a loan application, or in this example, a project going through an engineering process.  The packet has shared information such as “Project Name,” or “Project Type,” as well as details about what types of documents go into the packet.  In SharePoint, this is is implemented as a Document Set template that has information about the document content types it is allowed to contain.  Rather than talking about it, let me show you:

In this example, I created a “Project Document Set” content type that inherits from “Document Set.”  It has columns for the Project Name, Description and the Project Type.  I’ve also defined an initial set of content types for the types of documents that the organization produces.  I started with a base content type called “Deliverable,” and created several content types that inherit from it:

Now let’s edit the Document Set settings for the Project Document Set content type.  The first setting is “Allowed Content Types.”  This enables you to specify what types of documents can go into the set.  I’ll add an initial list of deliverables.  Everything seems to be going fine so far, but notice that the list on the right is already not in alphabetic order, but rather is in the order in which content types are added:

Next I’ll create a new Project Document set and add some documents to it.  Notice that when I upload a document and edit the document properties, the Content Type drop down is in the same order as the Document set allowed content types list:

In addition, Content Types are in the same order on the New Document ribbon button:

You could manually modify the content type order for each document set by hand by selecting each document set in the library and selecting “Change New Button Order” on the list item menu. 

Although you can change the content type order for a single document set, all new Document Sets content types will have the original content type order.  Another way you could try to solve this problem is to go to the Document Set settings page and remove all the content types and re-add them in alphabetical order.  You may, however, encounter an error that the content type is in use:

Even if you don’t have the content type in use issue, imagine if you had 125 allowed content types and you needed to manually re-order them.  When the 126th content type is added, you’d have to remove and re-add them all again.  What a pain!  It would be nice if the UI had an up, down and a sort alphabetically button, but since we don’t have that in this version, I have another solution: PowerShell.

This script uses the object model to remove all content types from the Document Set template, sort them, and then re-add them.  It will also update all document sets in one library to use the new content type ordering.

<#
This script will sort the allowed content types for a document set
Example: .\Sort-DocumentSetContentTypes.ps1 https://contoso.com/sites/docman "Project Document Set" "Project Documents"
#>
param
(
       [string]$siteUrl = $(throw "Site URL is required"),
       [string]$docSetContentTypeName = $(throw "Document set content type name is required"),
       [string]$listToUpdate = $(throw "The name of the list to update existing document sets")
)
$web = Get-SPWeb $siteUrl
$dsct = $web.ContentTypes[$docSetContentTypeName]
$dst = [Microsoft.Office.DocumentManagement.DocumentSets.DocumentSetTemplate]::GetDocumentSetTemplate($dsct)
$ctById = @{}
foreach($ctId in $dst.AllowedContentTypes)
{
       $ct = $web.ContentTypes[$ctId]
       $ctById.Add($ctId, $ct)
}
$sorted = ($ctById.Values | Sort Name)
$dst.AllowedContentTypes.Clear()
foreach($ct in $sorted)
{
       $dst.AllowedContentTypes.Add($ct.Id)
}
$dst.Update($true)
#update all document sets
$web.Dispose()
$web = Get-SPWeb $siteUrl
$list = $web.Lists[$listToUpdate]
foreach($folder in $list.RootFolder.Subfolders)
{
       if($folder.Item.ContentType.Name -eq $dsct.Name)
       {
              Write-Host "Updating allowed content types for existing document set" $folder.Name
              $docSet = [Microsoft.Office.DocumentManagement.DocumentSets.DocumentSet]::GetDocumentSet($folder)
              # this gets rid of the "Content types have been added gold bar"
              $docSet.Provision()
       }
}

Download PowerShell Script

It’s good to have a plan.  Although my initial goal was to rename the databases with the GUIDs, I soon realized that I needed a naming standard so I knew what to rename the databases to.  I wanted an approach that would accommodate multiple farms (2007 or 2010), multiple organizations, and enable you to easily identify what belongs to what.  It was also important to me that the databases sorted nicely.  After several iterations, here is the naming standard I arrived at:

Technology_Organization_Scope_DatabaseType

Here are some examples:

SPS2010_Contoso_Intranet_Content
SPS2010_Contoso_Intranet_ProjectService_Archive
SPS2010_Contoso_Intranet_ProjectService_Content
SPS2010_Contoso_Intranet_ProjectService_Draft
SPS2010_Contoso_Intranet_ProjectService_Published
SPS2010_Contoso_Intranet_ProjectService_Reporting
SPS2010_Contoso_CentralAdministration_Content
SPS2010_Contoso_Farm_BDCService
SPS2010_Contoso_Farm_Config
SPS2010_Contoso_Farm_ManagedMetadataService
SPS2010_Contoso_Farm_PowerPointService
SPS2010_Contoso_Farm_ProfileService_Profile
SPS2010_Contoso_Farm_ProfileService_Social
SPS2010_Contoso_Farm_ProfileService_Sync
SPS2010_Contoso_Farm_StateService
SPS2010_Contoso_Farm_SessionStateService
SPS2010_Contoso_Farm_SecureStoreService
SPS2010_Contoso_Sales_Content
SPS2010_NorthWind_Farm_Config
SPS2010_NorthWind_Intranet_Content

Now for some detail on each component of the naming standard.

Technology. Required.  Must be one of the following:

• SPS2010 (SharePoint Server)
• SPF2010 (SharePoint Foundation)

Organization. Required.  This is especially important when multiple organizations are on a shared infrastructure. Examples

• Contoso
• Northwind

Scope. Required. Typically farm or sub organization. Examples:

• Farm (such as config database or default service application databases)
• Sales
• Marketing

Database Type.  Required.  Must be one of the following:

• Config
• Content
• BDCService
• ManagedMetadataService
• PerformancePointService
• ProfileService_Profile
• ProfileService_Sync
• ProfileService_Social
• ProjectService_Content
• ProjectService_Draft
• ProjectService_Published
• ProjectService_Archive
• ProjectService_Reporting
• SearchService
• SearchService_Crawl
• SearchService_Property
• SecureStoreService
• SessionStateService
• StateService
• SubscriptionSettings
• UsageService
• WebAnalyticsService_Staging
• WebAnalyticsService_Reporting
• WordAutomationService

If you are creating a new farm, it’s fairly easy to establish the standard up front.  For most, however, the decision to implement a naming standard is made after the farm is created.  Here’s some recommended reading on the topic of creating and renaming SharePoint databases:

• Install SharePoint Foundation 2010 by using Windows PowerShell
• Rename or move service application databases
• Getting rid of GUIDs in SharePoint 2010 database names
• Rename the SharePoint 2010 PerformancePoint database to remove the GUID

For example, if you developed a sandboxed web part that displayed data from a list, it would perform a SharePoint database query each time it loads.  20 database queries = 1 resource point, so if the web part was displayed 20 times, the site collection would have used 1 resource point.  The default site collection maximum is 300 points, so the web part could be displayed 6,000 times in a 24 hour period; after that, the sandbox is turned off until a timer job resets it.  It's important to understand is that resource quotas can be exceeded through high usage and is not necessarily an indicator of poorly written code.  Quotas may need to be adjusted based on usage patterns, and the 300 point default is not a one-size fits all setting.  Another important point is that resource usage is calculated by timer jobs, so it is possible for the quota to be exceeded until the timer jobs run.  Sandboxed code will not be terminated mid-execution. 

Create Resource Quota Template

To demonstrate resource quotas, we'll create a resource quota template that only allows 1 resource point per day and create a sandbox web part that throws exceptions.  First, we must create a template.  Go to Central Administration > Application Management > Specify Quota Templates.  Select Create a new quota template and provide a name.  Set the maximum usage per day to 1 point:

Next, the template must be associated to a site collection.  Navigate to Application Management > Configure Quotas and Locks and select the site collection and the quota template:

Create Sandboxed Web Part

Create a sandbox solution with a web part that throws an unhandled exception, for example:

Add the web part to a page.  Now we know that 3 unhandled exceptions is the limit, so click the exception button 3 times.

Since we configured the site collection to use a maximum of 1 resource point per day, you might expect that when you clicked the button a 4th time the execution would be blocked, but usage is calculated by timer jobs.  If you open the solution gallery, you'll see that no resource points have been used:

Execute Resource Usage Timer Jobs

Next, we'll manually run the timer jobs to calculate resource usage.  Navigate to Monitoring > Review Job Definitions, and you'll find 3 timer jobs for each web application: 

First, run the usage log processing job for the site collection by clicking "Run Now":

Next, run the usage update job for the site collection:

Return to the solution gallery and you'll notice the daily usage has been updated.  The site collection sandbox has also been turned off since we used 1 resource point.

When the sandbox has been turned off, you'll see the following message when you access the page containing the sandboxed web part:

To reset, run the Solution Daily Resource Usage Update timer job: 

Summary

In this post, I demonstrated sandboxed solution resource quotas and what happens when the quota is exceeded.  The main purpose of resource quotas is to limit the risk that custom code will negatively impact the server farm.  Since custom code is the leading cause of support calls, sandboxed solutions and resource quotas provide a measure of confidence not afforded by SharePoint 2007.

References

• Plan for Sandbox Solutions

function DeveloperDashboardSection(sectionId, sectionTitle) {
    this.Title = sectionTitle;
    this.Id = sectionId;
}

DeveloperDashboardSection.prototype = {

    Id: '',
    Title: '',
   
    DeveloperDashboardVisible: function() {
        return$('DeveloperDashboard').length;
    },

    EnsureSection: function() {
        var section = $('#'+ this.Id);
        if(!section.length) {
            var sectionHtml = "<table id='"+ this.Id + "' width='49%'><tbody><tr><th colspan='2'>"+ this.Title + "</th></tr></tbody></table>";
            $('#CurrentScopeValues').append(sectionHtml);
        }
    },

    AddEntry: function(context, message) {
        if(!this.DeveloperDashboardVisible) return;
        this.EnsureSection();
        var entryHtml = "<tr><td nowrap='nowrap'><span>"+ context + "</span></td><td nowrap='nowrap'><span>"+ message + "</span></td></tr>";
        $('#'+ this.Id).append(entryHtml);
    }
};

To use the script, create an instance of the DeveloperDashboardSection and use the instance throughout your code to trace custom messages to the Dashboard:

var theSection = new DeveloperDashboardSection('sampleId', 'Custom Section');
theSection.AddEntry('someMethod()', 'The method was called');

The messages will appear on the Developer Dashboard in it’s own section:

When the Dashboard is not visible, the tracing calls are benign.

Naming Convention

Here is the naming convention I recommend for SharePoint 2007:

SharePoint_[Farm Name]_[Database Type]_[Name] where database type is one of the following:

• Config
• Content
• WSSSearch
• SSP
• SSPSearch

For example, the AdventureWorks MOSS 2007 Enterprise Intranet farm would have the following databases:

What I like about this naming convention is that the databases sort nicely.  On a shared SQL Server, the SharePoint databases are separated from other application databases.  Within SharePoint, each farm’s databases are together.  Within each farm, the database types are together, and finally, a meaningful name makes it easy to determine which area it belongs to.

Implementing the Naming Convention

The best way to ensure consistency is to script configuration changes.  I use PowerShell to tear down and build up my development environment, and I use the same approach to make changes to production servers.  In a future post, I will provide a sample, but essentially, I create a script that takes an environment-specific XML configuration file as a parameter.  For example:

Provision-Farm.ps1 johnpowell.development.xml

If you are lucky and brilliant enough to have a naming convention in place before the farm has been configured, it is much easier to implement the database naming convention.  Implementing a standard after the fact will require additional steps.  So let’s suppose you just installed the SharePoint bits and are ready to configure SharePoint.  Stop!  Rather than use the GUI, use PSConfig from the command line.  This enables you to control the Central Administration content database name.  For example, to create the configuration and CA database, use the following command:

psconfig.exe -cmd configdb -create –server sqlcluster.aw.com -database SharePoint_AWIntranet_Config -user svc-sp-aw-farm -password pass@word1 -admincontentdatabase SharePoint_AWIntranet_Content_CA

But what if you have an existing farm?  In that case, this post describes how to rename the Central Administration content database and this post outlines the procedure for renaming other content databases.

Conclusion

It is good practice to have a database naming convention, and to define and document it during the planning phase.  Although the SharePoint administrative interfaces do not enforce a database naming convention, with a little planning and governance you can implement a standard.  Once a standard is defined, scripting configuration changes is the best way to ensure they are implemented consistently.  For example, you could have a script Create-WebApplication.ps1 that takes a few parameters and implements your naming convention.  SharePoint 2010 has significantly more databases that 2007, making database naming even more important.  So here are your “go dos:”

• Define and document a database naming standard
• Create scripts to implement your standards
• Evaluate existing farms against your standards, and create a plan to rename them

• \14\Template\Features\<Feature Name>\Resources\
• \14\Resources\
• \14\Config\Resources\
• <Virtual Directory>\App_GlobalResources\ (note: resources files from \14\Config\Resources are copied here when provisioned)

Resources files follow a naming convention that consists of a base name such as “HelloLocalization.resx” and culture-specific resources such as “HelloLocalization.es-ES.resx.”  In SharePoint, these files must be in a particular location depending on usage.  In this walkthrough, I’ll show you how to create a “centralized” resources files that will be stored in 14\Resources.  My preference is to store custom files in as few locations as possible within the SharePoint hive.  I have also found that certain resources cannot be accessed from certain locations.  So with that in mind, let’s get started:

Since we are deploying to 14\Resources, we need to add a mapped folder.  Select Add > SharePoint Mapped Folder…

Select the Resources folder:

In the solution, delete the subfolder that was created in the Resources folder.  Next, right-click on the mapped folder and select Add New Item.  In the Search Installed Templates search box, type Resources to select the Resources file template.  Rename the resources file to something unique to your feature:

Set the Build Action to Content for the resources file:

Add your localized strings to the resource file:

For each feature, set the Default Resource File to the resource file name.  This enables you to reference a resource without fully qualifying it:

Optional: you can hide a feature when localized resources are not available for it by setting the Require Resources setting to True:

Now you can use the localized strings throughout your feature such as in the feature title and description:

When deployed, the feature appears like this in Site Collection Features:

The resources can also be used in the .webpart file:

<?xml version="1.0" encoding="utf-8"?>
<webParts>
  <webPart xmlns="https://schemas.microsoft.com/WebPart/v3">
    <metaData>
      <type name="HelloLocalization.LocalizedWebPart.LocalizedWebPart, $SharePoint.Project.AssemblyFullName$" />
      <importErrorMessage>$Resources:core,ImportErrorMessage;</importErrorMessage>
    </metaData>
    <data>
      <properties>
        <property name="Title" type="string">$Resources:HelloLocalization,WebPartTitle</property>
        <property name="Description" type="string">$Resources:HelloLocalization,WebPartDescription</property>
      </properties>
    </data>
  </webPart>
</webParts>

Which appears like this in the Web Part Gallery:

When you add the web part to a page, it appears like this:

The localized resources can also be used in the web part:

protected void Page_Load(object sender, EventArgs e)
{
    var lang = SPContext.Current.Web != null ? SPContext.Current.Web.Language : 1033;
    webPartMessage.Text = SPUtility.GetLocalizedString(
        "$Resources:WebPartMessage", 
        "HelloLocalization", 
        lang);

}

Which appears like this when added to a page:

To support a different culture, copy the resources file, and rename it to [ResourcesFileName].[Culture].resx.  For example, to create a Spanish (Spain) resources file:

Make the culture-specific changes to the resources strings:

If the language pack is installed on the SharePoint server, and the site has been created using that language, the resources file will be used:

For completeness, you should also be aware of the Visual Studio 2010 Feature Resources feature.  When you select Add Feature Resource...:

you are prompted for the culture, and the appropriately named resource file is created automatically:

Conclusion

In this walkthrough, I showed you how to localize a SharePoint 2010 feature.  Even if you aren’t targeting multiple languages, in my opinion it’s good practice to store resources outside of your compiled code.  I hope you found this useful, and your feedback is welcomed!

Additional Resources

• SharePoint v3 Localized Resources
• SharePoint Localization Tips and Tricks
• Deploying resource files across a farm

• Extract / copy SharePoint setup files to your computer
• Edit files\setup\config.xml and add the AllowWindowsClientInstall = TRUE setting
• Manually install prerequisites
• Enable Windows features (via command line)
• Install SharePoint (standalone), but do not run the configuration wizard
• Install SQL Server 2008 CU 2
• Run SharePoint configuration wizard

Full details can be found on the MSDN article, Setting Up the Development Environment for SharePoint Server.

• Off (default): The dashboard is not displayed, and there is no UI element to turn it on
• On: The dashboard is displayed, and there is no UI element to turn it off:

• OnDemand: A UI element enables you to turn it on or off

There are a few ways to set the developer dashboard level.  One option is to use stsadm –o setproperty –pn developer-dashboard –pv “On”, but in this article, I’ll show you how to control the dashboard through the object model using PowerShell. 

To configure the dashboard, use the SPWebService.ContentService object to set properties on the SPDeveloperDashboardSettings class.  Here is the PowerShell script to set the level:

param($level = $(throw "level is required.  Level is On, Off or OnDemand"))

# import assemblies
[void][System.Reflection.Assembly]::LoadWithPartialName("Microsoft.SharePoint")
[void][System.Reflection.Assembly]::LoadWithPartialName("Microsoft.SharePoint.Administration")

# set the level
$contentService = [Microsoft.SharePoint.Administration.SPWebService]::ContentService
$contentService.DeveloperDashboardSettings.DisplayLevel = ([Enum]::Parse([Microsoft.SharePoint.Administration.SPDeveloperDashboardLevel], $level))
$contentService.DeveloperDashboardSettings.Update()

Write-Host ("Developer Dashboard Level: " + $contentService.DeveloperDashboardSettings.DisplayLevel)

Here is a complimentary script to view the current settings:

# import assemblies
[void][System.Reflection.Assembly]::LoadWithPartialName("Microsoft.SharePoint")
[void][System.Reflection.Assembly]::LoadWithPartialName("Microsoft.SharePoint.Administration")

# get the level
$contentService = [Microsoft.SharePoint.Administration.SPWebService]::ContentService
Write-Host $contentService.DeveloperDashboardSettings.DisplayLevel

When VSEWSS packages your solution, it uses reflection to enumerate the packaged assemblies.  It works fine until it encounters an assembly that implements an interface that is defined in another assembly as is often the case in the Microsoft.Practices.* assemblies.  I am unsure of exactly why, but the extensions are unable to resolve the dependent assemblies.  To work around the issue, you can copy the dependent assemblies to the GAC, but I don’t think this is the optimal solution and doing so will cause pain during development and debugging.  Another option is to copy the dependent assemblies to the VSEWSS service bin directory post build.  After trying this for awhile, and maintaining the script, I decided it would be much simpler to just copy all assemblies in my solution to the VSEWSS service bin directory on post build.  Here is the script:

@rem======================================================================
@rem
@rem    This script copies assemblies to the VSEWSS bin directory
@rem    to eliminate the packaging type load exception that occurs
@rem    when an interface is defined in a separate assembly.
@rem    
@rem    usage call $(ProjectDir)Scripts/CopyAssembliesToVSEWSSBin.bat $(TargetDir)
@rem
@rem======================================================================

@echo off

@echo ========== Locating VSEWSS bin directory ==========
@set vsewssbin=%programfiles%\Microsoft SharePoint Developer Tools 9.0\svc\bin
if not exist "%vsewssbin%" set vsewssbin=%ProgramW6432%\Microsoft SharePoint Developer Tools 9.0\svc\bin
@echo VSEWSS bin: %vsewssbin%

@echo ========== Copying assemblies to VSEWSS bin directory ==========
@xcopy "%1*.dll" "%vsewssbin%" /R /Y

To use the script, create a bat file in your project and call it from a post build event. It does take 64-bit installations into account, and it will also work on your Team Build server.