I want to use a .MPP MS Project 2007 plan which has not yet been mapped to work items in TFS, the TFS project is empty, I mean that there are no work items at all. I want to synchronize with http://localhost:8080/tfs/ so that I can transfer my entire business plan to TFS work items, but this is not working. I have tried doing this:
Open VS 2010 shell:
witadmin importwitd /collection:http://localhost:8080/tfs/ /p:"MyProject" /f:"Z:\task.xml"
but I still can't publish to TFS in MS Project, I get this error:
TF80006: Team Foundation needs a work item type to publish work items. Select a work item type for the work items you have added and then try again.
How can I fix this?
I have resolved this issue:
Download and install the Team Foundation Server Power Tools plugin for VS2010 here.
Under Tools > Process Editor > Work Item Types > Open WIT from Server to obtain the work item type from a TFS project on your TFS server. I selected "Task".
Publish again, this time edit the lines that have validation errors. The fields in yellow will have to be changed accordingly. Or, you can disable validation by following these steps.
One of gotchas that bit me was that I did not set the Work Item Type in Project. Once I set it to 'Task' I was able to publish my schedule to TFS.
Related
I will start by saying that I am not a developer, I use Visual Studio only for TFS as a means of contributing to Work Items in our project (I am a product owner).
On TFS web, there are some fields we have that give us a multiple-choice made up of a number of checkboxes. In the Team Explorer / Work Item view in TFS, these fields do not work and give me the following error:
Could not find a part of the path 'C:\ProgramData\Microsoft\Team
Foundation\Work Item Tracking\Custom
Controls\16.0\GLMultiValueControl.wicc'.
I assume what is happening is that this file defines the allowed values for this field, however the file isn't there. In addition, the following directory doesn't exist either:
C:\ProgramData\Microsoft\Team Foundation
Is there some command I need to run to synchronise my local copy of TFS with the server? I find it surprising that the Team Foundation folder doesn't exist, maybe I've missed something with the installation?
I have a PBI in TFS under ProjectA with an iteration and area value filled in. Is it possible to move this PBI to ProjectB without creating a new PBI?
I am not seeing a way in the Visual Studio UI to do this. If I try to manually type in the area path of ProjectB, Visual Studio says that the path cannot be found.
I am using Team Foundation Server 2013 and Visual Studio Ultimate 2013.
No. Work items cannot be moved between team projects.
The reason is simple: The process template of the team project defines the work items. Team projects can have different templates. What if you tried to move a work item from a team project using a Scrum template to one using a CMMI template?
I would go a little deeper and say that if you need this feature then you should not have two Team Projects in the first place.
http://nakedalm.com/one-team-project/
The term that I use is:
"If you have artifacts that interact, with artifacts defined as people, code, or work items, then they should be in a single Team Project"
http://nakedalm.com/creating-nested-teams-visual-studio-alm/
Using a single Team Project can give you many more capabilities at the backlog/ work tracking perspective. Like the nested teams described above.
EDIT: This does not work for TFS2017 and forwards.
Yes, see http://www.codeproject.com/Tips/1018002/Yes-You-Can-Move-TFS-WorkItems-Between-Projects for a downloadable utility, source and a more detailed explaination.
It is a backdoor, SQL Manager approach, not supported by Microsoft, but it works for me. Here is the SQL:
UPDATE [Tfs_xxx].[dbo].[WorkItemsAre] SET AreaID=#AreaID,IterationID=#IterationID WHERE ID=#WorkItemID
UPDATE [Tfs_xxx].[dbo].[WorkItemsLatest] SET AreaID=#AreaID,IterationID=#IterationID WHERE ID=#WorkItemID
UPDATE [Tfs_xxx].[dbo].[WorkItemsWere] SET AreaID=#AreaID,IterationID=#IterationID WHERE ID=#WorkItemID
With the Tfs_xxx being replaced with Tfs_<your collection database name>.
Essentially, the project is inherited from the Area and the Iteration. Changing these from the current project to the target project causes the workitem to "move" to the target project. Additional rough edges are that the assignment pool or the workflow states might not align and have to be edited mannually in the UI to get the workitem back in the flow of the target project.
See my related answer.
Though not applicable to TFS on-premise, one can now do this with Azure Boards in Azure DevOps.
I'm trying to migrate from our on-premise TFS (2013.2) to Visual Studio Online (VSO).
One of the requirements from VSO is that you cannot use customized process templates.
My predecessor added few fields to few work item types wich I now have to remove, I don't care if I lose the data in those fields, just keep the standard ones.
I've tried few suggested methods but I'm not familiar enough with TFS to understand what I am doing :)
How can I remove those customizations?
I'm using OpsHub and following this guide: http://www.visualstudio.com/get-started/migrate-team-projects-vs
You need to do a few things...
1) identify your process template
User Story = MSF for Agile
Requirement = MSF for CMMI
Product Backlog Item = Scrum
2) Connect to VSO and download the relevant process template.
3) Use "witadmin.exe" to upload the defaults for Work Item Types, Categories, and Process
You should then be on a comparable template.
Since you are using OpsHub Migration Utility. During the Validation process it will show you the list of mismatches.
For the validation to succeed, you will have to delete/destory those fields. (Warning : You will lose all the historic data for that field)
For deleting the field, you can use the Visual Studio Power Tools (https://visualstudiogallery.msdn.microsoft.com/dbcb8670-889e-4a54-a226-a48a15e4cace). Install the tools relevant to your Visual Studio version and once they are installed, from the Visual Studio select Tools > Process Editor > Work Item Types > Open WIT From Server.
Here, connect to your TFS on-prem and select the Entity one-by-one as shown by the OpsHub Utility for having the mismatch. And delete the custom fields in question and save.
Click on Re-Validate in the OpsHub Utility. It should pass, if all the mismatched as shown before were taken care of through the above process.
Now, in case you want to destory the field you can use the witadmin deletefield /collection:http://localhost:8080/tfs/DefaultCollection /m:field-reference_name command.
I have an TFS server installation that through time has gone through upgrades from TFS 2005 to TFS 2008 and then to TFS 2010.
During the lifetime of the installation a lot of projects have been created and different project templates have been used. MSF Agile 4.0, 4.1, 4.2 and 5.0. and a few MSF CMMI ones.
What I would like to do is "replace" the project template used for all these projects to use a new one common one: Microsoft Visual Studio Scrum 1.0.
I am aware that TFS project templates are used as templates for creating new projects and cannot modify the tfs projects definitions after creation.
Uptil now only the version control and build server part of TFS have been used and there are no existing work item types.
Additionally all projects and build scripts are depending on the source code paths stay the same.
As I see it I have the following options:
Create new TFS projects using the correct project template and then move/branch the source code to the new project.
All code is moved to a temporary team project.
The old project is deleted
New project with the original name and correct process template is created
Code is moved to the new team project
Temporary team project is deleted
All the build definitions needs to be to recreated which is not an option.
The source code move/branch will "mess up" the versioning history
By messing up the versioning history I mean that when you move source code it will behind the scenes do a delete + source rename on the original location and the history will still be located in the old project. This will make searching in the history difficult and if I actually delete the old project I will loose all the history before the source code move.
This is really not an option for me since there is years of code change history that is needed to for supporting the different applications being built.
Use the TFS migration tools to migrate to another TFS project
This has the same downsides as the first solution
Replace/import work item types, install new reports, create new SharePoint sites
For each tfs project
Delete existing work item definitions using "witadmin deletewitd"
Import each work item definition from the new process template using "witadmin importwitd"
Import work item categories using "witadmin importcategories"
Delete old reports in project folder in report server
Upload the report definitions from the new process template
Modify data sources used for the reports using the report manager to point to the correct shared data sources (TfsReportDS and TfsOlapReportsDS)
Modify the report parameter ExplicitProject default value to "" (empty string) and disable prompt user option.
Export the documents in the old SharePoint site using stsadm
Delete the old SharePoint site
Recreate the sharepoint site using the TFS2010 Agile Dashboard site template
Activate site feature "Team Foundation Server Scrum dashboard"
In TFS Project Settings -> Project Portal Settings: Enable "team project portal" and ensure the url is correct. Enable "reports and dashboards refer to data for this team project"
And finally..
Process the Warehouse
Process the Analysis Database
Even though that this involves a lot of small steps this looks more appealing because
this option will not force me to move the source code and my existing build definitions will be intact.
My question:
Are there other ways to achieve the replacement of work item types that I haven't mentioned?
And/or am I missing any steps in last solution?
Given that you aren't using any existing work item types, your final proposal looks like the best option.
After deleting the old reports and exporting the SharePoint documents (you could also use Windows Explorer instead of stsadm), there are actually two commands in 'tfpt' that will help you. This will reduce it from 14 steps down to 5 or 6 steps.
tfpt addprojectreports Add or overwrite reports for an existing team project
tfpt addprojectportal Add or move portal for an existing team project
tfpt addprojectreports /collection:http://yourtfs:8080/tfs/YourCollection /teamproject:"Your Team Project" /processtemplate:"Microsoft Visual Studio Scrum 1.0" /verbose
tfpt addprojectreports /collection:http://yourtfs:8080/tfs/YourCollection /teamproject:"Your Team Project" /processtemplate:"Microsoft Visual Studio Scrum 1.0" /verbose
Your first option is IMHO your best shot.
You can branch the sources from the old team project to the new team project. With TFS 2010 you can see the history also from the branched location. So you don't loose functionality in here.
The Build is just an msbuild file which is stored in source control. The only thing you have to do is actually copy the build definitions. You can do that either manually, or you can create a little app that does that for you.
Is there a chance to delete Work Item from TFS, or all I can do is just to rename it.
Update:
This question was for TFS 2008.
New version (2010) have out of the box solution as Rob Cannon suggested
The answers here are obsolete for TFS 2010. You need to use the 'witadmin destroywi' command now.
http://msdn.microsoft.com/en-us/library/dd236908.aspx
See this tool: http://devmatter.blogspot.com/2009/04/deleting-work-items-in-tfs-ui.html
the Team Foundation Client does not include any functionality for deleting work items from TFS.
Although it’s a tad inconvenient, you can delete work items from TFS by installing the Team Foundation Server Power Tools (October 2008 release or greater). Of the many features available as part of the power tools, there is a command called destroywi that can be used to delete work items. For example, to delete the work item ID 1234, use the command:
tfpt destroywi /server:tfs-dev /workitemid:1234
Although this is a relatively straightforward task to perform, not everyone is comfortable with the command line interface not to mention you have to look up the work item ID(s) ahead of time. To ease the process a little bit, I created a simple UI that sits on top of the Team Foundation Server Power Tools that allows you to easily select a Team Foundation Server and Project to query from. You can run an existing query to display a list of work items from which you can select one or more work items to be deleted. You can also enter the work item IDs directly (as a comma-separated list) if you prefer...
No one added code or an example, so here is my re-iteration of this answer using Rob Cannon's answer as guidance above.
This is batch file code for accomplishing this task. You will be prompted before you actually delete your Work Item.
ECHO OFF
SET "VSDir=C:\Program Files (x86)\Microsoft Visual Studio 11.0\Common7\IDE\"
CD %VSDir%
SET /p WorkItemID=Enter Work Item ID:
ECHO.
witadmin destroywi /collection:{TFS Server}/{Collection Name} /id:%WorkItemID%
ECHO.
PAUSE
Enjoy
If you want to do this without using the tool suggested in the accepted answer, here is a quick summary of what to do. This is based on the corresponding MSDN article suggested in another answer.
Open Visual Studio Command Prompt:
Using the start menu:
Search for it.
Or navigate to All Programs -> Microsoft Visual Studio X -> Visual Studio Tools to find it.
Invoke witadmin
Determine the team project collection URL. An example is http://ServerName:Port/VirtualDirectoryName/CollectionName.
Determine the work item id.
Invoke the following command, substituting the two above values:
witadmin destroywi /collection:CollectionURL /id:id
See the MSDN article for more details. Note that you need permission for this to work.
You have to use the TFS Power Tools.
http://msdn.microsoft.com/en-us/vstudio/bb980963.aspx
1) As mentioned above the destroy command (pretty tiresome if you have to delete more than a single item)
2) With TFS 2015.2 you get a new recycle bin function (without an option to permanently remove the items).
https://www.visualstudio.com/en-us/news/tfs2015-update2-vs.aspx#delwork
But since they dont appear anywhere (replaces the "Removed" State) and they can be restored ... compared to the fact that it took since 2008 to add the bin feature .. pretty neat id say :D