When developing JavaScript solutions, I like to provide a tracing mechanism that can be turned on and off to aid debugging.  The IE Developer Tools, debugger and Fiddler are very robust debugging tools, but they don’t enable client script code to trace custom messages to a “log” that can be reviewed by developers.  The SharePoint 2010 Developer Dashboard is designed for server-side tracing, but it can also be used for client-side trace messages.  The approach is simple: tracing code in your client script appends html to the Developer Dashboard when the Dashboard is visible.  Here is the JavaScript (note this version depends on jQuery):

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.

In this walkthrough, I’ll show you how to create a SharePoint 2010 localized feature using Visual Studio 2010.  The basic mechanics of localizing a SharePoint 2010 feature are the same as localizing a SharePoint 2007 feature, and is well documented.  If you are unfamiliar with localization in SharePoint, please see Additional Resources at the end of this article.  In a nutshell, localized resources are stored in Resources (.resx) files, and in SharePoint exist in one of the following locations:

• \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="http://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

The SharePoint 2010 developer dashboard has three display levels (see SPDeveloperDashboardLevel Enumeration.):

• 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

In a previous post, I provided a walkthrough for automating builds for VSEWSS 1.3 projects.  The script I used was based on the SharePoint Guidance Drop 11, and after using it, I felt it could be simplified.  I’m a proponent of implementing the “simplest possible thing that will work,” and the following build script contains the minimal functionality needed to automate the building and packaging of your SharePoint solutions.

<?xml version="1.0" encoding="utf-8"?>
<Project xmlns="http://schemas.microsoft.com/developer/msbuild/2003" ToolsVersion="3.5">

  <Import Project="$(MSBuildExtensionsPath)\Microsoft\VisualStudio\TeamBuild\Microsoft.TeamFoundation.Build.targets" />

  <ProjectExtensions>
    <ProjectFileVersion>2</ProjectFileVersion>
  </ProjectExtensions>

  <PropertyGroup>
    <RunTest>false</RunTest>
    <RunCodeAnalysis>Never</RunCodeAnalysis>
    <SkipWorkItemCreation>true</SkipWorkItemCreation>
  </PropertyGroup>

  <PropertyGroup>
    <ContosoSolutionDir>c:\NightlyBuild\main\</ContosoSolutionDir>
    <ContosoSolutionName>Contoso.sln</ContosoSolutionName>
    <ContosoWSPName>Contoso.Deployment.wsp</ContosoWSPName>
    <ContosoDeploymentProjDir>c:\NightlyBuild\main\Contoso.Deployment\</ContosoDeploymentProjDir>
    <IDEPath>C:\Program Files\Microsoft Visual Studio 9.0\Common7\IDE\</IDEPath>
  </PropertyGroup>
  
  <ItemGroup>
    <SolutionToBuild Include="$(BuildProjectFolderPath)/../../main/Contoso.sln">
    </SolutionToBuild>
  </ItemGroup>

  <ItemGroup>
    <ConfigurationToBuild Include="Debug|Any CPU">
      <FlavorToBuild>Debug</FlavorToBuild>
      <PlatformToBuild>Any CPU</PlatformToBuild>
    </ConfigurationToBuild>
  </ItemGroup>

  <Target Name="AfterCompile">
    
    <!-- The extensions modify files in the pkg directory, so those files cannot read only-->
    <BuildStep TeamFoundationServerUrl="$(TeamFoundationServerUrl)" BuildUri="$(BuildUri)" Message="Making the pkg directory editable.">
      <Output TaskParameter="Id" PropertyName="StepId" />
    </BuildStep>
    <Exec Command="attrib -R &quot;$(ContosoDeploymentProjDir)pkg\*.*&quot; /S /D" />
    <BuildStep TeamFoundationServerUrl="$(TeamFoundationServerUrl)" BuildUri="$(BuildUri)" Id="$(StepId)" Status="Succeeded" />

    <!-- Build using /package switch  -->
    <BuildStep TeamFoundationServerUrl="$(TeamFoundationServerUrl)" BuildUri="$(BuildUri)" Message="Packaging wsp.">
      <Output TaskParameter="Id" PropertyName="StepId" />
    </BuildStep>
    <Exec Command="&quot;$(IDEPath)devenv&quot; &quot;$(ContosoSolutionDir)$(ContosoSolutionName)&quot; /Deploy debug /Package" />
    <BuildStep TeamFoundationServerUrl="$(TeamFoundationServerUrl)" BuildUri="$(BuildUri)" Id="$(StepId)" Status="Succeeded" />

    <!-- Copy package to drop folder -->
    <BuildStep TeamFoundationServerUrl="$(TeamFoundationServerUrl)" BuildUri="$(BuildUri)" Message="Copying wsp to drop folder.">
      <Output TaskParameter="Id" PropertyName="StepId" />
    </BuildStep>
    <Copy SourceFiles="$(ContosoDeploymentProjDir)bin\debug\$(ContosoWSPName)" DestinationFolder="$(DropLocation)\$(BuildNumber)" />
    <Copy SourceFiles="$(ContosoDeploymentProjDir)bin\debug\setup.bat" DestinationFolder="$(DropLocation)\$(BuildNumber)" />
    <BuildStep TeamFoundationServerUrl="$(TeamFoundationServerUrl)" BuildUri="$(BuildUri)" Id="$(StepId)" Status="Succeeded" />

  </Target>
  
