VS 2017 Build Tools failing with Error MSB4019: The imported project "D:\Microsoft.Cpp.Default.props" was not found - c++

I'm building a new TFS build server and decided to use the VS 2017 Build Tools instead of installing the full versions of VS. When I attempt to build our C++ projects, it throws the following error:
Error MSB4019: The imported project "D:\Microsoft.Cpp.Default.props" was not found.
After many hours of research I'm no closer to resolving this issue. I tried adding the following registry settings but it did not help.
Windows Registry Editor Version 5.00
[HKEY_LOCAL_MACHINE\SOFTWARE\Microsoft\MSBuild\ToolsVersions\14.0]
"VCTargetsPath"="$([MSBuild]::ValueOrDefault('$(VCTargetsPath)','$(MSBuildExtensionsPath32)\Microsoft.Cpp\v4.0\V140\'))"
"VCTargetsPath11"="$([MSBuild]::ValueOrDefault('$(VCTargetsPath11)','$(MSBuildExtensionsPath32)\Microsoft.Cpp\v4.0\V110\'))"
"VCTargetsPath14"="$([MSBuild]::ValueOrDefault('$(VCTargetsPath14)','$(MSBuildExtensionsPath32)\Microsoft.Cpp\v4.0\V140\'))"
[HKEY_LOCAL_MACHINE\SOFTWARE\Microsoft\MSBuild\ToolsVersions\14.0\11.0]
"VCTargetsPath"="$([MSBuild]::ValueOrDefault('$(VCTargetsPath)','$(MSBuildExtensionsPath32)\Microsoft.Cpp\v4.0\V110\'))"
"VCTargetsPath11"="$([MSBuild]::ValueOrDefault('$(VCTargetsPath11)','$(MSBuildExtensionsPath32)\Microsoft.Cpp\v4.0\V110\'))"
[HKEY_LOCAL_MACHINE\SOFTWARE\Microsoft\MSBuild\ToolsVersions\14.0\14.0]
"VCTargetsPath"="$([MSBuild]::ValueOrDefault('$(VCTargetsPath)','$(MSBuildExtensionsPath32)\Microsoft.Cpp\v4.0\V140\'))"
"VCTargetsPath11"="$([MSBuild]::ValueOrDefault('$(VCTargetsPath11)','$(MSBuildExtensionsPath32)\Microsoft.Cpp\v4.0\V110\'))"
"VCTargetsPath14"="$([MSBuild]::ValueOrDefault('$(VCTargetsPath14)','$(MSBuildExtensionsPath32)\Microsoft.Cpp\v4.0\V140\'))"
I'm guessing Microsoft's installer is broken for this product. Is there a standard fix for this error or should I scrap my efforts and simply install the full versions?
In the project file, I found this entry:
<Import Project="$(VCTargetsPath)\Microsoft.Cpp.Default.props" />
So, I guess this means that the variable VSTargetsPath is somehow pointing to the root of the D: drive but I haven't got a clue where that value is being set. Our current build server does not have an environment variable set named VSTargetsPath, but it does have the missing registry entries. It also has full versions of VS installed.

VS 2017 Build Tools failing with Error MSB4019: The imported project “D:\Microsoft.Cpp.Default.props” was not found
Try to pass VCTargetsPath explicitly as property to msbuild from your build configuration:
Edit the build definition for the build.
Click the process tab.
In the Advanced section, set the MSBuild Arguments to include the following property:
/p:VCTargetsPath="C:\Program Files (x86)\Microsoft Visual Studio\2017\xxx\Common7\IDE\VC\VCTargets\"
Save the build definition.
Note: You should change the value of VCTargetsPath to the location of the VCTargets folder.
Or pass VisualStudioVersion as property to msbuild:/p:VisualStudioVersion=15.0
If you are interesting in the value of $(VCTargetsPath), you can check following threads for some more details:
Can't find registry entries for Visual Studio 2017
Visual Studio Locator
Over the years Visual Studio could be discovered using registry keys,
but with recent changes to the deployment and extensibility models a
new method is needed to discover possibly more than once installed
instance. These changes facilitate a smaller, faster default install
complimented by on-demand install of other workloads and components.
vswhere is designed to be a redistributable, single-file executable
that can be used in build or deployment scripts to find where Visual
Studio - or other products in the Visual Studio family - is located.
For example, if you know the relative path to MSBuild, you can find
the root of the Visual Studio install and combine the paths to find
what you need.
You can emit different formats for information based on what your
scripts can consume, including plain text, JSON, and XML. Pull
requests may be accepted for other common formats as well.
vswhere is included with the installer as of Visual Studio 2017
version 15.2 and later, and can be found at the following location:
%ProgramFiles(x86)%\Microsoft Visual Studio\Installer\vswhere.exe.

Related

