A client was asking me this today so I decided to make a quick note and send a link :)
In TFS 2010 when trying to make Sequential builds (i.e. for one you have several interdependent solutions in your automation strategy) in the DefaultTemplate XAML file you have to change the
. It should be noted that this is a lot different than TFS 2008. In TFS 2008, in the TFSBuild.proj file the solutions were just ordered correctly and made use of the BuildSolutionsInParallel property. This also required changing the setting for the MaxProcesses in the tfsbuildservice.exe.config file on the build server to a value greater 1, and also to restarting the build service on the build server. This is a lot more cumbersome than changing the type tag mentioned above.
When maintaining a TFS environment where WI’s become crucial in terms of development artifacts, you may notice an issue with removed AD accounts causing a problem where WI’s are not privy to updates because the account has been removed from Active Directory. This becomes a huge issue because updates to the WI are no longer supported.
Generally, this will throw the error:
TFS Error: TF20015, stating that a field contains a value that is not on the supported list
This leads to the requirement where a developer, even though they have gone onto greener pastures, has an invalid account value, within a value restricted field. Bad news bear.
Fortunately, there is a supported route you can take with TFS in order to overcome this issue. Using the ALLOWEXISTINGVALUE rule allows entered value to still be valid even if that value is no longer a valid value. By customizing the process template work item types and use this definition for the field with invalid values.
Bada bing, good to go!
When users are using Team Explorer and viewing the group membership for a particular project (Team Project Settings -> Group Membership) it’s pretty easy because explicit users and groups are listed. However, this becomes a problem when you want to view all the users of that particular group. This is very, very evident when the groups are chained, i.e. Group X contains Group Y, which contains Group z, and so forth. This becomes an issue because viewing the security information for a particular security group becomes very limited.
Fortunately, to get around this limitation you can use the TfsSecurity tool, specifically the TfsSecurity /imx command, to get the direct members of the specified group.
It is important to remember that TfsSecurity.exe comes from Team Explorer, not the Visual Studio shell.