We're looking into migrating to TFS 2010 in the next few weeks. However, we're unclear on what kind of tools are required for the team. We know developers need Visual Studio but what tooling is required for Project Managers and Testers that will ONLY need to manage work items? Do they also need Visual Studio to just view and edit work items?
Project Managers and Testers can use the following methods to access TFS 2010
The web access portal - this allows the ability to create/run queries of work items, and even view source/builds if they want
Excel/Project - Both have integrate with TFS. You are able to load work items directly into Excel/Project, edit them, and publish them back to TFS.
Visual Studio with Team Explorer only - This is a barebones installation of VS, with the Team Explorer only. It doesn't take all that long to install, but it will say "Visual Studio" when launched. Not sure if that is scary to testers/project managers.
Web access provides a good complete set of functionality, but having VS/Team Explorer will provide a rich client experience (read: faster, more responsive).
Additionally, in order to get the Excel/Project integration, you'll need at least the VS/Team Explorer installed on the client box, even if they never use VS. And you need a CAL (Client Access License) to use the web access portal.
So to summarize, TFS provides a lot of ways for the non-developer to interact with the system, but all of them require a CAL, and most of them require installing VS/Team Explorer on the client machine.
In short, they don't need Visual Studio. They can use Team System Web Access (formerly known as TFS Web Access) to do pretty much everything a developer can do, except associate a check-in with a work item. After you install TFS 2010, you simply browse to http://yourserver:8080/Tfs/web and you're in!
Project Managers (and all other team members) can also work with work items from Outlook using 3rd party TFS client embedded in Outlook: TeamCompanion www.teamcompanion.com. This way, assuming they otherwise use Outlook, they wouldn't need to change tools or use any additional tools at all.
As is the case with Excel or Project integration they would still need a TFS CAL and additionally a TeamCompanion license.
TeamCompanion supports much more than just work item management: Email/TFS integration, SQL Server Reports, SharePoint document integration and much more...
Full Disclosure: I am the Product Owner of TeamCompanon, so I may be biased :-).
There is a web front end which you can use to manage the work items. There is also integration to Excel and MS Project.
See http://msdn.microsoft.com/en-us/library/ms181304.aspx for more information on Team Foundation Clients
Related
How do I view and integrate with GitHub issues using Visual Studio 2022?
When connected to an Azure Repo, the VS Team Explorer window includes a "Work Items" view that shows open issues from Azure Boards. I can easily create a branch from one, link it automatically, and submit pull requests. The integration is great.
When I connect to a GitHub repository, that integration is lost. The Team Explorer window no longer contains a "Work Items" view. Since I can't view the issues, I can no longer automatically create branches that are linked to the issue. I have to now manually type in the issue number if I want to link a commit to the issue. And the "Create Pull Request" menu items simply launches the browser to the GitHub page; there's no integration there, either.
I have found a VS Code blog post that enables a lot of this functionality (and more) into VS Code, but I've yet to find anything for Visual Studio 2022. From that post, I am most interested in the "Working on issues" bit. As described above, this was functionality that worked with Azure Repos but is lost with GitHub integration. How might I regain that functionality with GitHub and Visual Studio 2022?
The "old" team explorer did a number of really nice things, but it was also very hard to integrate into for other tool vendors. With the new Git experience the Visual Studio team opted for a more agnostic approach.
The old Team Explorer was written in .NET 4 and was very much geared towards integrating with Azure DevOps. It stems from 2005 when Team Foundation Server first got released. Over time other vendors snuck their way into Team Explorer, but mostly through undocumented and unsupported ways. This has caused many interesting issues in the past. The concept of the Team Explorer window also wasn't ideal for hosting GitHub, Azure DevOps, BitBucket and every other tool-vendor that wanted to be listed and there was very little in the way of control for users to set the order of elements or hide certain tiles. As such it's a breeding ground for bugs and it needed to be ported to .NET Core and x64 and to support out-of-process extensibility to properly support Visual Studio 2022 anyway.
So Team Explorer and its old undocumented extensibility points were dropped and the new Git Window was born. This window is a pure git client and it's vendor agnostic. Vendors may add menu items to the top level menu, but they currently can't extend the new git window.
At the same time, Visual Studio 2022 dropped support for the built-in browser window, which was a memory hog, loads IE11 and also needed full retooling to support the x64 out-of-process loading that Visual Studio 2022 now demands.
All of this work now allows Visual Studio to use more memory, it's faster and by moving extensions out-of-process, it has greatly improved the performance and stability of the visual studio platform. Unfortunately this all happened at the expense of some features.
The new git experience is no longer constrained by the Team Explorer window, is a top-level citizen in Visual Studio and can finally use easier to remember keyboard shortcut keys. It's much faster too and the new architecture allowed the team to build interactive rebase, multi-repo support, submodule support and more. But their priorities have been in advanced git scenarios for a long while, not in building support for vendor specific issue integration. It looks like that may be changing though. Auto-completion of #... is now in Visual Studio 17.5 preview:
Some tool vendors may invest in native integration into Visual Studio in the future. Many old extensions are no longer available in VS2022 or the authors are still working on a new version that conforms to the new requirements.
On the other hand you have VS Code, which is used by GitHub itself internally, runs in a browser, powers github.dev and github codespaces and doesn't carry the legacy if Visual Studio 2022. It's not Microsoft, but GitHub who has extended vscode and they added the support for their platform through extensions and open source contribution to the editor directly. GitHub has a different stake in vscode, they have the engineering staff that knows how to extend atom-based applications (they basically built that technology) thus, their features have been added to vscode.
Is it fair? Do we want it in big VS as well? Sure, but unfortunately, that's currently not where the money is being spent.
There are a few ways to accomplish what you want. But none are exactly what you desire.
The web
The main way is to start working from the browser. On every issue there is a Development section from which you can create a branch or initiate a pull request from the associated branch:
You can then immediately check it out locally
Or navigate to the code panel for the branch and click the open in visual studio link. This will launch visual studio in the correct context using the repo you selected and will check out the branch locally for you to start working.
Any commits you make to this branch are automatically associated to the issue, so there's no need to pass in the #issuenumber every time.
The cli
An alternative to working from the browser is to use the CLI. If you have the GitHub CLI installed it will pick up the context of your repo from the list of remotes and you can perform quick commands straight from visual studio's built-in terminal.
gh pr create
to create a new PR.
gh issue list
to quickly list your open issues
gh issue develop #issuenumber
to create a branch on the remote, associate it to your issue and check out the branch locally.
It takes a bit of getting used to the commands, but if you like the CLI it's a quick way to work.
In Visual Studio
You can create pull requests from your current state, which will then bring you to the browser with most of the data pre-filled. Issue auto-completion also works in the browser from that point forward.
To get the other features you want, you must install extensions. Unfortunately, GitHub has stopped development on the old GitHub for Visual Studio extension since most of its features have now moved into visual studio. It's not easy to build and maintain an extension for multiple versions of Visual Studio, so I don't expect this will be brought back to life.
I rely on the Git Web links extension to quickly switch between web and visual studio from the context of my working files:
In the settings you can set the default behavior to not copy, but to open in browser.
Other functionality you're after is currently not available through a publicly listed extension. Most of there features have also been removed or deprecated for Azure DevOps itself, so I don't expect the Visual Studio team to be in a hurry to add first-class support for Issue tracking back in.
Unfortunately, the "Work Items" view and the related issue integration for GitHub Repos is not currently available in Visual Studio 2022 out of the box.
You might be able to find a Visual Studio extension that provides this functionality, but I'm not aware of any off the top of my head.
An alternative option would be to use the GitHub API to retrieve the issues, and create a custom extension to display the issues in Visual Studio 2022. However, this would require custom development work on your part.
It seems like the VS2022 will have this feature in future (it's in Preview now).
https://youtu.be/0NiHvdoMBO8?t=95 [VS2022 Preview Feature]
Visual studio 2013 has its own accessibility validation, to check the accessibility one has to click on the tools menu, then click Check Accessibility, my question is: it is possible to make this validation automatically with MSbuild or with another tool?
Thanks
I need to check websites (MVC projects)
You may also want to look at tenon.io (http://tenon.io/), they have an extension for VS2013.
Tenon differentiates from all the other tools by providing an API which can be leveraged to integrate automated testing in to the development process.
Karl Groves says it better than I could:
All of my projects use Grunt, ... Tenon automatically performs unit testing on its own code. When something goes wrong, Grunt stops and yells at you. You can even tie Grunt to pre-commit hooks. In such a workflow nothing goes live without all your Grunt tasks running successfully.
Imagine, an enterprise-wide tool that can be used in each phase, that works directly as part of your existing workflows and toolsets. Imagine tying such a tool to everything from the very lowest level tasks all the way through to the build and release cycles and publication of content. That’s why I created Tenon.
While Tenon has a web GUI, the web GUI is actually a client application of the real Tenon product. In fact, internally Asa and I refer to and manage Tenon as a series of different things: Tenon Admin, Tenon UI, and Tenon (the API). The real deal, the guts, the muscle of the whole thing is the Tenon API which allows direct command line access to testing your code.
The beauty of Tenon is that because it is essentially an API, it can plug in to anything, Sublime, Webstorm, Netbeans, Notepad (probably not), Visual Studio!
Tenon.io Visual Studio add-on, compatible with 2013/2015 and 2013 Community Edition
http://blogs.msdn.com/b/visualstudio/archive/2015/03/03/improving-html-accessibility-with-visual-studio-extensions.aspx
The only catch, it’s not free for corporate users and it’s in the cloud (unless you pay Enterprise pricing for a local install). Pricing info: http://www.tenon.io/pricing.php
Karl Groves writes about his motivation for creating Tenon: http://www.karlgroves.com/2014/03/13/everything-you-know-about-accessibility-testing-is-wrong-part-4/
I think you need the AccChecker Console
https://msdn.microsoft.com/en-us/library/windows/desktop/jj191809(v=vs.85).aspx
If you want API access to this you should read AccChecker API
https://msdn.microsoft.com/en-us/library/windows/desktop/jj191808(v=vs.85).aspx
Overview here:
UI Accessibility Checker
https://msdn.microsoft.com/en-us/library/windows/desktop/hh920985(v=vs.85).aspx
The closer solution I have found so far regarding this topic is in Visual Studio 2015 by adding the Web Accessibility Checker extension from Mads Kristensen, which is also free. The extension can be found at the Visual Studio Marketplace website. You can see the usage instructions within the description of the extension. This is an example of what you get once build the solution and tap on the Error List panel:
I hope can help.
We are implementing Team Foundation Server for a better alternative over Microsoft Office for Work Item Tracking, Requirements gathering, etc. I am thrilled to have our team implement this, as I have used it in many of my past projects. That said, we are having some logistical problems implementing the solution.
One of my team members is a blind developer. He can successfully develop using SQL Developer, Eclipse and other programming software. However, we are having difficulty figuring out the Team Foundation Server interface using JAWs and pure keyboard access.
We originally tried to use the Visual Studio Online interface, which proved to be completely inaccessible. He installed the Team Foundation Server client, which seems to be significantly more accessible, but it is still difficult to navigate, especially with multiple panes of information and navigating between the sections of functionality.
We searched online for keyboard shortcut charts, accessibility, etc. and have found a few resources. However, none of them have solved the problem yet. Do any of you have any suggestions for how to make it more accessible? Is there a keyboard shortcut scheme for accessibility that we can interface? Have you found any good resources online for accessibility shortcuts with Visual Studio Team Foundation Server clients?
Thank you for your help. We are up for any solution, whether it be a Team Foundation Explorer Everywhere plugin, standalone clients, etc.
We do have keyboard shortcuts for the clients. For Team Explorer (standalone or VS), you can find the list at http://visualstudioshortcuts.com/2013/. We also do accessibility testing for TE/VS, including with JAWS. I watched a video in October that one of the teams had put together to show improvements that they had made. The before was pretty bad and the after was significantly better (and doing the work was motivated by another team at Microsoft who pointed out the shortcomings in trying to use it). The changes went into Update 4 of VS 2013. That's going to provide the best experience we have available. Please give that a try, and let me know what you think.
[Update] Also, we have a handful of key bugs in the web UI that we are working on that in the next month or so will improve the web UI experience in VSO and TFS 2015.
[Update] Here's a list of the current shortcuts, which includes both the web UI and Team Explorer.
Just wanted to post this for others researching this issue. I am a blind programmer who uses the jaws for windows version 17 screen reader. The corporation I work for just installed team foundation server 2015 for teams to use as a scrum project management tool.
The web interface is not useable by me. While some of it is accessible, meaning some links and web page elements are spoken to me and can be clicked, it is not useable in a practical sense. The entire web interface is a drag and drop interface that requires the use of a mouse and does not have any keyboard support to drag and drop items. For example, dragging PBI's into a feature or sprint is not supported by the keyboard or web page elements like html buttons you could click to move PBI's from the back log, to a sprint, to in progress, to completed, etc.
In aiddition, the tree control used is not accessible and is used for quite a bit of web page tasks. I think the tree control used is probably a jquery or javascript item.
The visual studio 2015 team viewer option is somewhat accessible, but it does not appear to allow you to perform all the tasks that the web interface does perform. For example, creating features, creating sprints, moving PBI's into a sprint, etc. If those options are present, and are accessible, I cannot find easily how to do it using the vs 2015 team viewer client.
Overall, while some of the features in the vs 2015 client and also in the web interface are spoken, tfs 2015 is not useable in a practical sense and does not allow a blind programmer to be as fluent as a sighted person using the tfs system. So at this point, I am not able to use the tfs system and must rely on sighted team members to key in my PBI's and drag / drop and create sprints for me. Very disappointing.
Main issue: I need to develop an automated way to create new SharePoint pages when an item is added to a SharePoint list. For example, we have a list of projects, and when a new project is added to the list, we want a custom website for that project to automatically be created from a template.
What I've tried: I have been researching this a lot, and it sounds like SharePoint Event Receivers can do what I need. So I got Visual Studio (both Visual Studio and SharePoint are 2010). However, I still cannot automate my child pages. I get an error message when I try to do anything SharePoint-related in Visual Studio: "A SharePoint server is not installed on this computer. A SharePoint server must be installed to work with SharePoint projects."
My organization is not big on new software, so getting more than Visual Studio is probably not possible. In addition, I will not be granted admin rights, so I don't know if I will even be able to use Visual Studio. (Also I'm pretty sure my SharePoint is not locally installed, but I don't know much about software set-up/configuration...I just want it to work so I can code!) I do have full rights to the SharePoint site, so that shouldn't be an issue.
Is there a way to solve this issue with only coding in SharePoint? Or is there a way to do it with just Visual Studio (non-admin) and SharePoint?
In order to develop solutions for SharePoint 2010 you need to have SharePoint 2010 installed on your dev machine. You can install SharePoint 2010 Foundation which is free.
Before you start development you need to decide which kind of solution you gonna create - sandboxed solution or farm solution.
Sandboxed solution has some limitations in functionality but you do not need admin access to the server to deploy it, only site collection administrator rights on site collection.
On the other hand farm solution allows you to use any available SharePoint object model APIs. But to deploy it you need to have admin access to the server (or at least IT guy with admin access who can run some ps scripts).
The decision mostly depends on what are you going to develop. If you have some requirements which do not fit for sandboxed solution then you have to go with farm solution.
From what you've described I think sandbox solution is enough.
I am developing an Isolated Shell that caters to "designers/special content creators" performing specific tasks, using the Shell. As they operate on files, they need to be able to use TFS for source control. This is mainly due to the fact that Developers will also operate on the same files from TFS but using Visual studio 2008.
After looking and searching I still could not find Team Explorer to be available to Shell.
Asking on MSDN forums, lead me to the answer that "this is not supported yet in the Isolated Shell". Well, then the whole point of giving away a shell is not justified, if you want to use a source control system for your files. The idea is not to recreate everything and develop tool windows etc using the TFS provider API.
The Visual Studio Extensibility book by Keyven Nayyeri has an example, which only goes so far into this problem of adding a sc provider.
Has anyone worked on developing Visual Studio 2008 Isolated Shell applications/environment? Please provide comments, questions - anything that you have to share apart from the following threads, which I've already participated in.
Threads from MSDN forums:
Team Explorer for Isolated Shell
Is it possible to use Team Explorer in VS Shell Isolated?
Thanks for your answer. Yes you are right, we will acquire CALs for users without having to buy them Visual Studio, that's the direction we will be taking.
But I am yet to figure out how to make Team Explorer available to such users, inside Shell. So I am looking to find out the technical details of how that can be done.
I mean, I have a user, he installs my VS Shell application, he has no VStudio Team system on his machine. Now if I acquire CAL for TFS and install Team Explorer, do you think it will be automatically available in the VS Shell app?
Any ideas? have you worked on making this happen?
Thanks
It sounds like you are trying to allow the "special content creators" save files in TFS Source Control without having to buy them a license to a Visual Studio Team Edition -- correct me if I'm wrong.
If that's the case, unfortunately I believe that you can't quite do that. Your users still need a Client Access License ("CAL") to access TFS.
I think that you can acquire just CALs for your users without having to buy Visual Studio for them (I presume for less than a full blown Visual Studio would cost). At that point, you can just distribute to them the Team Explorer, which is a VS shell with nothing but TFS access components. That is available in your TFS server media.
I found this via Google. You might want to review it to decide your best options:
Visual Studio Team System 2008 Licensing White Paper
The only exception to the CAL rules I'm aware of is access to Work Items. Assuming properly licensed servers, anyone in your organization can create new Work Items or view and update existing ones created by them, using the Work Item Web Access component.
Just stumbled on this question, it might still be relevant to you.
You have the option of including the AnkhSVN (http://ankhsvn.open.collab.net/) packages and load it into your Isolated Shell. While there are some issues around it, with Subversion support, you could use SvnBridge to access TFS repositories. This might bring you a little bit closer to the process you are trying to achieve.