I am using SQL Server Data Tools (which = Visual Studio 2015 (Integrated)) and I am having trouble being able to connect to TFS. I can see the Team Explorer window, but when I click "Manage Connections" --> "Connect to Team Foundation Server" ....nothing happens. I get no error or prompt or anything. Has anyone else had issues like this? Spent most of my day googling the problem yesterday and I can't figure out what is wrong.
I cannot use VS community as I am part of a company and it would violate the TOS.
Unfortunately, TFS is not included in the minimal VS that SSDT installs. If you're not able to use VS Community due to license restrictions, I would suggest looking into the Express edition (Web or Desktop) of Visual Studio 2015. It has a less restrictive license and supports the SSDT tools.
Related
I have installed Visual Studio 2019 to do some testing on our code base ready for migrating from Visual Studio 2017, I am also testing to ensure it plays nicely with our TFS system (currently TFS 2018 on premises).
It looks as though the Visual Studio Work Item Form is back! (VS 2017 dropped support for this in favour of opening Work Items in a web browser). I've not managed to find any information on this. I like the fact that we might have the option to work with Work Items in the VS IDE as well as the web browser, however its return introduces a few issues:
We use a custom MultiValue control that does have support for the VS 2019 Team Explorer (it last worked in VS 2015). Do you know where I can get hold of a MultiValue control that will work on the Work Item form in the VS 2019 Team Explorer?
Given that the MultiValue control isn't working I would like to continue working with Work Items in a browser. The VS 2019 Team Explorer seems to favour opening Work Items within the IDE, how can I open them in a browser from within the VS 2019 Team Explorer? Better still, how can I configure it to open in a browser by default?
Is there a better place for me to ask these questions?
Work Items should default to opening in the web in Visual Studio 2019. That behavior has not changed from Visual Studio 2017.
There is an option under "Tools->Options->Work Items" to enable the "Legacy experience (compatibility mode)". It sounds like that option has somehow gotten enabled in your installation. If you switch that back to "Default experience", work items should open in the web.
Hope this helps.
Sorry for the inconvenience. This is a designed behavior right now.
Please take a look at this similar issue: TFS work items opened inside Visual Study no longer open in the web browser, they always open in the Visual Studio editor
According to the response from MSFT:
We have re-design the default landing page for work items in Visual
Studio 2019 which only works with server >= 2019. If server is <
2019, work items will be open in Visual Studio only.
Since you are using TFS 2018 with VS2019, you may have to open work item in web portal from browser directly right now. Otherwise, you have to upgrade your TFS version from 2018 to Azure DevOps 2019, if you insist on opening the work item in Visual Studio.
I have legacy projects bound to Visual SourceSafe and done with Visual Studio 2003. Now, I have recently installed Visual Studio 2017 and TFS in the same machine.
Now when I try to open a legacy project that is bound to Visual SourceSafe I get a sequence of errors. Below the screenshots (pixeled for confidenciality reasons).
It seems like when open a legacy project (bound to Visual SourceSafe) with legacy visual studio 2003, it tries to connect to the TFS server (obviously it cannot). It is happening since I have installed new Visual Studio 2017 and TFS in the same machine, it seems like they cannot live together in the same machine. So how can I keep both VSS and TFS installed in the same machine? Is it possible?
UPDATED:
It seems like VS2003 does not allow to switch SCC providers. The only way is to hack the registry to switch.
I have found some interesting things that explains how to do it and it seems to work, the problem is that some links are broken, they are too old and not available anymore.
Source safe with Team Foundation Server in VS.2003
Installed TFS Version Control Provider and Now my VS 2003 Projects lost connectivity to VSS 2005?
MSSCCI Provider installation error
In above links it is provided a solution that consists on hacking the registry but the link they provide is broken:
Switch SCC providers
UPDATE 2:
As Edward Thomson has suggested in his answer, I have created a new key 'HKCU\Software\Microsoft\VisualStudio\7.1\CurrentSourceControlProvider\ ' and set it with a string value: ProviderRegKey="SOFTWARE\Microsoft\SourceSafe". Below screenshot, but it is not working:
MSSCCI is the Microsoft Source Code Control Integration API, it was the original API provided by Visual Source Safe for IDE tools like Visual Studio. Early Visual Studio versions (like 2003) only spoke MSSCCI, and expected a version control provider to provide MSSCCI. As a result, you can only have one version control provider speaking that protocol.
The Team Foundation Server client APIs provide MSSCCI (for Team Foundation Version Control only, not Git). As a result, if you want to use Visual Source Safe, you will need to configure Visual Studio to speak to that set of libraries instead of the TFS set of APIs.
In slightly more recent versions of Visual Studio (like Visual Studio 2008), you can choose your MSSCCI provider on the fly, in Options > Source Control > Plug-In Selection. All the MSSCCI providers will be enumerated and you can select between Visual Source Safe and Team Foundation Version Control.
If you're using an earlier version of Visual Studio that did not have this option, then you can change your MSSCCI provider by updating the registry directly.
Find the registry key:
HKCU\Software\Microsoft\VisualStudio\7.1\CurrentSourceControlProvider\
And set:
ProviderRegKey="SOFTWARE\Microsoft\SourceSafe"
Update 7.1 in the key with the version of Visual Studio that you have installed (Visual Studio 2003 corresponds to version 7.1.)
Once you have made this change, you will not be able to use Team Foundation Verson Control from Visual Studio 2003 without changing that back.
I'm not asking a technical question, but a request for advice.
Over time, I have always used installshield as the primary tool in installer development, and this tool has always been the king of them.
Lately, everything has gone to the web and Windows Forms have lost their charm. However, these still exist, and there are needs about them.
But you don't see anyone talking about the latest technologies about Windows Forms, installers...
Do you think Installshield is still the main tool for build installers? Why isn't any extension available in the VSTS/TFS vNext market?
Even in Jenkins, the last time the plugin was updated ... was in 2014. And we remember that Microsoft used Installshield Limited edition for one Visual Studio Version, but dropped to bring back Visual Studio Installer.
We are going to buy "VS 2013 Pro" and we need to know, if this product is compatible with tfs 2010 version. Are they able to connect properly. Maybe somebody tried or found an official post from microsoft about support.
Officially yes, TFS 2010 or higher supports VS 2013, but I have found you can get the following:
"You cannot connect to {IP Address here} because it is running a version of Team Foundation Server that is not supported by your version of Visual Studio" blah blah blah
If you get this, you may have to mess around with your Team Explorer version to get one that is compatible with TFS 2010. I have not experimented with the standard Visual Studio plug in. I do know that you can also download the MSSCCI client bits and switch to them in options if you are still having issues.
This pix shows switching to the MSSCCCI client:
http://3.bp.blogspot.com/-GYFtUDIlZcg/UI1jVHwlaaI/AAAAAAAAVgQ/lVKlW_Mc-XU/s400/Select+Source+Control.png
See Compatibility between Team Foundation clients and Team Foundation Server
We are setting up a new TFS 2008 implementation as our first usage of TFS for source control. We have several projects in Visual Studio 2003, 2005 and 2008, as well as other script/non-Visual Studio based projects.
My question is, for the Visual Studio 2003 and 2005 projects do we have to install Team Explorer 2003/2005 and make use of them to add projects to source control and to check out/in files, or, can we just use Team Explorer 2008 to add projects and check in/out files? The thought being that the developer could use 2008 to check out any thing and then open the appropriate visual studio version to work on their local instance of the project before then checking it back in using team explorer 2008 within their local visual studio 2008 application.
The concern is that by using team explorer 2008, that visual studio 2008 might impose changes on the older systems solutions dll or control details.
Thanks for any guidance.
This is possible. I have colleagues who are using Team Explorer for non-code files (Word documents, help files, etc.) and use it like they would VSS or any other SCC.
As an added bonus, I'm pretty sure that TFS Server 2008 is backwards compatible to at least 2005 (haven't run against 2003 in awhile). IIRC, I've run VSTS 2005 For Developers against a 2008 TFS Server.
I would double-check for you, but I've recently recently re-imaged my dev machine and haven't re-installed 2005 (working on new stuff!).
As an aside, I've found TFS to be a huge timesaver as far as the whole dev process. The IDE integration is top notch, and the linked bug/task tracking and changesets, with alerts, notes, built-in queries and reports had me wondering how I ever got along w/o it.
HTH.
The Team Foundation Client for VS 2005 and VS 2008 can be installed side by side so there's no issue there (there isn't one for VS 2003, but you could probably use the MSSCCI provider).
You can however, if you want to, do all of your source control operations in VS 2008 (or the Windows Explorer extensions in the latest power tools) but work on the projects from VS 2003/2005 without any issues. You just need to make sure you don't accidentally open the project files from within VS 2008 because that will upgrade the project format.