Team System Q&A
Okay, I'm a bit slow, and I haven't even sent off all the questions, but here's some questions that people asked in my recent travels and Team System Trainings and the related answers:
Q: Can you restrict who can change the FxCop rules on a project - if so, how?
A: No, this is not possible. (Chris comment - bummer)
Q: Does code that is generated via the typed datasets, etc. pass FxCop?
A: This is tough, I got some feedback that the generated code for typed datasets will have attributes to suppress FxCop errors (post Beta 2). I'm not sure how that works, but it should allow a check-in policy. It will be interesting to see if this is done in all generated code.
Q: Is anyone working on guidance for Project Server? It is known that it doesn't sync with work items- so what are the suggestions about what features of project server should be used, etc.?
A: There will be a white paper on this sometime this summer.
Q: Do work item associations stay for future checkins? The idea would be if I check out a file that was checked-in previously, that I would know about that relationship.
A:If you are asking whether the work items listed in the Pending Checkin tool window, the answer is no, they don’t remain checked. Once the checkin occurs, the work items contain links to the changeset and the changeset details dialog also provides those links. But checking out a file that was previously checked in with some work item association doesn’t result in that work item becoming associated again. It sounds like you are sort of after the work item history of a file. You can get that today with a little effort by simply browsing the changesets listed in the history for that file. Bring up Source Control Explorer and right click on the desired file. Choose History. For each changeset (row in the GUI) shown in the History tool window, double click it to get the changeset details dialog. Click on the work item channel. You can do the same thing from the command line using history dialog displayed by the history command.
Q: Can check-in policy be based on file type? Specifically, a students wants to force a code review scenario (not supported out of box) to only force the review for .CS files, not for XML, HTML, etc.
A: The policy plugin can do this for you, but currently there is not a mechanism to do this in the policy framework. It is a common request, though.
Q: How to handle exceptions in unit tests?
A: There is an ExpectedException attribute