Code coverage is used to check how much of your code is covered by unit test. When you run “Analyze Code Coverage for All Tests” from Test Explorer of your visual studio, it will first build your solution, then run all the associated tests and then show the code coverage in “Code Coverage Results” window. But what if your Code Coverage results is empty? This will result in an empty .coverage file.
There are many ways to troubleshoot this issue. For some people it will work by just deleting the .suo file from your project solution’s root directory and restarting VS. For some people it works by just removing or adding a test method.
Even that does not work always. In that case the best way to deal with this issue is to check your Event Viewer for a “TraceLog Profiler” error around the same time when you run your code coverage.
“The description for Event ID 5 from source TraceLog Profiler cannot be found. Either the component that raises this event is not installed on your local computer or the installation is corrupted. You can install or repair the component on the local computer.
If the event originated on another computer, the display information had to be saved with the event.
The following information was included with the event:
If you see an error something like above then check for below things and correct accordingly.
a) Environment variable VS110COMNTOOLS is set to <vsinstalldir>\common7\tools
(VS110COMNTOOLS is for VS2012 and VS120COMNTOOLS is for VS2013)
b) Regkey HKLM\SOFTWARE\Microsoft\VisualStudio\11.0\InstallDir is set to your <vsinstalldir>\Common7\IDE\
c) covrun32.dll or covrun64.dll exist in “<vsinstalldir>\Team Tools\Dynamic Code Coverage”
Once a TFS Team Project is created using a process template, there is no record of which process template was used to create the project for later reference. If someone create a project and left the team and another member wants to find out the process template used to create their project, then he will be in a bit of problem as he can’t directly check it any where.
The only possible way to find it is to check its work item types. For example, a project created using Scrum template will have a Backlog item of type “Product Backlog Item” as shown below.
A project created using Agile template will have a Backlog item of type “User Story” as show below.
A project created using CMMI template will have a Backlog item of type “Requirement” as show below.
By checking the work item type i.e. whether it is a Product Backlog Item or a User Story or a Requirement, we can determine the process template used to create the project as Scrum or Agile or CMMI respectively.
Some team requires the details of files/folders checked-in to TFS by users for auditing purpose. Once can achieve this goal both from web access and visual studio.
In Web Access:
Open your Team Project in Web access. Go to CODE. Here you can either select the entire root project folder or any sub folder to check the history.Then select the History link which will show the entire history of check-in related to that folder. You can switch to either Changesets or Shelvesets tab to view only related to those.
Click on Advanced search.You will see a window like below where you can query for any user for a specific date range.
In Visual Studio:
In Visual Studio, connect to your project in Team Explorer. Go to Source Control Explorer of your project. Right click on folder for which you want to find the check in history. Click on Find->Find Changesets (Or Find Shelvesets). It will open a window similar to below.
You can select check-in history of any user by selecting from “By user:” drop down. You can query for all changes, by changeset number or by a created date.
Developers always checkout lots of files to their local machine, work on them and then check them into the source control. But what happens when someone checked out bunch of files, modified them and then suddenly left the organization without checking them in?
This can be a night mare for other developers who wants perform some task on those files but they can’t access the file because it has already been checked out and sitting in the workspace of someone else’s machine. You can neither delete, edit nor even delete or rename the folder containing them. This can be really frustrating when you have a deadline to meet.
In order to release a lock you can either unlock the files if you know what files are locked or better, you can remove the workspace of the developer who has left the team. When you remove the workspace, all the files and folders checked out by it’s owner will be checked in into the source control.
To Unlock a file or Remove workspace follow below steps:
Open a developer command prompt:
Go to Start->All Programs-> Visual Studio 2013(or 2012, depending on your version of Visual Studio)->Visual Studio Tools
Open Developer Command Prompt
Find out the workspace of the employee who left the organization by running below command. (username is for the employee who left)