Its been very long since I have posted anything. Today I am gonna talk about migrating all your TFS Work Items from one project to another. Lets call the project where all your WIs are currently residing as Source Project and the project where you want to migrate your WIs as Target project. Your Target project can be in a totally different project collection or even in a different TFS server.
However TFS does not provide any way to migrate WIs between projects, there are few third party tools that helps in this scenario. I personally found using excel to Migrate very simple. I have used this technique to move work items from one project to another where target projects were in same collection, in different project collection and even different TFS server.
Okay so let’s get some work items moving to start with. The simplest scenario is, if both source and target projects use the same Process Template so that all your fields match.
If the templates don’t match then you’ll have to do some planning to understand how the fields match (for example In Agile template Microsoft.VSTS.Scheduling.StoryPoints to Microsoft.VSTS.Scheduling.Effort in Scrum template) or fields that might be missing (eg. Microsoft.VSTS.Scheduling.CompletedWork or Microsoft.VSTS.Scheduling.OriginalEstimate). If the fields are missing then you could consider adding them to the target process template, storing the information somewhere else or simply leave it behind.
Step 1: Create Query in Source Project
First you need to create a query in your source project that will result all the Work Items that you want move. You would also like to consider different columns for your query so you will have all the data you need.If you have any links between Work Items that you wish to preserve then it needs to be a Tree Query. At this point I will assume that you have planned this ahead and you know which WIs you want to migrate with what columns.You may need to play around with the query to get what you want.
Step 2: Copy and Save your Query to your Target Project
We have the query to export our data but now we want to move this query to our target project so we can import the data there.
Open the Source Project in Visual Studio Team Explorer and navigate to your newly created query.
Right click on your query and select Edit Query. Now select File->Save As…
We want to save our query to a file (*.wiq), somewhere in our local machine where we we can find it easily. Open the file in a text editor of your choice (I like Notepad++).
Edit the Server URL if you are moving to a new Server, edit the Team Project Collection name if you are just moving to a new collection and edit the Team Project name in the .wiq file and save it again.
Now right click your query from Visual Studio and select “Open in Microsoft Excel” .
Now open your Target Project in Visual Studio and Select File->Open->File…
Navigate to your *.wiq query file.
Select Save As…
And select your new project as the target server. The query should now be available in the target Team Project.
Now right click this new query in your target project and select “Open in Microsoft Excel“.
Copy the data from previously opened excel from source project query to the new excel opened from target project query. Modify any column or field needed if you are migrating to a project with different process template.
When we hit Publish on the Team menu, new Work Item IDs will be generated for us in the new project
Now we need to alter some things like the Work Item State. The TFS Process Template will not allow us to create Work Items in a non-starting state so our items will be New or Active for example. We need to filter on the Old States we want to edit.
Now we see only the items we need to change. Change and then fill down the value in the State column and publish back to TFS. Repeat the process for all the states returned in your query
You will also need to come back and do this for things like Area Path and Iteration Path if you haven’t already created them in your new project. Just save this spreadsheet and you can refresh and publish from/to TFS anytime.
Now we have successfully migrated our Work Items from one project to another.
I recently ran into a TFS user who was trying to create a new build definition for his project. When he check the Process part of the build, no Build process template shows up in the drop down list, And if he tries to download a template, he gets error that the template already exist for that project.
After investigating a while, I came across the TFS group which he was a member of. This group had below two permission “Deny” for Build.
“Deny” permission supersedes all other permission set for any role or permission. You can find this by going to “Build” section of your project and selecting “Security” from the “Action” drop down. And then set “Allow” for above two permission.
This resolved the issue user was facing and able to see and add Build process template to new build.
Have you ever faced an issue where you need to modify or edit a build definition which was create using VS 2010 for TFS 2010 or before? When you try to edit the “Configurations to Build” section of your build definition, you might see some error such as below.
Before you can work with TFS 2010 build workflows you must add a few assembly redirects to Visual Studio 2012 configuration files to enable it to communicate properly with TFS 2010. This section explains how to do that. You will need local administrative privileges to be able to do this.
Navigate to “C:\Program Files (x86)\Microsoft Visual Studio 11.0\Common7\IDE\”
Open devenv.exe.config file in a text editor and navigate to the “assemblyBinding” section.
Add the following assembly redirects as last elements inside the “assemblyBinding” section.
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”