TFS won't compile string interpolation syntax - tfs

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.

Related

TFS 2013 and Visual Studio 2017 Syntax

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.

BuildActivity ignores ToolsVersion

I have a Continuous Integration Build Running on a BuildAgent which I can not get working properly. I recently changed our codebase to C# 6.0 and changed the projects to ToolsVersion 14.
I did install Visual Studio 2015 on the Build Server (TFS 2012). If I do now check in the C# 6.0 code the build fails on the first project ("$" is unexpected or something")
The BuildTemplate is "DefaultTemplate.11.1"
If I check the log files the build calls the wrong csc.exe (C:\Windows\Microsoft.NET\Framework64\v4.0.30319\Csc.exe)
if I do start the MSBuild/14.0/Bin/MSBuild executable with the project without any switches the Build succeeds. Why does the TFS BuildAgent not use the ToolsVersion and how can I get TFS 2012 to build my Visual Studio 2015 solution
If I add the MSBuildArgument /tv:14.0 it still fails. As it calls th Version 12 of MSBuild which is part of the .NET 4.6 RC Framework which ships with Visual Studio 2015.
Changing the ToolsPath of the MSBuild Activity does get the Build working but spits bullets if I try to run my UnitTest. I get aMissing dlls "Microsoft.VisualStudio.TestPlatform.Utilities.dll" exception. (VS2012 is installed as well on the Build Server).
UPDATE:
I do now get a different error with my unit tests:
TF900548: An error occurred publishing the Visual Studio test results.
Details: 'Method not found:
'System.Collections.Generic.IEnumerable<System.String>
Microsoft.VisualStudio.TestPlatform.Utilities.InferSettingsHelper.MergeRunSettingsAndFindCompatibleSources(Microsoft.VisualStudio.TestPlatform.ObjectModel.Architecture
ByRef,
Microsoft.VisualStudio.TestPlatform.ObjectModel.FrameworkVersion
ByRef, System.String, System.String,
System.Collections.Generic.IDictionary`2<System.String,System.Collections.Generic.KeyValuePair`2<Microsoft.VisualStudio.TestPlatform.ObjectModel.Architecture,Microsoft.VisualStudio.TestPlatform.ObjectModel.FrameworkVersion>>,
System.Xml.XPath.IXPathNavigable, System.String ByRef)'.'
For those of us not living inside build templates every day here's the steps that got it working for me:
First find the template associated with your build (if you already know where to find it skip a couple steps).
Just right click the build definition and select Edit build definition
Select the Process tab and you'll see the name of the template (quite likely to be DefaultTemplate if you haven't customized it). On the far right click Show details to see the path for the template.
Go to the Home tab under Team explorer and click Source control explorer
Find the template file and double click to edit it. It should come up in a graphical view like this. Scroll till you find Run MSBuild for Project
Click on this item which will immediately bring up properties
Click on the little icon on the right - don't try and type it in because it'll probably explode and crash Visual Studio.
Enter IN QUOTES the following "C:\Program Files (x86)\MSBuild\14.0\bin"
NOW FOR THE MOST IMPORTANT PART
For me the Run MSBuild for Project was in TWO places.
So I just repeated the above steps in both places, and then after I checked in the .xaml file my build FINALLY worked fine.
You may need to recycle the agent / controller from within the TFS tool.
Edit template change msbuild activity ToolPath to "MSBuild/14.0/Bin/MSBuild"
See answer by Marson.
Using the TfvcTemplate.12.xaml build process template with the /tv:14.0 Build argument worked for me.
use msbuild aruguments /p:VisualStudioVersion=14.0

Built tests are not added to the Visual Studio Test Explorer window

