I'm getting ready to start building our new release with Visual Studio 2017. I have not moved to vNext, still XAML, but plan to move forward soon when the dust settles.
At one time I thought I would be using VS 2015 and 2017 on the same machine so I had asked a question on how to differentiate or tell TFS Build which VS version to use. I was told to add these MSBuild params to the Build Definition...
/tv:15.0 /p:VisualStudioVersion=15.0
It turns out the machine will be solely using VS 2017, but I left those parameters in the Build Definition.
When I ran the build, I received this error...
MSBUILD : error MSB1040: ToolsVersion is not valid. The tools version
"15.0" is unrecognized. Available tools versions are "4.0". Switch:
15.0
So, I removed the /tv parameter and the error went away. So, my question is, without the parameter, what tools are being used? Is the toolset TFS or Visual Studio related? Is the v15.0 toolset, if it even exists, a separate installation?
Here is the link to my original discussion on this, but I haven't been able to put it into practice until now...
TFS 2015 XAML Builds with Visual Studio
Any information, help is appreciated!! I just want to better understand what is going on for future server builds.
So, after the first response, here is additional information. From the failed build's diagnostic log, I see this...
MSBuild auto-detection: using msbuild version '15.7.179.6572' from 'C:\Program Files (x86)\Microsoft Visual Studio\2017\Professional\MSBuild\15.0\bin'.
You can able to download the MSBuild 15.0 package alone here
This error will occur in 2 scenarios
MSBUILD : error MSB1040: ToolsVersion is not valid. The tools version
"15.0" is unrecognized. Available tools versions are "4.0". Switch:
15.0
When you don't have installed msbuild 15.0 in your TFS Server
Your TFS Agent pointing wrong MSBuild Version ( see below image pointing towards msbuild version 15.0 )
Solution
For the 1st case, you can download the msbuild package
For the 2nd one, you can define your own Environment Variable to point towards the msbuild 15.0 version.
There is a similar question on MSDN see the solution, though might help.
Related
I'm trying to build VS (version 2019) SSIS project with MSbuild in CMD, but gets error:
The element DeploymentModel beneath element Project is unrecognized.
It worked only after I used this WA from 2017:
https://github.com/dotnet/msbuild/issues/2064#issuecomment-315875143
I was wondering if there is already solution for it or this is just the way it works?
another answer which might be relevant:
https://stackoverflow.com/a/46275125/14976099
I'm asking again as when using devenv you need Visual Studio installed on your computer, and for MSBuild you only need to have the .NET framework installed (which is where I'm hoping to get)
Per my understating, the answer is here and was released few months ago:
https://developercommunity.visualstudio.com/t/support-ssis-ssrs-ssas-in-msbuild/523612#T-N1246482
I'd like our developers to use one version of Visual Studio for all of our projects (where possible) - to that end, I've asked them to use VS2019 for some projects that were originally created in VS2010 and then migrated to VS2013.
A runtime behavior change occurred when running one of these old webforms applications in VS2019. I'm not sure why it's different since the dlls being used are the same and the compiled IL is the same for the method in question, but at the moment I don't really care about "fixing" it since it would require making code changes and regression testing the entire application; a path I'd like to avoid for the moment.
What I'd like to do is make sure VS2019 builds with the indicated tools so that we retain the old behavior. The project file is referencing tools version 12 (VS2013 is not installed), but when Visual Studio builds I see the following in the MSBuild output:
Project file contains ToolsVersion="12.0". This toolset may be unknown or missing, in which case you may be able to resolve this by installing the appropriate version of MSBuild, or the build may have been forced to a particular ToolsVersion for policy reasons. Treating the project as if it had ToolsVersion="Current". For more information, please see http://go.microsoft.com/fwlink/?LinkId=293424.
I installed MSBuild Tools 2013, but that didn't correct the issue before or after a restart. I also tried with tools version 15 and got the same error (VS2017 is installed).
MSBuild from the VS2019 dev command prompt worked, but I had to copy the 14.0 webapplication targets to a new folder named "16.0". I'm not sure why there is a 14.0 folder but no 12.0 or 15.0 folder without doing more searching online.
Is this a fool's errand, or am I missing something simple?
MSBuild from the VS2019 dev command prompt worked, but I had to copy
the 14.0 webapplication targets to a new folder named "16.0". I'm not
sure why there is a 14.0 folder but no 12.0 or 15.0 folder without
doing more searching online.
Update 1
This is just a prompt warning to ensure that you'd better use the related MSBuild version to build the project. It is designed as a reminder message.
But in fact, MSBuild does add backward compatibility feature.
The message is just a warning rather than an error and will not break the build process. And if it breaks the build process, it can prove that backward compatibility is not supported.
You can test it: use VS2019 to build a VS2017 or VS2015 projects and I am sure that it can built them successfully.
==============================================
Each version of VS creates a project that is built for the corresponding MSBuild version.
For example, in the project created in VS2010, its ToolsVersion="4.0", so when you use MSBuild from VS2010(msbuild v4.0), it will built without that warning.
VS2013-->ToolsVersion=12.0 , VS2015-->ToolsVersion=14.0 , VS2017-->ToolsVersion=15.0, VS2019--> ToolsVersion=Current
So when you build the project, you should try the related msbuild version to build them.
Although MSBuild supports backwards compatibility, the problem is always in the form of a warning, which has been troubling us during the project migration.
Solution
To solve it, you should use the related MSBuild to build the project with the corresponding ToolsVersion.
If you want to build them in VS2017, you should change ToolsVersion to 15.0 in every project's xxx.xxproj file.
If you want to build them in VS2019, you should change ToolsVersion to Current in every project's xxx.xxproj file.
More info, you can refer to my answer in this similar issue.
I inherited a lot of stuff that is above my knowledge level, but I am the only one here that is close enough to that level to figure it out. I feel like I learn quickly, and I have been able to jump every hurdle so far without too much time taken, but I just can't figure this out!
Basically we use TFS 2015 and in that we have a build definition that goes through an agent on a remote computer (that I can remote into).So, one of the developers checked in code with an updated NuGet package (Newtonsoft.Json) and it broke the build. The files and everything build locally just fine, but the build bot is broken.
I have a screenshot on imgur for a little context in my build definition and the webhook we use to send the notification in slack links to a an error page that tells me "error: Build Not Found" so I am all kinds of confused and I can't find anything online that can help me.
EDIT:
In my build logs I got this error
Error CS0246: The type or namespace name 'DataSourceRequest' could not be found (are you missing a using directive or an assembly reference?)
All of my other branch builds work and the only difference is that I updated the nuget package. Is there any way for me to upgrade the nuget package in the build agent?
Screenshot of Build Definition:
Build Definition Not Building After Nuget package Update In Visual Studio
AFAIK, the reason of this issue may be that you upgraded the package Newtonsoft.Json to version 9.01 or higher.
Starting from Newtonsoft.Json 9.0.1, this package supports the targets framework .NETStandard:
https://www.nuget.org/packages/Newtonsoft.Json/9.0.1:
Which is supported by NuGet 2.12 for Visual Studio 2013:
NuGet 2.12 Release Notes
Full NetStandard and NetCoreApp support for VS2013.
So, to resolve this issue, you should make sure the nuget.exe version is higher than 2.12 and the Visual Studio version is high than 2013.
Besides, as we know, Visual Studio are backwards compatible. Meaning we could use the lower version Visual Studio to develop the project and we could build it with a higher version of Visual Studio on the agent. But if the other way around, develop it with higher version, build it with lower version on the agent, we may encounter some issues due to compatibility. So, If we keep that the Visual Studio version on the agent is higher than the version you are developing, it would be better.
Hope this helps.
How to debug a project file in MSBuild 12.0 / VS2013? has an answer, but apparently that method is not supported in Visual Studio 2015/MSBuild 14. Does anyone know a way to perform MSBuild debugging in Visual Studio 2015/MSBuild 14? Bonus points for scoop about Visual Studio 2017.
The MSBuild debugger was never officially supported and was cut from MSBuild in favor of cross-platform support in the VS 2015/MSBuild 14 timeframe.
There are many ways to debug the behavior of a build. The combination of a Verbosity=Diagnostic build log and the preprocessed project (msbuild /pp:preprocessed.xml path\to\the.csproj creates a file containing all of the build logic for a given project) is extremely powerful. You may also be interested in the UI that the MSBuildStructuredLog provides, which helps pare down the massive output produced by a diagnostic log.
It really works well in old VS version:
But if I use the VS2015, I got the same issue as yours, it could recognize the /debug command line.
I report this issue to the product team here:
https://connect.microsoft.com/VisualStudio/feedbackdetail/view/3120913/how-to-debug-a-project-file-in-msbuild-14-0-vs2015
You could check the latest update from it, of course, please also vote and add your comment there:)
I recently migrated my VSTO Add in projects from "VS2008 and office 2007" to "VS2013 and office 2013", Changes took place as below settings.
.Net Framework version from 3.5 to 4.5(While upgrading project).
I have added VSTO 2013 PIA assemblies to reference.
That's it, when i tried to compile i have faced below MSBuild errors.
C:\Program Files (x86)\MSBuild\Microsoft\VisualStudio\v12.0\OfficeTools\Microsoft.VisualStudio.Tools.Office.targets(268,13): error MSB4064: The "TargetFrameworkVersion" parameter is not supported by the "SignFile" task. Verify the parameter exists on the task, and it is a settable public instance property.
C:\Program Files (x86)\MSBuild\Microsoft\VisualStudio\v12.0\OfficeTools\Microsoft.VisualStudio.Tools.Office.targets(264,9): error MSB4063: The "SignFile" task could not be initialized with its input parameters.
and i have tried to find solutions over the internet but couldn't find much, Any Solutions for this problem will be helpful.
The problem was not the MSBuild, **
i have updated visual studio update 3 to update 4
and started working like charm.
I think Microsoft guys have moved something around from Update 3 to update 4 but this has been reported several times in many forums and i don't know why they have not mentioned it but this is one effective solution.
I ran into this issue. The problem is that Update 3 of Visual Studio 2013 moved some things around, so you need to use the MSBuild that is now installed with Visual Studio 2013 (or the standalone build tools for build servers). You need to make sure that you're using the correct MSBuild (currently at C:\Program Files (x86)\MSBuild\12.0\Bin), and it should work.
http://datatoknowledge.com/2015/01/30/vsto-and-visual-studio-2013-update-3/
Erick
This is still not working as of Visual Studio 2015 Update 3.
I had to actually modify the C:\Program Files (x86)\MSBuild\Microsoft\VisualStudio\v14.0\OfficeTools\Microsoft.VisualStudio.Tools.Office.targets file and remove the TargetFrameworkVersion attribute from the SignFile task.