My colleagues and I have several versions of Visual Studio installed which — for business reasons — we may need to keep for some time. For some teammates an inconvenient version of Visual Studio will open when cloning a git repository from Azure DevOps server, starting from this web UI:
How can we ensure the preferred version of VS opens upon/after cloning? As a bonus, would there be any way to configure this per repository?
So far the best we have worked out is to follow these steps. However it doesn't seem to consistently update the preference for every user. In particular, if a team member has already cloned at least once targeting an earlier version (e.g. VS 2015, VS 2017) we seem to have a dickens of a time getting an update of this preference to VS 2019 to stick.
Open “Default Apps” in system settings
Select “Choose default apps by protocol”
Scroll to “Microsoft Visual Studio Web Protocol Handler Selector"
Change handler to Visual Studio 2019
Note: Our machines have MS VS Web Protocol Handler Selector listed twice. We have experimented with setting both or either without success. Any suggestions why we're seeing the protocol selector twice may also help.
would there be any way to configure this per repository?
For this issue, I am afraid this is currently not achievable in azure devops.
As a workaround ,agree with James Z, you can perform cloning in a specific version of visual studio instead of from the web UI from azure devops, so you don't have to worry about the troubles caused by the default version. In addition , the MS VS Web Protocol Handler Selector icon for vs2017 and vs2019 looks almost the same, which is also easy to confuse.
Open a specific version of visual studio according to your needs, connect to your project in Team Explorer, and select the repo to be cloned.
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]
Some time ago I have found seemingly a wonderful option:
TortoiseSVN --->>> use --->>> SVN bridge --->>> reach --->>> TFS.
https://svnbridge.codeplex.com/
But I am afraid, this rather not native solution, could possibly lead to hazard states, or incompatibilities.
Especially between various versions of TFS and TortoiseSVN.
What does the community think of SVN bridge ?
Or is there any converged external F-E GUI client developed directly for TFS ? (Outside of VSO Team Explorer itself, or other integrated plugins for IntelliJ, Eclipse ...)
I really want an external tool, independent of any IDE.
Here is a list of pretty outdated offered solutions.
https://blogs.msdn.microsoft.com/mrod/2008/04/28/external-team-foundation-server-tools/
The VS-TFS Power tools offer a Windows Explorer integration for VSTS/TFS. It requires Team Explorer 2015 to be installed (or at least the TFS Client Object Model) and since the last version was never updated for VS2017, you need the 2015 Client object model present.
There is also the TFS/VSTS plugin for Eclipse called Team Explorer Everywhere and Native support for TFVC in most JetBrains tools.
On top of that Team Explorer Everywhere ships with a cross-platform command line version of "tf", the standard version of "tf" is of course already an option to consider.
I'm not sure why you consider Team Explorer to be "dependent on any IDE" the Visual Studio Shell it ships with can just be fully ignored, just open the Source Control Explorer and the Team Explorer tab and you have a TFVC UI.
Using Visual Studio 2015 I was previously working on a project which is in an old Visual Source Safe repository.
I needed to connect to a project in Visual Studio Online (Team Foundation Server) and so in Tools -> Options -> Source Control -> Plug In Selection I choose Team Foundation Server and successfully connected to the Visual Studio Online repository pulled down the code, worked on it and checked it in.
The problem comes when I need to access the project in VSS again. I tried to reverse the process. Setting the Plug In Selection back to Visual Source Safe. However even when I don't have a solution open the 'Team Explorer' is still connected to Visual Studio online and I can't connect back to VSS. When I open my VSS based project it is STILL connected to Visual Studio Online as well.
I don't have the option of moving the older project out of VSS just now (not my choice, I'm hoping it's going to change soon but not a choice I can make), and need to carry on working on it. I basically need to disconnect VS from VSO and can't, and can't connect to anything else instead.
Has anyone come across this problem and a solution to it? I've searched but only find answers about disconnecting a project from it's current source control, I don't want to do that, I want each project to remain with it's source control, but I need to be able to choose which source control VS is connected to.
Well I've found AN answer eventually, through trial and error... it's a bit of a faff.
First thing is I forgot that VSS doesn't use the Team Explorer. When I opened the VSS based project the project HAD actually connected to VSS, but the Team Explorer wasn't reflecting that. So I could carry on working on my VSS based project and just ignore Team Explorer.
However I still wanted to disconnect, because it had only been a one-off requirement to connect to that Visual Studio Online project.
What I did was...
1. Log out of my Microsoft account from Visual Studio.
2. Close and re-open Visual Studio.
3. Click close on the prompt to log in to my Microsoft account.
4. THEN the option to delete the connection was available in Team Explorer. Pretty sure it hadn't been there before.
5. Log back in to my Microsoft account.
Unfortunately I had also reset my Microsoft Account password in the trial and error, which I now think was unnecessary. I was just trying to force VS to stop connecting to that repository.
As Team Explorer is not use with VSS you may want to use "Team | Disconnect from TFS" to disconnect. Then switch your control...
Note: As VSS as been completely unsupported for many years you are incurring a significant business risk by staying with it. Have you raised this risk with your executive team? Do they know that their organisational asset is at risk?
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
I have some projects to work on that involve a grotesquely large csproj that is the COTS CMS application I'm extending. The project has over 16k files in it which is ridiculous but it's not something I can control, nor can I control the choice of CMS platforms. The project is in a solution... the solution is in a git repository.
With a project that large, using the source control plugin in Visual Studio 2013 means any change to a file and subsequent save results in my CPU and RAM usage spiking to a ridiculous percentage for several minutes, making the fan spin on high constantly all day and making my IDE laggy. I have a very high-end desktop replacement laptop and I'm certain throwing hardware at the problem won't make it go away. So, I go into options and set the source control provider to None... problem solved after a couple-minute lockup while VS does something.
Now for the problem... when I come in the next day and open up the solution, the plugin selection is back on Microsoft Git Provider. Is there a setting or something I can configure to tell Visual Studio (ideally for just this solution or project) to stop trying to use the integrated source control?
I had the same problem, I need the Work Items from TFS but I use git-tfs to manage my projects locally.
I managed to disable the built-in Visual Studio Git Provider by deleting all occurrences of those registry keys:
7FE30A77-37F9-4CF2-83DD-96B207028E1B
11b8e6d7-c08b-4385-b321-321078cdd1f8