dotCover checked in on build servers

I am in the process of setting up coverage reporting on our build server (TeamCity). Our goal is to have everything needed in the build chain checked in, thus allowing all developers to perform the same tasks as the build server, as well as keeping the requirements for the agents down (no need to install stuff asit is pulled from the vcs).

A couple of questions wrt dotCover:
* Will that work? Or is there something that absolutely needs to be installed on the machine in order to make things work?
* Is the command line runner licensed outside of the integrated licenses? This makes it theoretically possible for developers to run the command line tool all at once, but the only result they will get is a html file, nothing integrated in VS. Obviously we will get licenses covering the needs for developers who want this in VS.

Best regards,

--Jesper Hogstrom

5 comments

Hello Jesper,
TeamCity 6 goes with the bundled dotCover version, but according to the license agreement it's possible to execute it only on build server.
In order to use dotCover locally you need a separate license for each working place (even if you don't use VS integration)

Regarding technical requirements:
You need .NET framework 2.0 or higher and Microsoft Visual C++ 2008 SP 1 Redistributable Package  ATL Security Update

0

Ruslan,

Did you mean to say "execute it only on build agent" instead of "execute it only on build server"? Seems to me that dotCover is bundled with agent distribution, not server.

Thanks,

Oleg.

0

Oleg,
The more precise statement is that dotCover bundled with TeamCity should be used only as a part of TeamCity.

0

While it is great to have dotCover integrated on the build server, I prefer to have my build systems designed so everything that can be done on the build server can be done from command line on the dev machines. Thus, everything required during build/test/analysis/installmaking is reachable from my build scripts, either checked in or retrievable from an external location (be it a remote file system, web server or rsync server).

In the case of dotCover, it would be really sweet if I could use my own scripts to call the bundled version (when executing on a build agent) or use a local version (if the developer has a valid license of dotCover). My understanding is that such a solution would not violate any licensing agreements.

Two questions arise:
* How can I find and invoke the bundled instance of dotCover on an agent?
* How can I reliably determine by scripts if the machine I am executing on has a valid license of dotCover (nonexpired trial or full license) and where the binaries on the specific machine are installed?

--Jesper Hogstrom

0

Please sign in to leave a comment.