How to publish .coverage file to a TFS build from CUITs

Question

I have used vsinstr.exe to instrument the subject assemblies for code coverage and then vsperfmon.exe to capture the .coverage file while running the code UI tests. The /EnableCodeCoverage option for vstest.console.exe is only valid when running unit tests.
How do I publish the resulting .coverage file to TFS and associate with a build? When running the CUITs with vstest.console.exe I am using the TfsPublisher to published the test results with a build.
Thanks.

Answer 1

Thanks, yes I've reviewed this information and many others. Per my original post, I'm using vsperfmon.exe to capture the .coverage file while running the code UI tests per http://blogs.msdn.com/b/phuene/archive/2007/05/14/code-coverage-collection.aspx
as /EnableCodeCoverage does not seem to work as listed below.
On Win8.1 Enterprise with Update 1 using VS2013.4 and TFS2013.4 I've attempted to scale back from a client server set of tests to a simple WinForm application and Coded UI test. When attempting to use the following command in a VS2013 command window as Administrator
I receive the following then the test never executes.
Warning: Using Isolation mode to run the tests as diagnostic data adapters were enabled in the  runsettings. Use the /inIsolation parameter to suppress this warning.
"C:\Program Files (x86)\Microsoft Visual Studio 12.0\Common7\IDE\CommonExtensions\Microsoft\TestWindow\vstest.console.exe" WFATest.dll /logger:TfsPublisher;Collection=http://mtl-tfs-at:8080/tfs/TfsRetailCollection_1;BuildNa
me=StoreMain6.4.0.5.0.163;TeamProject=BASE-Timekeeping;Platform="AnyCPU";Flavor="Release";RunTitle="20150112 Run" /EnableCodeCoverage 
When using a simple .runsettings file that has no diagnostic data adapters defined I still receive the warning. When running the same above command WITHOUT the /EnableCodeCoverage option then the test executes successfully.
....in only one case using the /EnableCodeCoverage option I received the following error:
Error: There was no endpoint listening at net.pipe://bcasner7/TestExecutor/15976 that could accept the message. This is often caused by an incorrect address or SOAP action. See InnerException, if present, for more details.