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
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]
Ok, before I explain in detail, here's my (very odd) setup:
Hardware: iMac
OS: Mountain Lion
Software:
Editor (Mac): Sublime 2
Virtualization: Parallels Running Windows Server 2008
IDE (Windows): Visual Studio 2010
Source Control (Windows): Team Foundation Server
So here's my dilemma.
I looooove Sublime 2. However, being a Microsoft shop at my workplace, I have no choice but to deal with TFS. I don't do a lot of back-end coding, I'm a front-end guy and don't need all the hefty class and structure tracking built into Visual Studio, so Sublime is perfect for me.
One of the things I love about Sublime is that I can hit cmd+p and pull up any file immediately. The alternative is spending several minutes sifting through our file structure to locate the same file (we have a massive project structure...it's a beast).
Unfortunately, I can't just tap cmd+p and pull up any file...I can...but after editing it, I hit save and "uh oh! file isn't checked out, it's read only". I then have to switch spaces, spend several minutes sifting through directories to locate that same file I worked on, and check it out. Switch back, save, and then check it in. It wastes a lot of my time and defeats the time-saving benefits of Sublime's file searching.
What I'd like to know is if there's an easier way to accomplish this. I've tried a few things and none have panned out. I found a plugin that integrates TFS with Sublime - but that only works for Windows. I tried using Eclipse with a TFS plugin, but I still have to browse through a massive directory structure to check out the file in Eclipse before editing it in Sublime.
Is there any way to streamline this process better? I know it might sound silly to go through such extremes to save a minute or two here & there, but when I do this hundreds of times a day, it starts to save a LOT of time!
Thanks in advance to the community for any help on this!
If you can persuade your TFS Admin team to upgrade to TFS 2012 you will have your solution. TFS 2012 supports "Local Workspace" which does not keep files read-only on disk. You download your source code once through Visual Studio or Eclipse and keep working in ANY editor you want. TFS Client tracks changes on the file system and you just need VS or Eclipse to check-in your work at the end of the day.
For TFS 2008 and 2010 you have to check-out your files manually or with the help of a supported IDE. Those versions only support "server workspace"s and that flavour of workspace keeps all files on disk as read-only.
You might have another chance with 2008 or 2010 tough. TFS 2008 and TFS 2010 on Windows platform supports offline working, which temporarily disconnects your workspace from the server to do your work. Then at the end of the day you go back online and TFS client tries to "detect" what changes were made when you were offline and lets you check them in. This blog post says Team Explorer Everywhere supports offline work. You might need to remove read-only flags of files manually. Offline working is not perfect even on Windows platform and you need to be careful until you get used to it but I believe it is worth giving a shot.
If upgrading to TFS 2012 is an option then you probably want to consider it.
TFS2012 with local workspaces no longer require files to be checked out in visual studio first (files are no longer marked as readonly, and vs detects changes from other programs). This will get rid of one of your alt-tabs to windows.
You'd still have to alt-tab back to check in, you could potentially use a commandline "tf checkin" if you don't want to keep visual studio open.
So after trying several suggestions from here, among a few I found elsewhere, I've come to the conclusion that the best setup (for me) is as follows:
Editor (Mac): Sublime 2
Editor (PC): Sublime 2 with TFS plugin
Virtualization: Parallels Running Windows Server 2008
IDE (Windows): Visual Studio 2010 Source Control
(Windows): Team Foundation Server
So as you can see I updated my existing setup with one slight tweak. On my Windows side, I installed Sublime 2 and installed the TFS plugin. If I want to check out a file, I switch to windows, search for the file, check it out via Sublime's TFS plugin, then switch back to the Mac. It's certainly not ideal, and requires an extra step, but it seems to work the best for me and is faster than using Visual Studio to check in/out.
If anyone comes up with a more elegant setup (aside from using TFS 2012 - which thankfully is coming for my organization), I'd love to hear about it. In the meantime, I hope this helps anyone else who might be using a setup similar to mine.
We're using Visual Studio 2010 (Premium edition if it matters), and pretty happy with it. However, We're never going to use the TFS features that's included in the IDE. (We're using Jira and Subversion, as it's not just Visual Studio that we work with, but also IntelliJ and a couple other IDE's.)
Is there any way to disable the TFS portions of the IDE? It's not a big deal or anything, just for the sake of "keeping things neat."
In Visual Studio 2010, go to Tools->Options In the list, select Source Control. Set your Current source control plug-in: to None
The main "TFS" parts of the IDE are in Team Explorer - Just don't install it.
Anything else you don't want/use, I'd advise you to simply ignore - VS has support for hundreds or even thousands of different things that you will probably never use, and you can't easily "clean" them all away.
In my experience the more you alter your installation of Visual Studio the more problems you will have with it. Every custom Option you set is another thing you have to repeatedly set every time you get a new PC or install a new VS. (Although it has improved a lot since import/export options became available and reliable). I used to spend about half a day setting up a visual studio to "work well", and now I just install it and use it. Ultimately I found that it was easier to just adjust my working practices (e.g. by relearning a few keyboard shortcuts etc) than to try to bend VS to my will.
Recently, the SourceSafe integration into visual studio has started to perform badly because we have moved, and the SourceSafe "server" is located across a VPN which goes across a slow connection. This has made loading large projects in visual c++ 6 take 5+ minutes because it has to talk to the "server" for each project. Also, there are some bugs that are dangerous in the integration (the auto-checkout of certain shared projects will do a get latest on the wrong version of a branched file). This has caused me to want to disable the SourceSafe integration, however I have not found any menu option or uninstall option. Google has reported a few registry tweaks, but none of them seemed to work.
Does anyone know of an easy way to remove the SourceSafe integration from Visual C++ 6, without uninstalling SourceSafe altogether?
From http://support.microsoft.com/kb/236399:
Source code control software, such as
Microsoft Visual SourceSafe, that
integrates with the Visual C++
integrated development environment
(IDE) can be configured to connect to
a source code server during Visual C++
startup. In such cases, a loss in
network connectivity will cause Visual
C++ to start up very slowly. To
improve performance, either ensure
proper network connectivity or disable
the source code control software
integration with the Visual C++ IDE.
To do the latter, quit Visual C++, and
then use RegEdit.Exe to locate the
following registry key and set its
Disabled value to (DWORD) 0x00000001:
HKEY_CURRENT_USER\Software\Microsoft\DevStudio\6.0\Source Control\Disabled
I followed this and it seemed to work upon trying it again. I think I might've had a second copy of visual studio running when I did it the first time.
Open the .dsp and .dsw file in a text editor, and remove the respective entries from the .dsp and the .dsw file. Also, delete the .scc files.
There is a Microsoft Knowledge Base article about how to do exactly this.
The gist of it is that you must manually edit the .dsw and .dsp files in a text editor, and remove a few other files lying around. See the article for more details.
If the solutions mentioned above fail for you do this:
Rename folder: \Program Files\Microsoft\%vs%\Common7\IDE\VS SCC
VS will complain once about plug in not being there and you say "Yes" to ignore it in perpetuity.
All files “got latest,” “read only,” and edited in VS, will make VS complain and offer to “override”, which works fine for me.
What do you gain:
Open VSS-linked solutions quickly without VS matching contents to VSS server.
Open VSS-linked solutions and EDIT the files at will without being bogged down in “check out” bs.
This makes using other distributed source control system on top of project tree with VSS bindings painless.
VSS client still works by itself just fine, including diff, checkout, checkin.
HKEY_CURRENT_USER\Software\Microsoft\DevStudio\6.0\Source Control\Disabled
I followed this and it seemed to work upon trying it again. I think I might've had a second copy of visual studio running when I did it the first time.
Its working .....Thanks Ajay
What has worked for us, and is much easier, requires no registry/file editing by hand, and safer I think is this:
1) Exit Visual Studio completely.
2) Disconnect from the network (unplug the cable and turn off wireless, or disable the network adapters)
3) Open the VS6 workspace (DSW) for the project. When it starts up it will find it cannot connect with the VSS database it wants to and ask you about that...
4) Tell VS to never try to reconnect to the source control db in the future.
5) Done... VS does all the changes to THAT WORKSPACE/PROJECT setup for you. You are not disconnecting VS from source control in general (like a registry edit would do) and your not manually editing files.
My company is using Visual SourceSafe (VSS) and Visual Studio 2005 (soon 2008). They want to switch to CVS, but the developers don't want to lose the integration we get with VSS and Visual Studio.
I know there are CVS plugins, but what functionality, if any, is lost with CVS?
If you're going to switch, why not switch to something better? CVS is a long way from state of the art in version control. A more modern system like Subversion or Vault not only offers better features, but it will get you better Visual Studio integration as well.
Screaming at VSS for lost source code, etc. Seriously though, it is a very different model (optimistic locking), so you will probably lose some productivity for the first little while. I would probably look at using TortoiseCVS and "Open Folder In Windows Explorer" right-click or the Visual Studio Explorer plug-in rather than a CVS plug-in if you are using Visual Studio 2008 (all of the CVS plug-ins I have tried have had either serious functionality issues, or serious stability issues).
VSS is really a terrible source control system, and moving to a modern style (optimistic locking) source control system will be a huge boon in the long run. You might want to skip the 1990s all together though and move to Subversion/Git/Mercurial and get into the 2000s.
If you must switch to CVS (Subversion or a distributed VCS would be better) then the script we used to migrate and keep the change history can be found here.
We are very happy with CVS, although we don't use Visual Studio integration as we find TortoiseCVS and SmartCVS much better. However if I was switching now I would look at Git or Mercurial.
My hack is as follows:
I am mainly a Java developer and I use Eclipse/RAD. The support for CVS is great and is very easy to work with.
For the C# work I do I tried to find a CVS plugin for Visual Studio but was unhappy with the one I found. In the end, I decided to use Eclipse to handle the versioning of my C# projects.
The procedure:
Create a simple project in Eclipse
Open VS and save the project into the directory created by Eclipse
Return to Eclipse, press F5 to refresh the project
Share the project (i.e. add to CVS)
Add .sln to the list of externally handled files in the Eclipse settings
VS can now be opened directly from Eclipse by clicking the .sln file, the project can be worked on within VS. Upon exit from VS the project must be refreshed in Eclipse and can be synchronised with CVS
Although I have not yet used the Subversion plugin, I guess that would work in a similar way.
This solution works well for me especially as I spend most my time in Eclipse anyway.
I did try using TortoiseCVS but found it tricky to use. Eclipse is free and the CVS interface is very usable.
Visual Studio has a bad integration inside the IDE for CVS and SVN. Those free ones don't work well. I use Tortoise (outside Visual Studio), and it works fine. If you want something inside Visual Studio, you might check for not free plugin or to use TFS.