</Project>

In this walkthrough, I’ll demonstrate how to achieve automated builds and continuous integration by creating a build script for VSEWSS 1.3 solutions.  The patterns and practices SharePoint Guidance  (11 drop) contains an example build script that this article is based on, but I found some issues with it in practice that I’d like to share.  Before we get started, I’d like to talk about the design of the extensions and some of the problems you may encounter with them. 

VSEWSS 1.3 stores information used to build the wsp file in a directory named “pkg” that is not included in the project.  This works fine for individual development on a single machine, but not so well for team development and build automation.  The pkg directory must be manually included in the project so files needed to build the wsp are included in source control.  If you forget to do this, your teammates won’t be able to build the wsp, and you risk losing deployment configuration.  Furthermore, if you later add a new feature, you also have manually add the new feature subdirectory to the project.  In addition to storing configuration information, the pkg directory is also where solution files (feature.xml for example) are automatically generated.  When you package the wsp (or refresh in the wsp view), the files in the pkg directory must be checked out to be re-generated.  This also causes problems on the build server because the files in the pkg directory are read-only because they are checked into source control.  An improved design would be to store wsp configuration information in a folder/file that is part of the project and use the pkg directory only for generating packages based on the wsp configuration files.  So now that you are aware of some of the team development “gotchas” with VSEWSS 1.3, I’ll show you, step-by-step, how to configure automated builds.

If you just want to see the build script, get it here.  Update: get a simplified build script here.

If you have not installed TFS Build, you will need to install it using the TFS installation media.  You will also need to configure a service account such as TFSBuild, and add the account to the TFS server group Team Foundation Licensed Users and the Team Project(s) group Build Services.

To get started, configure the build agent.  In the team project select Builds > Manage Build Agents…

Enter the build agent properties for your build server

Create a new build definition by selecting Builds > New Build Definition…

Enter a name for the build definition

Configure the workspace.  Note: all files in the source control folder will be downloaded to the local folder you specify, so be sure the location you specify has enough free space

Create the project file (TFSBuild.proj) by selecting the version control folder where you want it stored and selecting Create…

Select the Visual Studio solution to build and click Next

Select the configuration(s) to build and click Next

If you want to run unit tests or code analysis during the build, configure it and click Finish

Now that the project file is created, click OK

Configure how many builds you would like to retain and click OK.  Note: you should at least keep the latest of failed or partially succeeded builds or the build log file you need to troubleshoot will be deleted

Enter a share where the build files will be dropped and click OK

Configure what triggers the build, either manually, on a schedule or when files are checked in (continuous integration)

Test the build by highlighting the build definition and selecting Queue New Build…

Click Queue

At this point you should have a working build, but it doesn’t package the wsp file yet

Next, we’ll modify the build script to package the wsp file.  The build steps are as follows:

1. Clean up any workspaces / files left by the previous build packaging
2. Build the Visual Studio solution
3. Delete the workspace that was created by the build
4. Create a workspace for the wsp packaging build
5. Open a second instance of the IDE and package the solution using the /package switch
6. Copy the wsp to the drop folder

In addition to this process, a nice to have is to display the packaging steps in the GUI, so we’ll use the BuildStep task to accomplish that

To get started, get the latest version of the Team Build Types folder

Check out the TFSBuild.proj file.  Note: when developing the build script, you will have to check it out to work on it, and check it back in to test it

Add the custom tasks used by the build.  Although we could accomplish what we need to using TF commands, these tasks are installed with TFS and work well

<Project DefaultTargets="DesktopBuild" xmlns="http://schemas.microsoft.com/developer/msbuild/2003" ToolsVersion="3.5">

  <!-- These tasks are used by the Team Build process defined in this file -->
  <UsingTask TaskName="Microsoft.TeamFoundation.Build.Tasks.DeleteWorkspaceTask"
           AssemblyFile="$(TeamBuildRefPath)\Microsoft.TeamFoundation.Build.Tasks.VersionControl.dll" />
  <UsingTask TaskName="Microsoft.TeamFoundation.Build.Tasks.CreateWorkspaceTask"
             AssemblyFile="$(TeamBuildRefPath)\Microsoft.TeamFoundation.Build.Tasks.VersionControl.dll" />

Add the variables needed for wsp packaging.  Note: there is probably a better way to determine the location of the IDE

  <PropertyGroup>

    <!--  
    Variables added for VSeWSS 1.3 builds 
    -->

    <!--  IDEPath
    The path in which DevEnv and TF reside 
    -->
    <IDEPath>C:\Program Files\Microsoft Visual Studio 9.0\Common7\IDE</IDEPath>

    <!-- TempWorkspaceName
    Workspace name, must not match an existing namespace name 
    -->
    <TempWorkspaceName>NightlyBuildTempWorkspace</TempWorkspaceName>
    
  </PropertyGroup>

Add the solution to build.  Note: this will build the binaries, but will not generate the wsp file

  <ItemGroup>

    <SolutionToBuild Include="$(BuildProjectFolderPath)/../../Intranet/Intranet.sln">
        <Targets></Targets>
        <Properties></Properties>
    </SolutionToBuild>

  </ItemGroup>

Add the target to clean up any files left by the previous build packaging (if the previous build failed or was cancelled).  This target is called during the build just before the workspace is created to build the solution

  <!-- Before the build workpace is initialized -->
  <Target Name="BeforeInitializeWorkspace" >

    <!-- Delete temporary workspace (if left by previous build) -->
    <BuildStep
        TeamFoundationServerUrl="$(TeamFoundationServerUrl)"
        BuildUri="$(BuildUri)"
        Message="Deleting temporary workspace &quot;$(TempWorkspaceName)&quot; (if left by previous build).">
      <Output TaskParameter="Id" PropertyName="StepId" />
    </BuildStep>

    <DeleteWorkspaceTask
          TeamFoundationServerUrl="$(TeamFoundationServerUrl)"
          BuildUri="$(BuildUri)"
          Name="$(TempWorkspaceName)"
          DeleteLocalItems="true" />

    <DeleteWorkspaceTask
          TeamFoundationServerUrl="$(TeamFoundationServerUrl)"
          BuildUri="$(BuildUri)"
          Name="$(TempWorkspaceName)"
          DeleteLocalItems="false" />

    <BuildStep
              TeamFoundationServerUrl="$(TeamFoundationServerUrl)"
              BuildUri="$(BuildUri)"
              Id="$(StepId)"
              Status="Succeeded" />

    <!-- Error Occurred -->
    <OnError ExecuteTargets="MarkBuildStepAsFailed" />

  </Target>

Add the error handling target.  If any of the other steps fail, they will call this target using ExecuteTargets

    <!-- Handles custom errors -->
  <Target Name="MarkBuildStepAsFailed">
    <BuildStep
        TeamFoundationServerUrl="$(TeamFoundationServerUrl)"
        BuildUri="$(BuildUri)"
        Id="$(StepId)"
        Status="Failed" />
  </Target>

In the AfterCompile target, add the step to delete the workspace that was automatically created by the build

<!-- After the solutions are compiled -->
  <Target Name="AfterCompile" >

    <!-- Delete build workspace -->
    <BuildStep
            TeamFoundationServerUrl="$(TeamFoundationServerUrl)"
            BuildUri="$(BuildUri)"
            Message="Deleting build workspace &quot;$(WorkspaceName)&quot;.">
      <Output TaskParameter="Id" PropertyName="StepId" />
    </BuildStep>

    <DeleteWorkspaceTask
          TeamFoundationServerUrl="$(TeamFoundationServerUrl)"
          BuildUri="$(BuildUri)"
          Name="$(WorkspaceName)"
          DeleteLocalItems="false" />

    <BuildStep
              TeamFoundationServerUrl="$(TeamFoundationServerUrl)"
              BuildUri="$(BuildUri)"
              Id="$(StepId)"
              Status="Succeeded" />
    <!-- END Delete build workspace -->

Just below that, add the build step to create the temporary workspace

    <!-- Create temporary workspace -->
    <BuildStep
        TeamFoundationServerUrl="$(TeamFoundationServerUrl)"
        BuildUri="$(BuildUri)"
        Message="Creating temporary workspace &quot;$(TempWorkspaceName)&quot;.">
      <Output TaskParameter="Id" PropertyName="StepId" />
    </BuildStep>

    <CreateWorkspaceTask
          TeamFoundationServerUrl="$(TeamFoundationServerUrl)"
          BuildUri="$(BuildUri)"
          BuildDirectory="$(BuildDirectory)"
          SourcesDirectory="$(SolutionRoot)"
          Name="$(TempWorkspaceName)"
          Comment="Temporary workspace">
    </CreateWorkspaceTask>

    <BuildStep
              TeamFoundationServerUrl="$(TeamFoundationServerUrl)"
              BuildUri="$(BuildUri)"
              Id="$(StepId)"
              Status="Succeeded" />
    <!-- END Create temporary workspace -->

Add the step to package the solution.  This first marks all files in the pkg directory as not read only--the packaging will not be able to overwrite these files otherwise.  Then it runs the IDE and uses the /package switch to generate the wsp.  Finally, it copies the wsp to the drop folder.  If you had multiple wsp files to build, you could repeat the steps below or refactor into a target

    <!-- Place projects to package here -->

    <!--  Build and package solution -->
    <BuildStep
        TeamFoundationServerUrl="$(TeamFoundationServerUrl)"
        BuildUri="$(BuildUri)"
        Message="Packaging &quot; Contoso Intranet solution&quot;.">
      <Output TaskParameter="Id" PropertyName="StepId" />
    </BuildStep>

    <!-- The extensions modify files in the pkg directory, so those files cannot read only-->
    <Exec Command="attrib -R &quot;$(BuildDirectory)\Contoso\Intranet\Deployment\pkg\*.*&quot; /S /D" />

    <!-- Open a second instance of the dev environment and build using /package switch  -->
    <Exec Command="&quot;$(IDEPath)\devenv&quot; &quot;$(BuildDirectory)\Contoso\Intranet\Intranet.sln&quot; /deploy debug /package" />

    <!-- Copy to drop location -->
    <Exec Command="xcopy &quot;$(BuildDirectory)\Contoso\Intranet\Deployment\bin\debug\Contoso.Intranet.wsp&quot; &quot;$(DropLocation)\$(BuildNumber)\&quot; /E /Y /R" />

    <BuildStep
              TeamFoundationServerUrl="$(TeamFoundationServerUrl)"
              BuildUri="$(BuildUri)"
              Id="$(StepId)"
              Status="Succeeded" />
    <!-- END Build and package solution -->

