dotCover generating 1.6GB coverage file

Answered

I have just switched on dotCover support for a solution I am supporting, which comprises about 30 assemblies totalling 15MB in size, so nothing too huge. While testing and coverage itself ran smoothly, when it came to uploading the results, TeamCity bombed out with the following error:

[06:07:28] Publishing artifacts (2s)
[06:07:28] Collecting files to publish: [D:\BuildAgent\temp\buildTmp\coverage2236087896297608751zip\CoverageReport.xml=>.teamcity/.NETCoverage]
[06:07:28] Publishing 1 file [D:/BuildAgent/temp/buildTmp/coverage2236087896297608751zip/CoverageReport.xml => .teamcity/.NETCoverage] using [ArtifactsCachePublisher]
[06:07:28] Publishing 1 file [D:/BuildAgent/temp/buildTmp/coverage2236087896297608751zip/CoverageReport.xml => .teamcity/.NETCoverage] using [WebPublisher]
[06:07:28] Publishing artifacts (4s)
[06:07:28] Collecting files to publish: [D:\BuildAgent\temp\buildTmp\coverage3601415231415118859zip\dotCover.dcvr=>.teamcity/.NETCoverage]
[06:07:31] Publishing 1 file [D:/BuildAgent/temp/buildTmp/coverage3601415231415118859zip/dotCover.dcvr => .teamcity/.NETCoverage] using [ArtifactsCachePublisher]
[06:07:31] Publishing 1 file [D:/BuildAgent/temp/buildTmp/coverage3601415231415118859zip/dotCover.dcvr => .teamcity/.NETCoverage] using [WebPublisher]
[06:07:28] Publishing artifacts (6s)
[06:07:28] Collecting files to publish: [D:\BuildAgent\temp\buildTmp\dotCover4394796116229772270report\coverage.zip=>.teamcity/.NETCoverage]
[06:07:33] Publishing 1 file [D:/BuildAgent/temp/buildTmp/dotCover4394796116229772270report/coverage.zip => .teamcity/.NETCoverage] using [ArtifactsCachePublisher]
[06:07:33] Publishing 1 file [D:/BuildAgent/temp/buildTmp/dotCover4394796116229772270report/coverage.zip => .teamcity/.NETCoverage] using [WebPublisher]
[06:07:34] Failed to publish artifacts: Artifact [coverage.zip] length [1680374289] exceeds maximum allowed [300000000]

Any idea why the file should be 1.6GB in size? Can I turn off the generation of that file, because it can't be good for performance to create or store it? I'm more interested in just getting the statistics at this point.

10 comments
Comment actions Permalink

Got the same behavior, 2GB coverage.zip file. Upped the artifact size limit to 2.5GB to see the result. Number of assemblies looks OK, however very slow to navigate in.

0
Comment actions Permalink

Hi

Is it possible to share .dcvr files?

0
Comment actions Permalink

Thank you, but I meant the big .dvcr file

0
Comment actions Permalink

Well - the dvcr file is only 15.91MB - You want the zip file? If so, could you provide a upload dest. - don't wanna post the file in public. (jmn[at]seges.dk)

 

0
Comment actions Permalink

Hi Jasper,

Please use our FTP or create a request using "Submit a request" button on the top.

0
Comment actions Permalink

Hi Alina, I've uploaded to the ftp server - filename is coverage_jmn.zip

0
Comment actions Permalink

Hi @Alina,

 

Any update on this issue?

0
Comment actions Permalink

Hi Jasper Nygaard,

Looks like you've got a lot of generated source files. Try using System.CodeDom.Compiler.GeneratedCodeAttribute to decrease size of coverage data.

0
Comment actions Permalink

Hi Nikolay,

We kind of gave op in 2016 regarding dotCover and code coverage. However we are looking into using SonarQube and would love to get this to perform. 

I just went through lot of the generated source code and all the classes seems to be annotated with this attribute. What am I mising here?

Examples - should they be supported? Could you give be a hint as of which file areas are generating so much data?

[System.CodeDom.Compiler.GeneratedCodeAttribute("PresentationBuildTasks", "4.0.0.0")][global::System.CodeDom.Compiler.GeneratedCodeAttribute("Microsoft.VisualStudio.Editors.SettingsDesigner.SettingsSingleFileGenerator", "14.0.0.0")][global::System.CodeDom.Compiler.GeneratedCodeAttribute("System.Resources.Tools.StronglyTypedResourceBuilder", "4.0.0.0")][System.CodeDom.Compiler.GeneratedCodeAttribute("System.Runtime.Serialization", "4.0.0.0")]

0

Please sign in to leave a comment.