Merging of CodeFiles does not take into account different path separators

[cyungmann]

Describe the bug
Perhaps I am missing something, but I believe the Equals(object) implementation in CodeFile.cs does not account for different path separators on different operating systems:

        public override bool Equals(object obj)
        {
            if (obj == null || !obj.GetType().Equals(typeof(CodeFile)))
            {
                return false;
            }
            else
            {
                var codeFile = (CodeFile)obj;
                string fileNameToCompare = codeFile.Path.Substring(codeFile.Path.LastIndexOf('\\') + 1);

                string fileName = this.Path.Substring(this.Path.LastIndexOf('\\') + 1);
                return fileName.Equals(fileNameToCompare, StringComparison.OrdinalIgnoreCase);
            }
        }

I think this is causing different behavior in a build pipeline I am using when run on a Windows build agent vs Linux build agent and merging coverage reports generated on different operating systems.

[danielpalme]

I will have a look within the next days.

[danielpalme]

Can you share some sample coverage files that you are trying to merge?
That would be great to test with your "real" files.

You can share them privately via email reportgenerator@palmmedia.de

[cyungmann]

@danielpalme I'm not sure about providing the real files, but I can try to create a minimal repro this week.

[danielpalme]

That would be great. Thank you!

[cyungmann]

TestResults.zip contains coverage.cobertura.xml files from coverlet.collector run on both Windows and Linux. After invoking reportgenerator on Linux, the produced HTML report says that there are 2 files:

However, when invoking reportgenerator on Windows on the same files, the produced HTML report says that there is only 1 file and it correctly merges the two occurrences of the file together:

[cyungmann]

The attempted fix for #60 is meant to improve merging of CodeFile instances when the file paths are different, but does not seem to work in cross-platform/OS scenarios since it explicitly uses the '\' character.

[cyungmann]

@danielpalme let me know if there is any other information that would be useful, e.g. the test solution/code I used.

[cyungmann]

There is also interplay with this code in CoberturaReportProcessor that normalizes paths to Path.DirectorySeparatorChar, hence why things seem to work on Windows.

[danielpalme]

Thanks for your sample files.
I was able to reproduce the issue on Linux.

The next release will contain the fix (5b04a56).
I will let you know once it's published!