We use Team Foundation Server (now Azure DevOps) in conjunction with Visual Studio as our version control system.
I am our teams ssrs report developer and, unfortunately, sometimes throughout the course of my day I'll be working on multiple projects and will have a report checked out, however I'm unsure what changes I might have pending (it could be something actually valuable for production, or just something I was testing). Is there a built in way to compare pending changes to the code vs the current saved version?
Per Daniel Mann's excellent comment, the answer is very simple. Right click > Compare!
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]
How to customise I have knowledge to customise process template in tfs 2015 or in 2012 but for upgrade version in 2017 is there any changes or any enhancement.
I have find in google but I have not found any helpful to customise process template in 2017 specifically.
your help should be appreciated. thanks
The first step is you need to download the process template you want to edit from you TFS server. To do this, launch Visual Studio and navigate in the menus to "Team -> Team Project Collection Settings -> Process Template Manager". When the dialog shows up, you will be able to select the template you wish to edit and download it. Detailed instructions for this can also be found here.
Once you have downloaded the process template, you have a series of XML files that describe how TFS should handle almost everything when you create a new project using that template. The XML can get overwhelming quickly, even for the most seasoned person. You should ideally use the Process Template Editor which is a plugin for Visual Studio (the link is for Visual Studio 2017). For details on customizing a template, you should start off by reading the Customize a process template on the Visual Studio documentation site.
Once you've made your changes, you simply need to upload your process template back to the server using the Process Template Manager (where you downloaded the template). If you replace an existing template, anything using that template will get the updates. If you create a new template, only new projects using that template will be able to make use of it.
Not much has changed with editing the process templates between TFS 2013, TFS 2015 and TFS 2017. So if you find a blog or a write up on one of the versions, there is a good chance it's still valid. There may be slight differences in UI, but there shouldn't be anything ground breaking.
DISCLAIMER!!!
Now that I've answered your question, I would be negligent if I didn't explain the dangers of what you are about to do. Customizing a TFS process template can be very dangerous to your TFS server. Microsoft does not guarantee or put any warranty on changes you make. You customize a template, you are on your own. You have to understand that this template literally tells TFS how to work. It is highly recommended to have a sandbox environment complete separated from your production server and make all changes in said sandbox environment first. Only after you've validated the changes should you move it to your production environment. In addition, anytime you deploy a change to your production server, make sure you have healthy backups your databases. I can't stress this enough.
Lastly, any changes you make, you run the risk of locking yourself into a specific version of TFS or making your upgrade path far more difficult. My last piece of advice is to carefully weigh the need for customization over the risk associated with making it.
In my company, we are using Team Server Foundation 2010.
Last week when I was checking out some ssrs (sql server reporting services 2010) files, I obtained the correct files from TFS. I could see that the files were still connected to TFS.
However, I think there was a time last week where there was a message saying that I was working offline.
Now when I obtained the most current code from TFS, I do get the correct code. However I do not see that the code is connected to TFS any longer. Basically when using Source Control Explorer, I do not see that this code is linked to TFS
Thus I would like to know how to get my code back to accessed in TFS 2010?
Do you see the same problem with all files in TFS or only specific set of files?
Do you see this problem in only one workspace or in all workspaces on a single machine? Or does it affect all users?
What does it mean that files are not linked to TFS, can you post a screenshot?
TFS 2010 was quite weak story for offline and it worked only for solutions (as visible in Solution Explorer). Source Control Explorer always required connection to TFS
I'm also confuse about “files are not linked to TFS”you describle ,can you post a screenshot.
Simply offline mode means TFS 2010 goes offline (disconnect the connectivity properly between your local machine and TFS 2010 server) while your solution is already open though VS 2010.If you checkout files while you are in offline mode, then TFS 2010 source controls system doesn’t record or track any changes you made. But when you reconnect TFS server, the server will get you changes in pengding changes, then you can check in manually.
To get your solution back online to TFS you can try this solution:right-click on the solution name right at the top of the Solution Explorer and select the Go Online option.
More detail: How do I get my solution in Visual Studio back online in TFS?
You need to use the "go online" command to re-sync:
Cannot see go online option in tfs
Note: TFS 2010 is no longer supported and you should upgrade soonest
The company I work for recently started using TFS 2010 for version control and we have had some active discussions on establishing a check-out policy. Currently, we have Multiple Check-Outs enabled. This policy is enabled because, as a small dev team, we can always get together to discuss merge conflicts when they arise at check-in time. One thing we didn't reach a consensus on was getting the latest on check-out. Should we also enforce the "Enable get latest on check-out" policy? Does it go a long way in helping to ensure that we aren't editing out-of-date code?
It is better to leave it disabled because each user can enable this option locally in Visual Studio according to their preferred way of working by modifying their settings in Visual Studio (Tools Menu -> Options -> Source Control -> Visual Studio Team Foundation Server).
Most of the teams that enable this option are coming from a system that already behaved this way (Visual Source Safe, mostly) because they are comfortable working that way already.
I find most people want to explicitly control when their files are getting updated so others' changes don't unexpectedly mess up their flow when they might not be ready for the latest changes their team members had checked in ahead of them.
However, every team working with shared checkouts on an active project should be trained and aware that it is good practice to get the latest changes regularly, as it will reduce the amount of conflicts and confusion when they finally want to check in their work.
Consider getting the latest version of the code:
When you start working for the day.
Throughout the day if it is a really busy project
Most importantly, right before you check in your changes you should get the latest changes and then test your build.
When I launch a project on Visual Studio 2010, I have to wait 10 minutes while the "Updating Source Control Status" finishes at the bottom of the screen. Until this happens, Visual Studio is completely frozen.
I am connected via VPN, and I have enabled domain lookup for my tfs host. (http://www.codeproject.com/Questions/111260/VS-NET-2008-hangs-everytime-we-load-our-project-fr.aspx?tab=mostrecent)
I am not sure what else to do. Any ideas?
the simplest way to investigate is to enable tracing in devenv.exe (look at tf.exe.config and copy appropriate part to devenv.exe.config) and see what server calls are being made. I would recommend publishing results on msdn forum (http://social.msdn.microsoft.com/Forums/en-US/tfsversioncontrol) since TFS devs are monitoring it much closely than stackoverflow.
Good luck!
If you use yourtfsserver.visualstudio.com and the site is down (for instance like it is right now due to an Azure storage disruption) VS may freeze up on you when you open a new source controlled project or randomly while your in a project even it it isn't in source control.