mixed case in File fullPaths can cause class indexing to start too high


Using OpenCover and ReportGenerator 4.0.804 to report my test coverage the report generation started taking figuratively forever. Investigating, I saw something likefound report files: D:/sandbox/project/src/buildlogs/temp_test_coverage/Project.UnitTest.coverage.xmlLoading report 'D:\sandbox\project\src\buildlogs\temp_test_coverage\Project.UnitTest.coverage.xml' Preprocessing report Indexing classes in directory 'D:\sandbox\project\src\Module1\SubPath\' Added coverage information of 370/370 auto properties to module 'Module1' Indexing classes in directory 'D:\'My D: drive isn't the hugest, but it's big enough, so that explained the delay. And of course, I certainly didn't want anything above D:\sandbox\project\src indexed. I took a peek at my .coverage.xml file and the ReportGenerator code and until I found the offending lines.All but one of my File nodes had a fullPath starting with "D:\sandbox" except one, which had "D:\Sandbox". Because "S" isn't "s", CommonDirectorySearcher.GetCommonDirectory thinks the longest common prefix is "D:\" and searches the drive.I was able to reproduce using the attached unit test added to CommonDirectorySearcherTest.It appears to be fixed by using StringComparison.OrdinalIgnoreCase when checking prefixes in CommonDirectorySearcher.GetCommonDirectory.I worried a little about this not being sophisticated enough, in case we were working on a UNIX filesystem where case is significant (for example), but the code around these lines seemed to assume Windows (assuming "\"s between path components), so I figured I'd see what you think.Thanks, Blair

file attachments

Closed Dec 16, 2012 at 10:52 AM by danielpalme
Fixed in changeset #71309


BlairConrad wrote Dec 7, 2012 at 11:47 AM

Attaching proposed fix.

danielpalme wrote Dec 8, 2012 at 11:42 AM

Thanks for your hint. I will have a look at it soon.

wrote Dec 16, 2012 at 10:52 AM

wrote Feb 14, 2013 at 8:16 PM

wrote May 16, 2013 at 9:56 AM