{"id":543,"date":"2012-01-21T12:25:58","date_gmt":"2012-01-21T12:25:58","guid":{"rendered":"https:\/\/blogs.msdn.microsoft.com\/buckh\/2012\/01\/21\/a-tool-to-find-duplicate-copies-in-a-build\/"},"modified":"2012-01-21T12:25:58","modified_gmt":"2012-01-21T12:25:58","slug":"a-tool-to-find-duplicate-copies-in-a-build","status":"publish","type":"post","link":"https:\/\/devblogs.microsoft.com\/buckh\/a-tool-to-find-duplicate-copies-in-a-build\/","title":{"rendered":"A tool to find duplicate copies in a build"},"content":{"rendered":"

As part of our builds, quite a few projects copy files to the binaries directory or other locations.  These can be anything from image files to test scripts.  To have our builds complete more quickly, we use the multi-process option (\/maxcpucount<\/a>) of msbuild to build projects in parallel<\/a>.<\/p>\n

This all sounds normal, so what\u2019s the problem?  In a large team, people will sometimes inadvertently add statements to different project files that copy files to the same destination.  When those project files have no references to each other, directly or indirectly, msbuild may build them in parallel.  If it does happen to run those projects in parallel on different nodes and the copies happen at the same time, the build breaks because one copy succeeds and one fails.  Since the timing is not going to be the same on every build, the result is random build breaks.  Build breaks suck.  They drain the productivity of the team and are frustrating.<\/p>\n

Whether the build is continuous integration or gated checkin, these breaks may happen randomly.  They are most likely to happen on incremental builds where the percentage of time spent during the build on doing copies is much higher than a clean build.  Tracking them down as they happen is painful.<\/p>\n

So, I wrote a simple tool to find cases in the log where the destination is the same for more than one copy operation.  The comment in the header explains what the code is looking for.  Running this on the normal verbosity msbuild logs from a clean build ensures that all of the copies are in the log for analysis.  We also build what we call partitions separately, resulting in the number of log files being a multiple of the number of partitions being built (a partition is a subset of the source and is typically a top-level directory in the branch).<\/p>\n

In our internal builds, we record multiple log files for our builds, including minimal, normal, and detailed.  When there\u2019s a problem, you can start with the smaller build logs and increase to the more verbose logging as needed.<\/p>\n

I\u2019m posting this for any of you who might run into the same thing.  Keep in mind that there are other things, such as antivirus software, that can interfere with the build process and result in errors for files being copied.<\/p>\n

\n
using<\/span> System;\nusing<\/span> System.Collections.Generic;\nusing<\/span> System.Linq;\nusing<\/span> System.IO;\nusing<\/span> System.Text;\nusing<\/span> System.Text.RegularExpressions;\nusing<\/span> System.Threading.Tasks;\n\n\/*<\/span>\n * This tool finds cases where more than one file is copied to the same target.  This will cause<\/span>\n * build breaks when msbuild executes the copies in parallel because the copies are independent<\/span>\n * (there are no dependencies).  This typically occurs in incremental builds because incremental<\/span>\n * builds do a lot less work (not nearly as much to build), resulting in the copies being a much<\/span>\n * higher percentage of the build activities and more likely to collide.  Gated checkin,<\/span>\n * continuous integration, and developer\/tester builds are almost always incremental, not clean.<\/span>\n * These issues are still possible in regular clean builds, such as done nightly by the build lab.<\/span>\n * <\/span>\n * These race conditions are difficult to debug manually.  Since msbuild records all of the copies<\/span>\n * made via the copy task, we can use the log file to identify cases where the same destination<\/span>\n * path is used in more than one copy.<\/span>\n * <\/span>\n * Use the *.normal.* logs from a clean build with this tool.<\/span>\n * <\/span>\n * The best thing to do is to ensure that each file copy to a particular destination is done by<\/span>\n * one and only one project.  When that is the case, you are guaranteed not to have problems<\/span>\n * with two copies colliding and breaking your build.<\/span>\n * <\/span>\n * Here's example output from buildr.suitesrc.normal.log that shows a copy failure.  Here two<\/span>\n * copies were executed in parallel and the second one failed, causing the build to fail.<\/span>\n * <\/span>\n    48>Project "D:\\a1\\dd\\alm\\tfs_core\\Admin\\Servicing\\Data\\dirs.proj" (48) is building "D:\\a1\\dd\\alm\\tfs_core\\Admin\\Servicing\\Data\\Azure\\Microsoft.TeamFoundation.Data.Azure.csproj" (55) on node 8 (BuildLinked target(s)).<\/span>\n<\/span>\n    55>_CopyOutOfDateSourceItemsToOutputDirectory:<\/span>\n         Copying file from "D:\\a1\\dd\\alm\\tfs_core\\Admin\\Servicing\\Data\\ReleaseManifest.xml" to "D:\\a1\\binaries.x86ret\\bin\\i386\\ReleaseManifest.xml".<\/span>\n<\/span>\n<\/span>\n    48>Project "D:\\a1\\dd\\alm\\tfs_core\\Admin\\Servicing\\Data\\dirs.proj" (48) is building "D:\\a1\\dd\\alm\\tfs_core\\Admin\\Servicing\\Data\\SqlServer\\Microsoft.TeamFoundation.Data.csproj" (53) on node 4 (BuildLinked target(s)).<\/span>\n<\/span>\n    53>_CopyOutOfDateSourceItemsToOutputDirectory:<\/span>\n         Copying file from "D:\\a1\\dd\\alm\\tfs_core\\Admin\\Servicing\\Data\\ReleaseManifest.xml" to "D:\\a1\\binaries.x86ret\\bin\\i386\\ReleaseManifest.xml".<\/span>\n<\/span>\n    53>D:\\a1\\dd\\tools\\x86\\managed\\v4.5\\Microsoft.Common.targets(3516,5): error MSB3021: Unable to copy file "D:\\a1\\dd\\alm\\tfs_core\\Admin\\Servicing\\Data\\ReleaseManifest.xml" to "D:\\a1\\binaries.x86ret\\bin\\i386\\ReleaseManifest.xml". Access to the path 'D:\\a1\\binaries.x86ret\\bin\\i386\\ReleaseManifest.xml' is denied. [D:\\a1\\dd\\alm\\tfs_core\\Admin\\Servicing\\Data\\SqlServer\\Microsoft.TeamFoundation.Data.csproj]<\/span>\n  <\/span>\n * <\/span>\n * Note that there may be multiple copies in a sequence.<\/span>\n * <\/span>\n    291>_CopyOutOfDateSourceItemsToOutputDirectoryAlways:<\/span>\n         Copying file from "D:\\a1\\dd\\suitesrc\\TFS\\common\\deploytools\\httpcfg.exe" to "D:\\a1\\binaries.x86ret\\SuiteBin\\i386\\TFS\\Tests\\httpcfg.exe".<\/span>\n         Copying file from "D:\\a1\\dd\\suitesrc\\TFS\\common\\deploytools\\makecert.exe" to "D:\\a1\\binaries.x86ret\\SuiteBin\\i386\\TFS\\Tests\\makecert.exe".<\/span>\n         Copying file from "D:\\a1\\dd\\suitesrc\\TFS\\common\\deploytools\\winhttpcertcfg.exe" to "D:\\a1\\binaries.x86ret\\SuiteBin\\i386\\TFS\\Tests\\winhttpcertcfg.exe".<\/span>\n       CopyFilesToOutputDirectory:<\/span>\n         Copying file from "D:\\int\\641\\194\\suitesrc\\tfshttpsconfig.csproj_80399372\\objr\\x86\\TfsHttpsConfig.exe" to "D:\\a1\\binaries.x86ret\\SuiteBin\\i386\\TFS\\Tests\\TfsHttpsConfig.exe".<\/span>\n<\/span>\n * Nodes are reused by msbuild.  The result is that a given may process many projects, so it's not<\/span>\n * possible to scan and pair up all of the nodes and project files at once.  In the code below, <\/span>\n * you will see that it always tracks the most recent node for that reason.<\/span>\n * <\/span>\n *\/<\/span>\n\nnamespace<\/span> FindBadCopies\n{\n    class<\/span> Program\n    {\n        static<\/span> void<\/span> Main(string<\/span>[] args)\n        {\n            if<\/span> (args.Length < 1)\n            {\n                Console.WriteLine("Usage: findbadcopies <logfile>\\r\\n"<\/span>);\n                Console.WriteLine(\n@"This tool scans a build log, such as buildr.suitesrc.normal.log, and produces a\nlist of file paths that are the targets of more than one copy and shows which\nproject files initiated each copy.  These redundant file copies are prone to\nfail periodically in incremental builds, such as gated check ins and CI builds,\nbecause copies are a higher percentage of the operations in the build, making\nit more likely that two collide."<\/span>);\n\n                return<\/span>;\n            }\n\n            ProcessFile(args[0]);\n        }\n\n        private<\/span> static<\/span> void<\/span> ProcessFile(String fileName)\n        {\n            Dictionary<int<\/span>, String> nodeTable = new<\/span> Dictionary<int<\/span>, String>(1000);\n            Dictionary<String, int<\/span>> pathTable = new<\/span> Dictionary<String, int<\/span>>(1000, StringComparer.InvariantCultureIgnoreCase);\n            String previousLine;\n\n            string<\/span>[] text = File.ReadAllLines(fileName);\n\n            \/\/ Process all of the lines in the file, skipping the first line (we need the previous line,<\/span>\n            \/\/ and the first line in the file isn't important to this tool).<\/span>\n            int<\/span> lastNode = 0;\n            for<\/span> (int<\/span> i = 1; i < text.Length; i++)\n            {\n                previousLine = text[i - 1];\n\n                \/\/ Record most recent node.  The text that appears with it can be different<\/span>\n                \/\/ (see sample log data).<\/span>\n                string<\/span> prevLinePattern = @"([0-9]+)[>]"<\/span>;\n                Match match = Regex.Match(previousLine, prevLinePattern, RegexOptions.IgnoreCase);\n                if<\/span> (match.Success)\n                {\n                    lastNode = Int32.Parse(match.Groups[1].Value);\n                }\n\n                \/\/ If the line is recording the start of a project, add it to the table.<\/span>\n                string<\/span> pattern = @"[0-9]+[>]Project "<\/span>"[^"<\/span>"]+"<\/span>" \\([0-9]+\\) is building "<\/span>"([^"<\/span>"]+)"<\/span>" \\(([0-9]+)\\)"<\/span>;\n                match = Regex.Match(text[i], pattern, RegexOptions.IgnoreCase);\n                if<\/span> (match.Success)\n                {\n                    int<\/span> node = Int32.Parse(match.Groups[2].Value);\n                    String projectPath = Path.GetFullPath(match.Groups[1].Value);\n\n                    \/\/ Because nodes are reused, we are only keeping the project path for the most recent use<\/span>\n                    \/\/ of a given node.<\/span>\n                    nodeTable[node] = projectPath;\n\n                    \/\/ If we matched a project line, it can't be a copy line.<\/span>\n                    continue<\/span>;\n                }\n\n                \/\/ If the line is one that records a copy, see if there was an earlier copy made to<\/span>\n                \/\/ the same target path.  First, try the output of a copying task.<\/span>\n                string<\/span> copyingPattern = @"Copying file from "<\/span>"[^"<\/span>"]+"<\/span>" to "<\/span>"([^"<\/span>"]+)"<\/span>""<\/span>;\n                match = Regex.Match(text[i], copyingPattern, RegexOptions.IgnoreCase);\n                if<\/span> (match.Success)\n                {\n                    String targetPath = null<\/span>;\n                    try<\/span>\n                    {\n                        targetPath = Path.GetFullPath(match.Groups[1].Value);\n                    }\n                    catch<\/span> (Exception e)\n                    {\n                        \/\/ There is a file in the test tree that uses non-English chars that causes<\/span>\n                        \/\/ GetFullPath() to throw (TODO: understand why), so we keep the raw text.<\/span>\n                        \/\/ Console.WriteLine(match.Groups[1].Value);<\/span>\n                        targetPath = match.Groups[1].Value;\n                    }\n\n                    \/\/ If we have already seen the target path, then we have a duplicate copy path<\/span>\n                    \/\/ target to report.<\/span>\n                    int<\/span> otherNode;\n                    if<\/span> (pathTable.TryGetValue(targetPath, out<\/span> otherNode))\n                    {\n                        Console.ForegroundColor = ConsoleColor.Cyan;\n                        Console.WriteLine("{0}"<\/span>, targetPath);\n                        Console.ResetColor();\n\n                        Console.WriteLine("      {0}"<\/span>, nodeTable[otherNode]);\n                        Console.WriteLine("      {0}"<\/span>, nodeTable[lastNode]);\n                        Console.WriteLine();\n                    }\n\n                    pathTable[targetPath] = lastNode;\n                }\n            }\n        }\n    }\n}<\/pre>\n<\/blockquote>\n","protected":false},"excerpt":{"rendered":"
As part of our builds, quite a few projects copy files to the binaries directory or other locations.  These can be anything from image files to test scripts.  To have our builds complete more quickly, we use the multi-process option (\/maxcpucount) of msbuild to build projects in parallel. This all sounds normal, so what\u2019s the […]<\/p>\n","protected":false},"author":94,"featured_media":10268,"comment_status":"open","ping_status":"open","sticky":false,"template":"","format":"standard","meta":{"_acf_changed":false,"footnotes":""},"categories":[1],"tags":[4,7],"class_list":["post-543","post","type-post","status-publish","format-standard","has-post-thumbnail","hentry","category-uncategorized","tag-msbuild","tag-team-build"],"acf":[],"blog_post_summary":"
As part of our builds, quite a few projects copy files to the binaries directory or other locations.  These can be anything from image files to test scripts.  To have our builds complete more quickly, we use the multi-process option (\/maxcpucount) of msbuild to build projects in parallel. This all sounds normal, so what\u2019s the […]<\/p>\n","_links":{"self":[{"href":"https:\/\/devblogs.microsoft.com\/buckh\/wp-json\/wp\/v2\/posts\/543","targetHints":{"allow":["GET"]}}],"collection":[{"href":"https:\/\/devblogs.microsoft.com\/buckh\/wp-json\/wp\/v2\/posts"}],"about":[{"href":"https:\/\/devblogs.microsoft.com\/buckh\/wp-json\/wp\/v2\/types\/post"}],"author":[{"embeddable":true,"href":"https:\/\/devblogs.microsoft.com\/buckh\/wp-json\/wp\/v2\/users\/94"}],"replies":[{"embeddable":true,"href":"https:\/\/devblogs.microsoft.com\/buckh\/wp-json\/wp\/v2\/comments?post=543"}],"version-history":[{"count":0,"href":"https:\/\/devblogs.microsoft.com\/buckh\/wp-json\/wp\/v2\/posts\/543\/revisions"}],"wp:featuredmedia":[{"embeddable":true,"href":"https:\/\/devblogs.microsoft.com\/buckh\/wp-json\/wp\/v2\/media\/10268"}],"wp:attachment":[{"href":"https:\/\/devblogs.microsoft.com\/buckh\/wp-json\/wp\/v2\/media?parent=543"}],"wp:term":[{"taxonomy":"category","embeddable":true,"href":"https:\/\/devblogs.microsoft.com\/buckh\/wp-json\/wp\/v2\/categories?post=543"},{"taxonomy":"post_tag","embeddable":true,"href":"https:\/\/devblogs.microsoft.com\/buckh\/wp-json\/wp\/v2\/tags?post=543"}],"curies":[{"name":"wp","href":"https:\/\/api.w.org\/{rel}","templated":true}]}}