Add the build step to delete the temporary workspace we created

    <!-- Delete temporary workspace -->
    <BuildStep
        TeamFoundationServerUrl="$(TeamFoundationServerUrl)"
        BuildUri="$(BuildUri)"
        Message="Deleting temporary workspace &quot;$(TempWorkspaceName)&quot;.">
      <Output TaskParameter="Id" PropertyName="StepId" />
    </BuildStep>

    
    <DeleteWorkspaceTask
          TeamFoundationServerUrl="$(TeamFoundationServerUrl)"
          BuildUri="$(BuildUri)"
          Name="$(TempWorkspaceName)"
          DeleteLocalItems="false" />

    <BuildStep
              TeamFoundationServerUrl="$(TeamFoundationServerUrl)"
              BuildUri="$(BuildUri)"
              Id="$(StepId)"
              Status="Succeeded" />
    <!-- END Delete temporary workspace -->

Check the project back in to source control, and queue the build to test it

One of the shortcomings of the RSS Viewer web part is that it can only be bound one feed.  In this walkthrough, I’ll show you how to make the RSS Viewer web part dynamic with filter web parts and web part connections to enable binding to multiple feeds.

Create the RSS Feeds List

In View All Site Content, select Create

Select Custom List and enter a name such as “RSS Feeds.”  Next, add two columns to the list.  The first column will hold the feed URL and the second column is a one-line description of the feed that will be displayed in the filter list.  Name the column “Feed URL,” set the type to Single line of text (not Hyperlink), make it required, and add it to the default view.

Add the description column.  Name the column “Feed Description,” set the type to Single line of text, make it required, and add it to the default view.

Next, add some feeds to the list:

Add an RSS Viewer Web Part

Add an RSS Viewer web part to a page:

Configure the web part to default to your favorite feed:

Add a Filter Web Part

Add a filter web part to the page to control which feed is displayed in the RSS Viewer.  Add a SharePoint List Filter web part to the page:

Configure the filter web part to use the values from the feed list:

Connect the Filter Web Part to the RSS Viewer Web Part

Next, connect the filter web part to the RSS viewer web part.  Select Connections > Send Filter Values To > RSS Viewer:

Set the Connection Type to “Get Feed URL From”:

Test the Filter

Click the browse button on the filter:

Select one of the feeds and the corresponding feed should display in the RSS Viewer:

Conclusion

The RSS Viewer web part can be made more dynamic and provide a better user experience by using filter web parts.  In this walkthrough I showed you one type of filter, but I invite you to investigate other approaches using some of the other out of the box filter web parts.

References and Additional Reading

• RSS Feed Reader (CodePlex)
• Work with Filter Web Parts
• Issues using RSS Feed Viewer Web Part with a List of RSS Feeds using SharePoint 2007
• RSS Viewer Web Part and Authenticated Feeds

Sometimes you need a local copy of an assembly from the GAC and here is a quick tip on how to do it.  The GAC can be found in the c:\windows\assembly directory, but if you try to browse it, the following custom shell extension appears:

This view does not provide the ability to copy assemblies, but it does provide some very useful information such as the strong name details.  Here are some options to get around that feature to copy an assembly from the GAC.

Option 1: Disable the Shell Extension in the Registry

One possibility, but not the best one, is to disable the shell extension.  I don't like this approach because it involves editing the registry and I like the information provided by the shell extension.  Here's how to disable the extension if you want to.  Open the registry editor and add/set the HKLM\Software\Microsoft\Fusion\DisableCacheViewer DWORD value:

Set the value to 1:

Once you make that change, you can browse the directory:

Option 2: Go Command-O

Another option is to copy assemblies from the GAC from the command line.  This approach works well if you prefer working from the command line, but if you like to right-click with a mouse, this might not be the choice for you.

I highly recommend PowerShell, but you can use Windows Command Prompt.  Find your way to the c:\windows\assembly directory and copy the file you need:

Option 3: Use the SUBST Command

The SUBST command allows you to create a shortcut to a path on your file system and assigns that shortcut a drive letter.  I really like this approach because you have the option of using Windows Explorer without having to disable the shell.

Suppose you want to create a G Drive (G for GAC), use the following command: SUBST G: C:\WINDOWS\ASSEMBLY

Then in Windows Explorer you are free to double-click and right-click to your heart's content and still use the shell extension. 

