I installed Visual Studio 2015 Enterprise RTM and only seeing "references" from Code Lens. We are using TFS for source control. I expect to see related commits from TFS. Based on this article, I have everything enabled in options:
Here is what I see in VS:
Is there anything wrong with my VS setup?
The TFVC lenses that are part of CodeLens only work when connected to a version of Team Foundation Server that is running the background job that generates the historical data. This means that you need to be running at least TFS 2013 or 2015 in order for this feature to work. Some features require a specific version of Visual Studio.
It is also possible that your server admin has disabled indexing on the server, one can do that using the tfsconfig codeindex command on the application tier.
Related
We currently have a TFS 2012 Server which is being replaced by a 2015 server, the aim is to gradually migrate our code from one to the other.
When we do this we would like to maintain the checkin history, labels etc, Looking at similar questions the answer seemed to be to use the integration toolkit, however it looks like it (and its successor the integration platform) do not support TFS 2015.
We are using TFVC rather than git, if that makes a difference.
I don't have much knowledge about the integration toolkit, but I would actually suggest to do the upgrade one Team Project Collection at a time, but moving them separately to a new server with TFS 2015 installed. This way you will keep all history, label etc.
We have done this way back when upgrading from TFS 2010 to TFS 2013. Only obstacle that we had was a collection around 500 GB in size so it took around 16 hours for the upgrade to finish.
The following answer specifies the steps needed to move a collection to another server:
Copy TFS 2012 collection to another server with TFS 2015 Installed
We have used this Migration tool for our Client.
It’s possible to migrate TFS 2012 data to TFS 2015 with all information intact without any system downtime. The premium version of OpsHub Visual Studio Migration Utility (OVSMU) supports migration of projects with TFVC repository from one instance to another. It supports the 2010, 2012, 2013, and 2015 versions of TFS and all versions of Visual Studio Online, including the 2017 version. Along with basic data, you can migrate all workitems with history, comments, attachments, relationships, and source control with changesets, history, labels, comments, etc. You can checkout the details here: https://www.opshub.com/products/opshub-visual-studio-migration-utility/
I have an ongoing need to manage, in TFS source control, a collection of SQL scripts organized as an SSMS solution (.ssmssln file).
I'd like to capture the "success path" for using SQL Server 2012 SSMS with TFS2010, using the appropriate MSSCCI provider and Team Explorer versions and install sequence.
I'm using the "Developer Edition" of the SQL Server products, running locally on my Win7-64 dev box, and need to access a TFS 2010 server maintained by a different group. VS2012 and VS2013 are also installed on this "new" dev box and I have had no problems accessing our TFS 2010 server from them.
I had been trying to get SSMS from SQL Server 2012 (Developer Edition) to work with our TFS Server 2010 for some time, with no luck. I finally did get the SSMS 2012/TFS 2010 combination to work on the new dev box, but was left with the question "what was it that actually worked", and none of the other documented solutions address this combination. This one doesn't:
See: SQL Server Scripts 2012 Project into Team Foundation Server 2012, which addresses SSMS 2012 and TFS 2012.
My company's TFS versions tend to lag 1 major version behind our VS and SQL versions.
Other articles did not have steps that solved my problem.
https://dba.stackexchange.com/questions/17850/tfs2010-for-ssms-2012; the 2010 Team Explorer plus 2012 MSSCCI provider did not work for the SSMS 2012 + TFS 2010 combination. This article, http://www.techtree.co.uk/sql-server/management-studio-ssms/use-team-foundation-server-tfs-as-your-source-control-in-ssms/, while helpful, didn't really discuss the Team Explorer requirement except briefly in comments from others.
I had the SSMS 2008R2 and TFS2010 combination working fine on an older box using the MSSCCI provider. When I moved to a new box, installed SSMS from SQL Server 2012, and would open and edit my SSMS solutions (opening the .ssmssln files) I was not having any luck in getting integrated TFS source control to work, despite trying a number of different MSSCCI provider versions and TFS Team Explorer versions.
From SSMS2012, I would get the "Connect to a Team Foundation Server" dialog box, with an empty dropdown list of TFS servers, and then attempt to add my company's server, and inevitably get a 404 error, despite entering the same values that worked for SSMS 2008R2/TFS2010 on my older Win7-64 box.
The combination that I believe finally worked for me was:
Install Team Explorer for Visual Studio 2012
http://www.microsoft.com/en-gb/download/details.aspx?id=30656
Install MSSCCI Provider for Team Foundation Server 2010 https://visualstudiogallery.msdn.microsoft.com/bce06506-be38-47a1-9f29-d3937d3d88d6
After doing these two things, I recall getting a prompt to open Team Explorer. I believe it was launched for me either after installing the MSSCCI 2010 provider or when I went to configure source control in SSMS 2012.
Interestingly, when Team Explorer launched, it showed "the Visual Studio 2010 logo." In any case, I opened it, and went to add the TFS servers. This time, there was an additional entry in the add servers box, that showed the TFS "initial path" (or "instance name") for our TFS 2010 server.
Our TFS server address appears to be:
http://OurTFSServer:8080/tfs
Previously, there had been no place to enter the "/tfs" part of it. This time, it showed up in the add TFS server address dialog box, and I believe was prepopulated for me.
It appears to me that the missing part was the install of the VS2012 Team Explorer, which seems to know about the "/tfs" initial path, where the VS2010 Team Explorer did not. Strangely, the Team Explorer that launched showed the VS2010 logo; note that I explicitly uninstalled the VS2010 Team Explorer prior to the sequence of installing VS2012 Team Explorer and then installing the TFS 2010 MSSCCI Provider.
Just to keep things interesting, the MSSCI provider version numbers and dates are confusing. Here is what the "readme.txt" file says for the MSSCCI version numbers. The file is located at:
Program Files (x86)\Microsoft Team Foundation MSSCCI Provider\readme.txt
NEW system:
Microsoft Team Foundation Server MSSCCI Provider
v 3.5 09/20/2013
OLD system:
Microsoft Team Foundation Server MSSCCI Provider
v 4.0 03/07/2012
So it appears the combination that was working on my "old" dev box for SSMS 2008R2 and TFS2010 was the Team Explorer for Visual Studio 2010, and the MSSCCI Provider for Team Foundation Server 2012. I also had VS2010, VS2012, and VS2013 installed on that box.
On the "new" box, it appears the working combination for SSMS 2012 and TFS2010 is Team Explorer for Visual Studio 2012, and the MSSCCI Provider for Team Foundation Server 2010 (which has an older version number but a newer build/release date, compared to the 2012 MSSCCI provider).
What I am looking for is others who use this combination, SSMS 2012, and TFS 2010, to confirm and/or clarify the "success path" of what is required and the sequence, based on their experience from ACTUALLY GETTING THIS COMBINATION TO WORK. Not what "should" work (and often doesn't), but what DID.
This problem was resolved on several fronts, over time, by migrating to better-fit technologies, and updating to known-compatible versions of the Microsoft technologies involved.
1) I changed most of the SQL script content to JSON files, by serializing the data with Newtonsoft's JSON.NET. Now I no longer had a need to maintain these SQL scripts. Instead, I load the data from JSON files, to objects, having implemented serialize/deserialize approaches within the applications that use the data. This works out way better than SQL since the bulk of the data that was being kept involved representations of "content".
The content is represented as packets of documents, with each packet containing multiple document templates, and each template being comprised of multiple paragraphs. There are additional properties of packets, templates, and paragraphs up and down the object model. So JSON serialization/deserialization was a way better fit for these applications. It also enabled a "single piece flow" approach to updating content. Now I manage JSON files instead of SQL scripts, to keep point-in-time snapshots of these content objects. Typically I will back up the prior version of all the document packet objects as part of each content release, and store that backup in TFS.
2) There were other areas where I still need to maintain SQL scripts, such as reusable queries within the application. (I didn't want to use stored procedures for configuration flexibility reasons) I found an approach for making these SQL queries part of a .NET assembly via Resource Files and that addressed the need. One example of the type of approach I used is here: https://jopinblog.wordpress.com/2007/11/12/embedded-resource-queries-or-how-to-manage-sql-code-in-your-net-projects/
3) My company upgraded our TFS Server to TFS 2012 and we started using Visual Studio 2012 and 2013. The things that had been problems in SSMS started working when using newer known compatible configurations.
We are planning to upgrade from Tfs 2012 to Tfs 2013. Can anyone help me understand the difference in process templates between them? We use all three process templates for different projects.
The changes are very minor, except for:
The introduction of Portfolio backlogs.
Test Plans and test Suites are now Work Item Types (TFS 2013 update 3).
The AgileConfig and CommonProcessConfig files have been merged to a single file inside the template
The minor changes:
Git support for the Source Control options
Stackrank type fields are now hidden by default (because Agile task boards are now features of the Standard CAL).
Tag field support through the API.
The easiest way to visualize all differences is by comparing them through the TFS Team Project Manager which can be downloaded here.
TFS 2013 did not work well with our existing workspaces defined on remote network drives. TFS 2012 did work with this configuration.
After working several hours with our System Administrators, we gave up on trying to get the trying to get the existing network drive workspaces to work with the TFS 2013. Converting the workspaces to local drive locations enabled us to work with TFS 2013.
Can someone explain the high level process, of installing TFS? I've had the Server set up by a "network guy". It's TFS 2010, and we're using VS 2010 and moving to VS 2012. Do I need to install something on my client machine, or does Visual Studio just "hook" into TFS automatically?
Also, I've been tasked with moving our VSS to TFS. I've seen those posts and don't need coverage of that, unless you wanted to point me to the best links of how to. When those instructions mention installing Team Explorer or needing SQL Server Express on the machine you are doing the migration on, do they mean my workstation or the Server?
The Microsoft walk-throughs are the worse (IMHO)...
well, I followed http://tfsguide.codeplex.com/wikipage?title=How%20To%20-%20Migrate%20Source%20Code%20to%20Team%20Foundation%20Server%20from%20Visual%20Source%20Safe
And nearly got it installed. I'll post a new question with the new issue.
I am installing VSTS. What components do i need to install for both .net & sql server. ?
How do we configure our projects?
There are two parts to a successful Team System environment: Team Foundation Server and Visual Studio Team System.
For best results, install the former on a dedicated server. There are great resources to help you through installation right from Microsoft. There's even a video series of TFS-related content!
Once your Team Foundation Server (TFS) is installed, Visual Studio Team System (VSTS) is installed on your development workstation. VSTS looks just like any other VS install at startup. To configure it to work with your TFS instance, go into Tools > Options and Select Source Control: here you will see a pull down which should contain an entry entitled Visual Studio Team Foundation Server. I forget how to select your TFS server instance for VSTS to work with but I don't recall having trouble with it when I did it a few months ago.
Once you've configured all that, you interact with your TFS work items and source code from the Team Explorer and Source Control Explorer panes in VSTS: it should begin to feel rather like using VS without integrated source control from there forward.
The bigger issue is configuring your process in TFS to reflect your project's strategy, etc. That is an exercise in thought/reading more-so than how to configure it.
All this documentation is readily available via Microsoft's website. It does require some reading but devote some time to it: it'll pay off in the long run.
Team Foundation Server Requirements