Allow in the standard work item, that the description includes screenshots.
A very basic use case for a bug tracker is: describe a problem with a series of screenshots showing what happens.
"I click on the menu X and select the chevron"
[screenshot]
"Now I drag the right hand side and the layout gets messed up"
[screenshot]
If I drag it back again the layout partially restores
[screenshot]

I know you can attach screenshots, but this is very clumsy and completely separate from the description.

For bonus points
- allow some simple formatting
- provide a trivial image editor to allow cropping and highlighting pieces of the image without using another application.

From what I understand it might be possible to do some of this with a lot of custom development. That's not very interesting to me - I'm interested in the out-of-the-box experience covering common use cases.

What I really want to do for example: in case that the task assinged on "mm/dd/yyyy" is not comleted before "mm/dd + 7/yyyy", the alert notification should be sent to the "assigned to" person of that task and to somebody else (I call it workflow manager, the person who is responsible for the project).
In my humble opinion, client alerts are pretty useful for a strong team of developers but it would also be a great step forward if there is a branch of manager alerts such as described above.
To summarise, I wish I could easily manage team alerts using "workflow manager" role according to current date, iteration, product life cycle etc.
Thx, Kirill.

Right now you can setup continuous deploy for a Team Project to a hosted service if the Version Control is "Team Foundation Version Control" but If the project is using Git, then you cannot set it up. The reason we want this is because we would like to have all are Team Projects in one type of version control, but we are having hard time getting are developers to be able to work work with TFS on Mac's (git tf works fine, but getting tf to work on mac's is more work then it is worth, having to down grade Java). We do a lot of Azure hosted service work, but a lot of the clients for the service that we make are Mobile Apps. We would like to be able to develop both Azure hosted services and iOS app's using the same Version Control. If publishing to Azure hosted services worked we could then us all git everywhere!

I want to delete a project from the TFS that I created on the ***.visualstudio.com website, where "***" is the name of my TFS Team Collection site but there is not a way to do it. If the only way is to use "tfsdeleteproject", how can I pass my credentials using command prompt?

Suggestion: If I'm in the "Team Foundation Project Collection Administration Group" it should allow me to delete the projects as easy as it allows me to create a new one by using the interface at the website.

Please, help me on how I'm able to delete a project.

Thanks,
Rogerio Santana

When you drag a work item onto the related work item area or add it via the ID it then is used when you do a check in to associate the changes to that work item. I may be abnormal in my usage of source control in that I check in *VERY* frequently. Usually after I get a few unit tests passing I'm checking in. This means that throughout the day I may check in a dozen or more times and really want to associate all those checkins to possible the same work item (story).

Currently, once you do a check in it clears the related work item. I can understand that this makes sense for most people, but is there a way to have it not clear the work item after a check in? For example, a switch or checkbox to say keep this related work item here so that the next set of changes I do are also associated with it?

What I'm doing now is having to keep the query results window up and after each check out I have to find the work item and drag it back into the related work item section.

Source Control Explorer list only fice columns (Name, Pending Change, User, Latet and Last Check-in).
Please add more columns, like Last Modified Date, History Present, etc. that will allow us to see the last modifeid date of the file and not just the date when the file was checked in to source control.
The excellent example is, when you move the files/folders around within Source Control, you are forced to check in the changes, which is every file in the project. Resuling into the same check in date for all files and folders within the project. Now I have to review the history for entire project to find out which file was modified last.

There are various scenarios with generated code that produce SCA violations. It would be usefull to have an easy and robust way of suppressing those warnings. The current solutions are not suffcient:
- The 'GeneratedCode' attribute supresses at the class level. That means all violations in the non-generated part of the class are also supressed. It also means you have to re-enter it every time the generation is re-done.
- The SuppressMessage attribute forces you to manually suppress all SCA warnings on the generated code.

The solution provided by StyleCop (if #region contains tekst 'generated code' then suppress all warnings from that region) is more fitting to most code-generation scenario's.

Please built support for this into FxCop / TFS / Visual Studio