A common SharePoint customization request is to copy or move items and documents between lists.  This can be accomplished without development by creating a workflow using SharePoint Designer (SPD).  With this approach, you may encounter issues with list item fields not copying or copying intermittently.  This article will explain how the copy list item activity works, what can go wrong and how to troubleshoot and resolve the issues.

About SPD Workflows

If you are not familiar with SPD workflows, here is a quick primer on how to create a workflow that copies a list item to another list.  Open the site and select File > New Workflow.  Select the source list and set the start options.  Note in this example, the workflow executes when a new list item is added.

The workflow consists of steps which have conditions and actions.  In this example, there are no conditions, only an action to copy the list item:

Configure the action to copy the current item in the source list to the target list and click Finish to associate the workflow with the source list.

Add a new item to the source list and you can see the outcome of the workflow:

The item was copied to the target list:

How the Copy List Item Activity Works

The copy list item activity iterates through all the fields in the source list and tries to find a match in the target list.  The fields are considered compatible for copying when the following is true:

• The source and target field names are the same.  It compares the field name you see in the browser (SPField.Title), not the internal/static name (SPField.InternalName)
• The source and target field are the same type
• The source and target fields are compatible.  For example, if the source field allows multiple selections, but the target does not, or the source allows selecting people and groups, but the target only allows selecting people
• When the source field is a lookup to another list, the target field must use the same list
• The source field is not read only
• The source field is not a special field, such as ContentTypeId

After the field matches have been determined, a list item is created in the target list using a system update (does not trigger event receivers / workflows and the created by user is system).  In addition, when the field type is User, the user(s) are created in the target web if they don't already exist.

What Can Go Wrong

There are two common symptoms and the underlying causes of each is human error.  But don't beat yourself up; they are easy mistakes to make and correct.  Use the following to troubleshoot the issue:

• When a SPD workflow doesn't copy one field to the target list:
  • The field names don't match
  • The field names match, but the field type and the settings do not 
• In a document library, when none of the fields are copied (except the file name), or when all the fields are copied but intermittently:
  • The issue is that everything is working as designed and the workflow hasn't accounted for it!  There is a difference between New and Upload 

The Difference Between New and Upload in a Document Library

In a document library, users can add a document two ways through the browser.  The first option is to click New.  This opens the client application associated to the list template such as Microsoft Word.  In Word 2007, the list item properties appear on the Document Information Panel (In Word 2003, the list item properties are displayed in a dialog when you save the document):

Because the list item properties are captured by the client application, the document and properties are saved at the same time.  The save triggers the workflow created event receiver logic and the copy will succeed.  When the document is added using the Upload (or Upload Mutliple) option, the upload occurs in two stages.  The first stage is adding the file to the document library:

The second stage is updating the list item properties.  At this point, the item has been added to the document library, the created event has fired, and the copy list item workflow has completed. The properties haven't been entered, so the workflow copied the document and blank property values to the target list.

The following summarizes the differences between New and Upload:

• When a document is uploaded using New, there is only a create 
• When a document is uploaded using Upload, there is a create when the file is uploaded and an update when (and if) the properties are updated--but the properties are updated with a system update so the update event does not fire

Troubleshooting and Solutions

• When only one field doesn't copy
  • Don't trust your eyes, copy the field name from the source list and paste it into the field name of the target list.  For example, how long does it take you to spot the difference between these two fields:  Source:Mutiline Field, Target:Multiline Field?
  • Compare the settings between the source field and target field.  Does one allow multiple values and the other does not?
• In a document library when all fields don't copy or copy intermittently
  • The workflow needs to account for the difference between New and Upload
    • Configure the workflow to execute when the item is changed
    • Add a condition to the copy list item step to examine the workflow status

To overcome the issue with document libraries, one possible approach is to modify the SPD workflow as follows:

• Set the workflow to execute only when the item is created
• In the first step, add a wait activity to wait until a required field is not empty (a field that is entered in the "second  stage" after the document is uploaded)

Conclusion

SPD workflows are a business-user enabling technology and a useful tool in your SharePoint customization toolkit.  I hope this article sheds some light on how to implement a copy list item workflow using SPD and how to troubleshoot and resolve common issues with the approach.