Visual Studio: copy installation folder and setup it up to be auto-detected by Qt Creator

I wiped out an old Windows 10 and replaced it with a new Windows 10 by ISO image.
Before wiping out, I copied the folder of Microsoft Visual Studio 2017 Community Edition on old Windows to an external hard disk:
xcopy /E "C:\Program Files (x86)\Microsoft Visual Studio" D:\
Now after reinstalling Windows 10, I copied the VS 2017 folder from external the hard disk to the C:\Program Files (x86)\ folder of new operating system.
I did so to avoid having to download VS 2017 again on new OS.
The problem is other software, like Qt Creator, cannot auto-detect the VS C/C++ compilers. I guess that's because the VS 2017 isn't added to path.
The questions are:
What path should I add to system path in order to VS 2017 to be auto-detected by other software like Qt Creator?
Is there any script which I can run to automatically integrate the VS 2017 to the rest of the operating system.
To answer the questions in your issue:
Copying the content of C:\Program Files (x86)\Microsoft Visual Studio folder is not a recommended way to install VS.
(The complete installation will not only set the Environment variables but also set the related registry keys and values. A simple copy may break this process)
So we always suggest that users install the VS by vs-installer or offline installation package. (Same like what Zlatomir suggests.)
To your actual requirements:
It seems you're just trying to use VC++ compiler in QT Creator instead of developing QT projects in Visual Studio. So build tools for VS package is enough for you.
See this related issue, if we download Build Tools for VS package with corresponding C++ workload, then we can get the compiler the QT needs. There's no need to install the VS IDE for this situation.
And if we need C++ compiler from VS2017, download the Build Tools for VS2017, if we need C++ compiler from VS2015, download the Build Tools for VS2015 Update3. Link of old version about VS Tools see here.
Update:
From the the link older downloads we can see:
Choose the download button according to which version we need. We can find both VS2017 build tools package and VS2015's there.
Usually programs on Windows don't work after you just copy the installation folder.
So right now there is little you can do to fix it, even if you partially fix, you have no way to know if something else will be broken in the future.
So the recommended solution is to download the installer again and create an offline installer for the next time this happens, you can do that by running the online installer with the following parameters: vs_community.exe --layout c:\vslayout --lang en-US (replace vs_community.exe with the actual name of the online installer file, or rename it), for more options, that might require a smaller download (example if you only need native and don't need .net) check the documentation here for the full set of options you have.

Visual Studio 2013, error MSB8020: The build tools for Visual Studio 2010 cannot be found

At the start I'd like to note that I've spent some time researching this issue and suggested solutions for similar questions like this one didn't help me.
Problem background
I need to migrate a Firebreath plugin project (which I haven't worked on previously) from PC_1 to PC_2.
As far as I'm aware the project was started on PC_1 on Visual Studio 2010 and later moved to Visual Studio 2013 Pro. There's one solution consisting of 19 projects. I have an instruction which says that in order to get the plugin installer I should first Build project_x and after that Build project_y_WiXInstall. Both steps work without any issues on this machine.
Then there's PC_2 which had Visual Studio 2015 Community installed before I started working on it. I've removed it, installed Visual Studio 2013 Pro (version 12.0.21005.1 REL - exactly the same as on PC_1), moved all of the needed files and I'm trying to get rid of all of the compilation errors. So far I figured out I had to install Cmake 2.8, Windows Driver Toolkit 7.1 and manually override an incorrect VCTargetsPath MSBuild variable
Problem description
Currently when I try to compile the project on the new machine I get these two errors (this is an image link since I can't embed images yet on this account). I'm not sure what's going on with the first error message since it looks incomplete and the file CUSTOMBUILD doesn't exist, but I'm not bothered by it too much since the previous compilation error I fixed also had a similar "artifact" as the first error and it disappeared after fixing the second one.
The covered part of the second error message is the project path. The error origin (Microsoft.Cpp.Platform.targets file, line 64) looks like this:
<!-- Error out if toolset does not exists in Visual Studio 2010 or 2012 -->
<VCMessage Code="MSB8020" Type="Error" Arguments="$(_CurrentPlatformToolsetShortName);$(PlatformToolset)" Condition="'$(ToolsetTargetsFound)' != 'true'" />
What didn't help
The error description suggests using an Upgrade Solution... option, but there's no such thing when I right-click the solution
As an accepted answer for the question I've posted at the start of my post suggests, I've checked the Properties of all 19 of my projects (including the project ZERO_CHECK) but their Platform Toolset is already set to Visual Studio 2013 (v120).
I've also tried changing the Platform Toolset to inherit from parent or project defaults for all of the projects. This resulted in it switching to Visual Studio 2010 (v100) (not installed) and after that I've right-clicked on the projects and chose Upgrade VC++ compiler and libraries. After this the Platform Toolset was back to the Visual Studio 2013 (v120) but it didn't help with the compilation error.
As a NON-accepted answer for the question I've posted at the start of my post suggests, I've tried searching for all of the occurrences of 10.0 and V100 in all of my .vcxproj files to replace them but I haven't found any occurrences of them.
[EDIT]
I just got an idea to try building the project with MSBuild from the command line. There's a bit more info compared to errors inside Visual Studio, so maybe it will help with resolving the issue: https://pastebin.com/JhN3dXM3
So the thing you're missing here is that FireBreath projects are built using CMake -- the actual contents of the build directory should always be completely temporary and never stored in source control. To build the project on a new computer you need to run the prep command again from scratch.
If the previous maintainer changed the build files manually and/or migrated it to a newer version of visual studio without using cmake to do it then they did some very ugly things and all bets are off... good luck.
This is why all the firebreath documentation (I wrote most of it) strongly urges that the build directory be transient and you always do project file updates in cmake.
Hope that helps!

How to set the default Windows kit (SDK) version?

I used to use Windows 8.1 SDK for my C++ application, and everything's working fine. Today I installed the Windows 10 SDK and I can't find a way to make it the default one.
I can hard-code the new SDK path in the Visual Studio project settings, but that is highly undesirable. I want the new kit to be used by default for every new project.
There's no environment variable for the SDK, and I can't find anything in the registry, either.
More precisely, there are Windows SDK entries in the registry, but what I need - the C++ includes and libraries - is called the Windows Kit (located in C:\Program Files (x86)\Windows Kits).
Ok, it seems not a lot of people face thist problem, but i'll still post a workaround to set default sdk version. It worked with Visual Studio 2017 Communtity.
Consider the following situation:
You've got a solution with projects you must not retarget
You had older VS installed earlier on your PC
When you open the solution, VS sets SDK version as 8.1 for some reason, while you use Windows SDK 10
When you try to build you have the following:
Error MSB8036 The Windows SDK version 8.1 was not found. Install the
required version of Windows SDK or change the SDK version in the
project property pages or by right-clicking the solution and selecting
"Retarget solution".
because SDK 8.1 is not installed properly on your PC, and reinstalling it somewhy does not solve the problem.
Others on your team don't have such a problem as the projects don't have Windows SDK version explicitly defined inside *.vcxproj files.
So, obviusly, MS build system with multiple SDKs installed has some kind of confusion, and the worst part is that it results in defining corruptly installed SDK as your default.
I used the following workaround to set default windows SDK explicitly:
Go to [VS installment path]\Common7\IDE\VC\VCTargets
,example:
C:\Program Files (x86)\Microsoft Visual
Studio\2017\WDExpress\Common7\IDE\VC\VCTargets\Microsoft.Cpp.WindowsSDK.props)
Open file Microsoft.Cpp.WindowsSDK.props as an administrator
Find line
<DefaultWindowsSDKVersion Condition="'$(DefaultWindowsSDKVersion)' == ''
and '$(AppContainerApplication)' != 'true'">8.1</DefaultWindowsSDKVersion>
change 8.1 to the SDK version you're sure you have properly installed, then save the file.
In my case it was 10.0.17763.0, so the final line was
<DefaultWindowsSDKVersion Condition="'$(DefaultWindowsSDKVersion)' == ''
and '$(AppContainerApplication)' != 'true'">10.0.17763.0</DefaultWindowsSDKVersion>
Now reopen your solution and try to build it. Should work fine.
My first troubleshooting tips would be to uninstall all the Visual Studio stuff you have, then reboot. Then install the latest version of Visual Studio. Then install any other SDKs that you need via the Visual Studio installer wizard. If you require to have Visual Studio 2015 and 2019 installed, go ahead and install 2015 before you install 2019.
If you want to change the project templates, you can in fact do that. The folder for the default templates is here:
C:\Program Files (x86)\Microsoft Visual Studio\2019\Community\Common7\IDE\ProjectTemplates\VC\WindowsDesktop\
Let's say you want to modify the ConsoleApplication template. Create a new project, in this new project edit the Project Property "SDK version" to be 8.1. Save the project and then go to Project->Export Template. Export the template. It will be a zip file in Documents\Visual Studio 2019\My Exported Templates. Unzip it.
You will notice the .vstemplate file in this folder which is similar to the found in the directory above. You will see in the node it will reference a .vcxproj file. In this .vcxproj file you will find the property:
<WindowsTargetPlatformVersion>8.1</WindowsTargetPlatformVersion>
Therefore in order to modify the default templates to match the template you just exported you will need to add the necessary files and lines XML from the My Exported Templates files and overwrite the defaults in Program Files. These will probably be overwritten each time you update VS tho.
Alternatively just extract the zip file of template you exported to the folder:
ProjectTemplates\VC\WindowsDesktop\
And you will find it in your templates after you reload visual studio

What do I need to install for C++ project / VS 2013 on TeamCity server or Team Foundation Build Service?

I am attempting to build a C++ project in a Visual Studio 2013 solution on TC 8.0.6 (build 27767).
I have installed the latest MSBuild "Microsoft Build Tools 2013" stuff (which is normally installed as part of VS 2013 install) directly on the server.
But I get the following error:
[17:05:23]VCTargetsPath is c:\Program Files (x86)\MSBuild\Microsoft.Cpp\v4.0\
[17:05:23]PlatformToolset is v120
[17:05:23]VCMessage
[17:05:23]c:\Program Files (x86)\MSBuild\Microsoft.Cpp\v4.0\Platforms\Win32
Microsoft.Cpp.Win32.Targets(512, 5): error MSB8008: Specified platform toolset (v120) is not installed or invalid. Please make sure that a supported PlatformToolset value is selected.
[17:05:23]Project MyCppProject\smCpp.vcxproj failed
As far as I can see I have everything I need and I have tried various hacks to set the PlatformToolset to v110 etc., but that doesn't work either.
At this stage I would like to verify exactly what I need to install on the build server. Can someone clarify if I need anything extra please?
Many thanks
Brian
Ultimately you need to set the correct path to MSBuild. With VS 2013, build tooling became part of VS rather than .NET, making it version 12.0 instead of 4.0. The default path in this instance is:
"C:\Program Files (x86)\MSBuild\12.0\bin"
If the team foundation build is broken then it's likely because the TF server is not on version 2013. To fix the problem you need to make yourself a copy of the build template the build definition uses (assuming your version is >= 2010 and < 2013) and point to the correct tooling folder. The build templates are located in the following source path:
$/YourTeamProjectName/BuildProcessTemplates
If you can edit the template in Visual Studio you open the Workflow Foundation design surface. In there find the Run MSBuild for Project tasks (note in the default template there is more than one, but I've shown a pic of what to look for) and change the tool path property to the above path.
Once you created the template you need to change your build definition to use the new template.
For TeamCity you need to set the MSBuild ToolsVersion to version 12.0 in your build step. I'm not sure what version of TC started support for version 12.

MSVCP100D.dll missing

When I try to debug my C++ application I get the error
The program can't start because MSVCP100D.dll is missing from your
computer. Try reinstalling the program to fix this problem.
I found someone with a similar problem here: Remote debugging C++ on the Windows Server 2008 platform with VS2010; MSVCP100D.dll missing however the solution given there doesn't seem to show up when I go to the solution properties.
Would reinstalling Visual Studio fix this problem?
Usually you don't want MSVCP100D.dll on your system. It's for debugging purposes only. If you get this error for your release build you must make sure that you didn't accidently add a 'Debug'-tagged Project Output to your setup project.
If you really need to debug your software on a remote machine, I suggest you do the following:
Create a new Setup project called 'CRTDebug100Setup' and add the following Merge Modules (found under C:\Program Files\Common Files\Merge Modules):
Microsoft_VC90_DebugCRT_x86.msm
policy_9_0_Microsoft_VC90_DebugCRT_x86.msm
Build, and deploy on your computer to be debugged!
Reinstalling Visual Studio fixed the problem.
This can also occur if Generate Debug info is not set to No
Configuration Properties -> Linker -> Debugging -> Generate Debug info
Followup on l33t's answer above (tried to revise it but it did not seem to appear).
Added later by gpicher 10 Jan 2012: I believe those .msm packages would be for a 9.x version of the DLL in question, not a 10.x version. I resolved a similar problem I had by making a setup project with Visual Studio 2010 installed on a 64 bit Windows installation, using the merge module Microsoft_VC100_DebugCRT_x86.msm in the folder C:\Program Files (x86)\Common Files\Merge Modules. There's a similar x64 version of the .msm if the application showing the error dialog is a 64 bit application. In this case a third party was providing me a debug build of their application in order to develop and test new plugin code against, so I couldn't change build settings, and wanted the debug functionality.
Find the Visual Studio 2010 install iso file.
Extract cab44.cab file from the ISO.
Then extract file "F_REDIST_DLL_APPLOCAL_msvcp100d_x86" from the .cab file using 7z.
Rename the file to msvcp100d.dll.
For x64 version. The cab file name is cab26.cab and the file name is F_REDIST_DLL_APPLOCAL_msvcp100d_x64.
For similar issue such missing msvcr*d.dll for another visual studio version. Here is the way I used to find the answer:
Find the Visual Studio ISO.
Extract all the .cab file.
7z.exe t *.cab > filelist.txt
gvim filelist.txt
searching for the interested file name. Hope this helps.