Our company is stuck on TFS 2013 due to Adobe's RoboHelp software only working with that as a maximum version. We are looking to migrate to .NET 4.6 from 4.0 and VS 2017 - As such we can use new framework featuers (such as Async / Await) and language features (Like Tuples).
Unfortunately our team build is failing when building a test project with the upgraded stuff and I assume this is because it's pointing at the 4.0 MSBuild.
I've installed VS2017 (Compiler and .NET 4.6 targeting pack). I have done some research on the topic but TFS 2013 + VS 2017 seems an oddly specific combination. I did however find that I need to change the ToolsVersion to 14.0 which I have done.
MSBuild then shows me that the maximum ToolsVersion I can have is 12.0, which again makes me think I'm using an old MSBUild. More research lead me to the ToolsPath property which I have set to "C:\Program Files (x86)\Microsoft Visual Studio\2017\Professional\MSBuild\15.0\Bin". However this still gives me the same error.
How do I go about getting VS 2017 projects to build on TFS 2013? I presume I need some kind of MSBuild path changing but the ones I have tried so far just don't seem to cater for the new syntax.
Just for anybody else that comes across this issue - There are potentially multiple MSBuild tasks within the build process template, I happened to have two and as soon as I changed the ToolPath on the second task to the full MSBuild path, my project started to build.
Related
However VS 2019 is the best IDE, sometimes we want to do somethings and we can not do it. for example, you work on a project and suddenly your PC is crashed and you have some class check out on TFS.
In new PC when you get source you see some sources check out with your user in another pc and you can not check-in or undo them in VS 2019. What can you do?
A tip for solving the problem with another work-space in TFS
Solution
The best way that I find without any writing commands is:
Install VS 2013 and after that get Power Tools for TFS vs 2013
After install power tools, when you get the source with vs 2013 and go to source control explorer, you can right-click on your project and go to find--->findByStatus
and click on find.
you see all files which are checked out by other workspaces and you can undo them
that's easy
Next step. close vs 2013 and open VS 2019 and get your sources and start again write code. (please write clean code :))
You can also use the Attrice TFS Sidekicks available here there are multiple versions for different Visual Studio but they all work against 2019. From the workspace sidekick you can list and remove old workspaces.
Also you can run from the TF.exe command line do remove old workspaces Microsoft doc available here
I have VS 2017 and VS 2019 installed on my computer. When I compare my changed code in VS 2019 Team Explorer's Pending Changes window, the differences are shown in VS 2017. That is as soon as I choose Compare with Latest Version option from context menu, VS 2017 is started and differences are shown in VS 2017. Is it something that I have to change in VS 2019 settings or VS2109 is supposed to work like this?
No, it's not an expected behavior.
Have tested VS2019 with either VS2017 or VS 2015 installed, both worked properly.
This strange behavior may related to cache. I was wondering if your target Path used to open under VS2017 in your environment. Or something cached in VS2017.
Please try to clear TFS cache and VS cache which may do the trick. First with TFS cache, if not work then with VS cache.
I updated to Visual Studio 2015 when it was released last week. Resharper suggested that I might like to update the following string using string.Format:
string filePath = HttpContext.Server.MapPath(string.Format("~/App_Data/{0}.xlsx", Guid.NewGuid()));
To use string interpolation:
string filePath = HttpContext.Server.MapPath($"~/App_Data/{Guid.NewGuid()}.xlsx");
I did this, and all is well.
However I've broken the build on TFS:
Controllers\MyController.cs (224):
Unexpected character '$'
So it seems like the new features in C# 6 can't be compiled by our older, non-updated version of TFS.
The project is still targeted at using the Framework 4.5 however, I have not targeted 4.6. I (wrongly) assumed that still targeting the old framework would mean it could be built by other team members still using VS2013 along with our TFS build server.
So it looks like our TFS needs an update of... something.
What do I need to install on the TFS server to have it compile this new syntax? The latest version of the .NET Framework or something else?
Install .NET Framework 4.6 and Build Tools 2015 on your build server.
Then override the ToolsVersion (/tv:14.0) in MSBuild arguments.
Unfortunately, there doesn't appear to be an easy way to get older versions of TFS working with C# 6.0 without installing VS2015 on the TFS build server. If you can do that, I would suggest that. If, for whatever reason, you cannot, then the following worked for me:
I followed the instructions of the other answer, but that alone didn't work. I also had to edit the default TFS build process template (which in my case is found in $//BuildProcessTemplates) and change the ToolPath properties of the "Run MSBuild for Project" nodes to the location of MSBuild 14.0 (which usually is C:\Program Files (x86)\MSBuild\14.0\Bin).
You will then need to update your build definitions to use the new build template (if you had copy/edited a new one vs editing the original one).
At this point, you should be able to build C# 6 projects with TFS, but if you're trying to do web deployment/packaging as well, then there are still a few more steps.
On the build server, at C:\Program Files (x86)\MSBuild\Microsoft\VisualStudio\v14.0, there should be a Typescript folder and nothing else. On your local machine with VS2015, go to the same path. There should be a Web and WebApplications folder. Copy those over to the server's folder. You should now be able to package/deploy web projects as well.
Please check to see if "Run MSBuild for Project" exists more than once within your TFS Build process template. In my case it existed twice and took me awhile to figure out why the change for ToolPath was not taking the desired effect.
First day trying new VS Community 2015 RC Version 14.0.22823.1 D14REL.
Our TFS server is still TFS 2010; I'm wondering if that's the source of the problem.
Other Team Explorer sections are working fine -- Work Items, Source Control Explorer, Pending Changes. I even did a merge and checkin successfully.
But the Builds section shows this:
I'm not even sure where to look for an error log.
VS.NET 2012, still installed on the machine, shows the Builds section correctly.
As support for TFS 2010 ends before VS 2015 releases don't expect the support to be awesome. If you don't have SP1 then your are already out of support. None of the editions of Visual Studio 2015 (and 2013) officially support TFS 2010 RTM.
I would recommend that you upgrade to TFS 2013, or TFS 2015 at your earliest opportunity. If you need support for that then get a consultant to help who has a good relationship with MSFT.
If your ops team is inside of keeping software up to that's and with the applications support model then you should seriously consider moving to VSO so that you don't have to worry about It any more.
Reinstalling VS 2015 after my Windows 10 debacle, I found that suddenly everything was working including builds! With the server still on TFS 2010. Apparently my problem was that I had the VS 2015 Community Release Candidate, not the final release.
I'm trying to migrate from TFS 2012 Update 2 to TFS 2013.
Following the documentation I installed TFS 2012.2 on the new hardware, backed up/restored the databases, then installed TFS 2013 as an upgrade.
I can see the Team Project and the builds. The problem is when I right click a build to queue up a new one and click on the Parameters tab I just get a blank panel. My best guess is there was an error loading the parameters. Note those builds worked fine in TFS 2012.2.
If I create a new build from scratch and I use their new default template (TfvcTemplate.12.xaml) I still get the same error.
I don't see any errors in the output window or the event log.
It turns out it's a known bug with VS2013 connecting to TFS2013
The VS2013 hotfix has been released. Taken from here.
For future reference, this was fixed in Visual Studio 2013 Update 1 (see KB 2911573).