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:)
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'm currently using a .net core visual studio publish, and its including the runtime dlls in the output. I do not want these files, but would like to use the hosting bundles on the server.
This is a new thing, it didn't use to include these dlls with a publish. I think it might have been triggered by a visual studio update, but I am not positive why its happening.
Here's my settings:
The Deployment Mode is not set to "Self-Contained" which I think is the setting that should force the runtime to be included.
I've done tons of googling but can't seem to find any other configuration that would be related to this. Any guidance would be greatly appreciated!
Posting an answer, just in case anyone else ends up here. I found the answer mostly because of Lex Li comment.
The most recent upgrade to visual studio / .net core seems to require you to specificity a target runtime in your Publish Profile. In order to make this work, you will be forced to upgrade your project to 2.1 or higher. Otherwise visual studio will choose portable by default, and include the runtime dlls in the publish.
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.
I want to start the develop of a custom project type for Visual Studio that builds a BPR project with Visual Studio.
I need some hints to beginning with this project. Where can I find a template for this type of projects?
My target is to remove the Borland C++Builder's ugly and unstable interface from the development process and work enterely from Visual Studio.
Edit: Oops, I didn't really see that you're about to create a new project type for C++ Builder files. In that case, you have to build a language package. The Visual Studio Extensibility site should get you started. Also have a look at this more specific link.
I'll leave my old answer here for reference, because it might help people who just want to build C++Builder projects without creating a whole new project type :)
You didn't specify the version of Visual Studio, but I'll assume a recent one. In Visual Studio 8 and 9, most project files (all popular ones except Visual C++) are actually MSBuild files and can therefore be built by MSBuild. You can add a simple command line task (Exec) to build your bpr on the command line, or you can create a custom task for this (if you don't find one already available - the search terms should be MSBuild and custom task). This way, both Visual Studio and MSBuild can build anything you like. If you don't have an MSBuild file to start with or want to dive into developing a task, the MSBuild project template for Visual Studio will help you.
Oh, and other than that, if you don't actually need C++Builder things, you might as well export the BPR as a solution (or create a new solution and add the files).
Integrating C++Builder projects into a build process should be a lot easier with C++Builder 2007 or 2009 as both use MSBuild as build system. But then, I think that upgrading to a recent version of C++Builder solves your problem the other way :)