I set up the SpecFlow plug-in for the Visual Studio 2013.
I created new Feature Item and build it.
Result: built test is not shown in the Test Explorer. Why?
I do it according to this video
in order to configure it to generate MSTest tests you need to add this to your app.config:
<specFlow>
<unitTestProvider name="MSTest"></unitTestProvider>
</specFlow>
I experience this same problem, but the solution was different.
Following the advice on a SpecFlow Github issue, the following worked for me:
Close all Visual Studio instances
Go to %TEMP%\VisualStudioTestExplorerExtensions\
Delete all the folders in here
Try again
if the tests are not showing in the test explorer you need to install NUnit test adapter :
go to Tools->Extensions and updates ->Online->Visual Studio Gallery->Tools->Testing and select NUnit Test Adapter
Visual Studio can change the default processor architecture when it loads. While looking endlessly trying to figure out the issue, I finally figured it out, that it wasn't really Specflow causing the issue.
If you have references that require a special architecture, it will prevent the tests from showing up in the test explorer. Change the architecture to x86 or x64 based on your needs.
Another thing you can do to see the build issues is open the Output window and change the dropdown to Tests during build. It will highlight any information of things taking place during your build.
I felt somebody should mention it just in case.
I'm running SpecFlow tests with SpecRunner and had this same problem, a couple of times as a matter of fact.
Having tried all of the above suggestions, I found that the only solution to the problem was to uninstall and reinstall the SpecRun NuGet package. Next build, tests present in Test Explorer window as expected.
In my case the reason why tests weren't discovered were because I was using Resharper build.
As soon as I went to: Resharper -> Options -> Tools -> Build -> General: "Use ReSharper Build"(untick), then all tests were suddenly discovered.
In my case all the approaches above didn't work. My solution: I don't know why, but - I re-installed "Specflow for Visual Studio 2015" in "Tools => Extensions and Updates", then I've created a new feature file (old still didn't work), and this new feature-file works correctly.
For me, I changed from using direct DLL references to using the NuGet references of version 3.1.7.4 of SpecFlow and this solved the problem.
I needed to reference "SpecFlow", "SpecFlow.NUnit" and "SpecFlow.Tools.MsBuild.Generation".
and then clicked the "Show All Files" button in Visual Studio to see the code behind file at a sibling level to it associated Feature file (this used to be an associated child file of the feature file in older versions).
I also need to use the "Include In Project" context menu item on the code behind file, for tests to show up in Visual Studios "Test Explorer".
NOTE: I did try to unzip the Specflow required files from the NuGet package and reference them directly in my project to be consistent with other direct references in my project (non-NuGet references) but this doesn't seem to work and you have to use the NuGet reference. I found an closed issue in github, which states that we have to use the Nuget reference to get the tests to work in Test Explorer:
https://github.com/techtalk/SpecFlow/issues/1617
For me, the issue was the TestAssemblyPath in my srprofile file. It didn't match my actual dll name.
I tried installing the Nugget package
SpecFlow.Tools.MsBuild.Generation
with the same version than specflow and now I can see the test in TestExplorer, other ways not works for me.
I already had installed 1 from
Nugget Package Specflow
Specflow.NUnit
Nunit
Nunit3TestAdapter
and the extension for Visual Studio for Specflow a NUnitTestAdapter

How to rename build name with assembly version?

Pls see screenshot. I have setup continuos integration with tfsservice.
It builds and deploys after each checkin.
I would like to append or pre-pend if that word exists, the assembly version so that I can easy recognize what build generated what version, and I can easy identify in which build a bug appeared.
If you mean you need to get the version number from a library during the build, then you can use the Assembly class in the MSBuild Extensions Pack to get the version number from the desired library.
This is feasible, but you need to customize your build template.
A good starting point is the Visual Studio ALM Rangers' BRDLite Reference Templates. See Assembly Versioning example in the BRDLite.Asp.NetTemplate.2012.2.xaml template.

How do I make TFS 2012 build separate output binaries by project framework [duplicate]

We have a very large solution (some 300+) projects and we are trying to build it via MSBuild on TFS2010.
We can build it via MSBuild on all out development machines, and are in the process of adopting TFS.
The structure of our code is like so:
bin\Client
bin\Server
Framework\ClientFramework.csproj
Modules\Module1\Project1
Modules\Module2\Project2
etc.
Each project has a relative OutputPath which builds the code to the bin Client or Server directory. So for example, Project1.csproj has an OutputPath of "..\..\bin\Client".
We seem to be having a problem that in TFS MSBuild the OutDir is set to a Fixed Path:
C:\Builds\MyProject\Binaries\
So things are getting confusing when resolving the relative OutputPath on top of the OutDir
ClientFramework goes to C:\Builds\MyProject\Binaries\..\bin\Client
Project1 goes to C:\Builds\MyProject\Binaries\..\..\bin\Client
etc.
We also have some Post build events that copy some 3rd Party dll's to the bin folders, these paths cannot be resolved properly either.
I think the solution we are after is to build everything to our existing bin\Client, bin\Server structure and then move the Folders from bin to Binaries.
Any ideas on how to accomplish this or how we should be working, are appreciated, but updating our existing projects might prove problematic, as it all works with VS, developer command line builds and with CC.net.
Since this is first link that pops up with a Google search of "TFS OutDir", I must provide a newer solution. I spent an entire day playing around with OutDir, OutputPath, and overriding them with TeamBuildOutDir. A better solution is to set the MSBuild property GenerateProjectSpecificOutputFolder. It comes with .NET 4.5. More info here: http://blog.codeassassin.com/2012/05/10/override-the-tfs-team-build-outdir-property-net-4-5/
I found the answer on MSDN : http://msdn.microsoft.com/en-us/library/ff977206.aspx

Resources