Technology Toolbox

Your technology Sherpa for the Microsoft platform

Jeremy Jameson - Founder and Principal



Extraneous SharePoint Assemblies

This post originally appeared on my MSDN blog:

Since I no longer work for Microsoft, I have copied it here in case that blog ever goes away.

If you develop solutions for Microsoft Office SharePoint Server (MOSS) 2007, you may notice that certain SharePoint assemblies always get copied to your Visual Studio project output folder even though these referenced assemblies are configured with Copy Local = False. Since these assemblies should always refer to the ones installed by MOSS 2007 on the destination environment, you obviously don't want to deploy these as part of your solution.

The "extraneous" files that I've seen copied are:

  • Microsoft.Office.Server.Search.dll
  • Microsoft.Office.Workflow.Feature.dll
  • Microsoft.SharePoint.Portal.SingleSignon.dll
  • Microsoft.SharePoint.Search.dll
  • Microsoft.SharePoint.Search.xml

While I can't provide an explanation for why the Copy Local property is ignored for these assemblies, I can provide you with a script to recursively remove these files from your Visual Studio project structure.

Sometime last year, I created the following script and dropped it in my SharePoint Toolbox folder (\NotBackedUp\Public\Toolbox\SharePoint\Scripts\DeleteExtraneousSharePointAssemblies.vbs):

Option Explicit

Dim strFolder
strFolder = "."

If (WScript.Arguments.Count = 1) Then
    strFolder = WScript.Arguments(0)
ElseIf (WScript.Arguments.Count > 1) Then
    WScript.Echo("Usage: DeleteExtraneousSharePointAssemblies.vbs [folder]")
End If

Dim fso
Set fso = CreateObject("Scripting.FileSystemObject")

Dim folder
Set folder = fso.GetFolder(strFolder)

If (InStr(folder, "Program Files") > 0) Then
    WScript.Echo("Error: Cannot delete assemblies from Program Files")
End If

Wscript.Echo "Scanning: " & folder.Path

DeleteExtraneousSharePointAssemblies folder

Sub DeleteExtraneousSharePointAssemblies(folder)
    Wscript.Echo "Scanning: " & folder.Path

    Dim file
    For Each file in folder.Files
        If file.Name = "Microsoft.Office.Server.Search.dll" _
            Or file.Name = "Microsoft.Office.Workflow.Feature.dll" _
            Or file.Name = "Microsoft.SharePoint.Portal.SingleSignon.dll" _
            Or file.Name = "Microsoft.SharePoint.Search.dll" _
            Or file.Name = "Microsoft.SharePoint.Search.xml" Then

            If (Not (file.Attributes And 1 = file.Attributes)) Then
                Wscript.Echo "Removing read-only flag from file: " & file.Path
                file.Attributes = file.Attributes XOr 1
            End If

            Wscript.Echo "Deleting " & file.Path
        End If

    Dim subFolder
    For Each subFolder in Folder.SubFolders
        DeleteExtraneousSharePointAssemblies subFolder
End Sub

While these copied files may not seem like a significant issue, if you configure automated daily builds of your solution and subsequently copy each daily build to a "Release Server" -- or if you have multiple branches of your solution available on your local development VM -- then the disk space consumed by these files can really add up.

For example, across the 7 branches of the solution from my previous project (with some of the later branches containing 52 Visual Studio projects), a simple search for Microsoft.* returned 316 items consuming a whopping 746 MB of disk space. This is a significant amount of space when you consider that I typically allocate anywhere from 16-20GB for each VHD.

After running the script above, I regain roughly 750MB of wasted disk space.

The space savings are obviously much higher on the Release Server that archives the Debug and Release outputs from each build.

Note that we were using Visual Studio 2005 on my previous project.


  1. # infoblog » Extraneous SharePoint Assemblies

    March 29, 2009 9:27 PM
  2. # re: Extraneous SharePoint Assemblies

    November 28, 2012 6:01 PM
    Fred Stumpp
    I know this is an old post, but like me, others may be researching this issue for the first time. This blog saved a lot of time by zeroing in on the cause. In my case, the reference to Microsoft.Office.Server.Search defaulted to Copy Local = True and resulted in these extraneous files:


    Once I set Microsoft.Office.Server.Search to Copy Local = False, the above files disappeared from the output folder. I did not need to resort to a clean up script.
    Moral: check ref properties to ensure Copy Local = False


Add Comment

Optional, but recommended (especially if you have a Gravatar). Note that your email address will not appear with your comment.
If URL is specified, it will be included as a link with your name.

To prevent spam from being submitted, please select the following fruit: Apple

Please add 1 and 1 and type the answer here: