Where is WindowsSDK_IncludePath defined? - visual-studio

The macro $(WindowsSDK_IncludePath) has the values shown in the picture.
I'd like to know where those values are defined, they must be defined in some files.
The picture was taken from Visual Studio 2013.

In my case, the WindowsSDK_IncludePath variable was correctly defined and in fact it worked perfectly in Visual Studio 2013. So I even uninstalled and reinstalled VS2015. Then I found thanks to this link that the preset macro variables can be modified by specific user settings. These user settings are stored in C:\Users\<user>\AppData\Local\Microsoft\MSBuild\v4.0\Microsoft.Cpp.Win32.user.props which in my case read as follows:
<?xml version="1.0" encoding="utf-8"?>
<Project DefaultTargets="Build" xmlns="http://schemas.microsoft.com/developer/msbuild/2003">
<ImportGroup Label="PropertySheets">
</ImportGroup>
<PropertyGroup Label="UserMacros" />
<PropertyGroup>
<IncludePath>$(VC_IncludePath);$(WindowsSDK_IncludePath);C:\Program Files (x86)\CodeSynthesis XSD 4.0\include;</IncludePath>
<LibraryPath>$(VC_LibraryPath_x86);$(WindowsSDK_LibraryPath_x86);C:\Program Files (x86)\CodeSynthesis XSD 4.0\lib\vc-12.0;</LibraryPath>
<ExecutablePath>C:\Program Files (x86)\CodeSynthesis XSD 4.0\bin;$(VC_ExecutablePath_x86);$(WindowsSDK_ExecutablePath);$(VS_ExecutablePath);$(MSBuild_ExecutablePath);$(SystemRoot)\SysWow64;$(FxCopDir);$(PATH);</ExecutablePath>
</PropertyGroup>
<ItemDefinitionGroup />
<ItemGroup />
</Project>
Somehow the <IncludePath> sentence made it impossible for VS2015 to find the correct value. In my laptop computer where everything worked correctly, the file was basically empty:
<?xml version="1.0" encoding="utf-8"?>
<Project DefaultTargets="Build" xmlns="http://schemas.microsoft.com/developer/msbuild/2003">
<ImportGroup Label="PropertySheets">
</ImportGroup>
<PropertyGroup Label="UserMacros" />
<PropertyGroup>
</PropertyGroup>
<ItemDefinitionGroup />
<ItemGroup />
</Project>
After setting my file just like the one in my laptop, everything worked normally. Of course I lost the execution preference of CodeSynthesis XSD but right now I am not working on any project that use it. I will continue experimenting with different variants of this file.

For me it was the file Microsoft.Cpp.Common.props in folder C:\Program Files (x86)\MSBuild\Microsoft.Cpp\v4.0\V140, where I had to change the hardcoded Windows 10 SDK version from 10.0.10240.0 to 10.0.10586.0.
<!-- 10.0.10240.0 is the hardcoded checked-in version of uCRT that we use in case we target 8.1 SDK -->
<TargetUniversalCRTVersion Condition="'$(TargetUniversalCRTVersion)' == '' and ('$(TargetPlatformVersion)' == '8.1' or '$(DefineWindowsSDK_71A)' == 'true')">10.0.10586.0</TargetUniversalCRTVersion>
I'm using VS2015 on Windows 10 and wasn't able to compile against Windows 8.1 SDK because of missing include files. Installing the standalone Windows 10 SDK didn't help either (because it doesn't contain ucrt files for 10.0.10240 like ctype.h a.s.o.).

I see the data in file sdk.props in folder C:\Program Files (x86)\Windows Kits\8.0\build\CommonConfiguration\Neutral
<PropertyGroup>
<WindowsSdkDir Condition="'$(WindowsSdkDir)' == ''">$([MSBUILD]::GetDirectoryNameOfFileAbove('$(MSBUILDTHISFILEDIRECTORY)', 'sdkmanifest.xml'))</WindowsSdkDir>
</PropertyGroup>
<PropertyGroup> <WindowsSDK_IncludePath>$(WindowsSdkDir)Include\um;$(WindowsSdkDir)Include\shared;$(WindowsSdkDir)Include\winrt;</WindowsSDK_IncludePath>
</PropertyGroup>
I use a Win8 + VS2012, so it should be in folder 8.1 for your VS2013 + 8.1 SDK.

I find Reason that : Windows Registry
[HKEY_LOCAL_MACHINE\SOFTWARE\Microsoft\Windows Kits\Installed Roots]
"KitsRoot10"="C:\\Program Files\\Windows Kits\\10\\"
but in Actually
"KitsRoot10"="C:\\Program Files (x86)\\Windows Kits\\10\\"
"AppVerifier64BitAutomationRoot"="C:\\Program Files\\Application Verifier\\"
"KitsRoot81"="C:\\Program Files (x86)\\Windows Kits\\8.1\\"

Search for *.props in C:\Program Files (x86)\Windows Kits\
In my case the file causing the problem was UAP.props. Editing the file and changing 4.7.1 to 4.6.1 solved the issue.
<PropertyGroup>
<WindowsSdkDir Condition="'$(WindowsSdkDir)' == ''">$([MSBUILD]::GetDirectoryNameOfFileAbove('$(MSBUILDTHISFILEDIRECTORY)', 'sdkmanifest.xml'))\</WindowsSdkDir>
<DotNetSdkRoot Condition="'$(DotNetSdkRoot)' == ''">$(Registry:HKEY_LOCAL_MACHINE\SOFTWARE\Microsoft\Microsoft SDKs\NETFXSDK\4.7.1#KitsInstallationFolder)</DotNetSdkRoot>
<DotNetSdkRoot Condition="'$(DotNetSdkRoot)' == ''">$(Registry:HKEY_LOCAL_MACHINE\SOFTWARE\Wow6432Node\Microsoft\Microsoft SDKs\NETFXSDK\4.7.1#KitsInstallationFolder)</DotNetSdkRoot>
</PropertyGroup>

Related

Get the correct $(VisualStudioVersion) for VS 2017 inside a MSBuild file

I have a MSBuild file to publish a solution (created in VS 2013 and ported to VS 2017) to a remote server. The offending line is this one:
<PropertyGroup>
<VisualStudioVersion Condition="'$(VisualStudioVersion)' == ''">10.0</VisualStudioVersion>
<VSToolsPath Condition="'$(VSToolsPath)' == ''">$(MSBuildExtensionsPath32)\Microsoft\VisualStudio\v$(VisualStudioVersion)</VSToolsPath>
</PropertyGroup>
When I run the command:
"C:\Program Files (x86)\Microsoft Visual Studio\2017\Professional\MSBuild\15.0\Bin\msbuild" WebSite1_Web_configs.build /p:Configuration=Integracion;Platform="AnyCPU" /p:VisualStudioVersion=15.0
After some compilation, it ends up with this error:
Error MSB4062 The "TransformXml" task could not be loaded from the assembly C:\Program Files (x86)\Microsoft Visual Studio\2017\Professional\MSBuild\Microsoft\VisualStudio\v12.0\Web\Microsoft.Web.Publishing.Tasks.dll
Of course it can't be loaded, because the version should be 15.0, not 12.0.
Things I have tried:
Adding the /p:VisualStudioVersion=15.0 to the command where I call MSBuild. It doesn't work.
Changing, inside the *.csproj file, the element:
<Project ToolsVersion="12.0" DefaultTargets="Build" xmlns="http://schemas.microsoft.com/developer/msbuild/2003">
For:
<Project ToolsVersion="15.0" DefaultTargets="Build" xmlns="http://schemas.microsoft.com/developer/msbuild/2003">
It doesn't work.
So, how can I get the correct VS version with $(VisualStudioVersion) inside the MSBuild file without having to hardcode it?
Ok, the problem was that I had <Import> elements at the end of the *.build file. One of those imports had part of the path hardcoded:
<Import Project="$(MSBuildBinPath)\Microsoft.CSharp.targets" />
<Import Project="$(MSBuildExtensionsPath32)\Microsoft\VisualStudio\v12.0\WebApplications\Microsoft.WebApplication.targets" />
I changed it to:
<Import Project="$(MSBuildExtensionsPath32)\Microsoft\VisualStudio\v$(VisualStudioVersion)\WebApplications\Microsoft.WebApplication.targets" />
I executed MSBuild with the /p:VisualStudioVersion=15.0 parameter and it worked.
Please, if you have the same problem, check if you have imports with hardcoded paths.
On Visual Studio 2017, instead of edits the .csproj file, you can simple go to Visual Studio Package Manager Console (Tools -> NuGet Package Manager -> Package Manager Console) and install Web.Targets:
Install-Package MSBuild.Microsoft.VisualStudio.Web.targets

Why doesn't Directory.Build.props work when building a solution using Visual Studio 2017?

I have a Directory.Build.props file located in the same directory as the .sln file.
<Project>
<PropertyGroup Condition=" '$(Configuration)|$(Platform)' == 'Debug|AnyCPU' ">
<DocumentationFile>bin\Debug\$(MSBuildProjectName).xml</DocumentationFile>
</PropertyGroup>
<PropertyGroup Condition=" '$(Configuration)|$(Platform)' == 'Release|AnyCPU' ">
<DocumentationFile>bin\Release\$(MSBuildProjectName).xml</DocumentationFile>
</PropertyGroup>
</Project>
When I build the solution using MSBuild, I am able to generate the XML files properly. However, using a Build -> Rebuild Solution task in Visual Studio doesn't generate the XML file.
Is there a difference in how Visual Studio 2017 builds and uses Directory.Build.props as opposed to MSbuild?
I had added the directory.build.props as a solution item. This somehow prevented Visual Studio from picking it up and using it in the build process. Once I removed it as a solution item, this worked fine.
You also might have to delete your .vs directory (or portion of) as it seems to be cached there as well.
https://developercommunity.visualstudio.com/content/problem/248037/defaultbuildprops-with-langversion-is-not-used-by.html
You need to check that your project file contains next row in the beginning of file
<?xml version="1.0" encoding="utf-8"?>
<Project ToolsVersion="15.0" xmlns="http://schemas.microsoft.com/developer/msbuild/2003">
<Import Project="$(MSBuildExtensionsPath)\$(MSBuildToolsVersion)\Microsoft.Common.props" Condition="Exists('$(MSBuildExtensionsPath)\$(MSBuildToolsVersion)\Microsoft.Common.props')" />
Without row Import 'magic' doesn't happen. So, you need to insert this row to all your old projects

Create proj file that loads csproj files into solution explorer when opened with visual studio

I am building a project file for our application that I am going to execute from our build machine. I was wondering if it is possible for me to open the project file and get the same view visual studio gives me of the solution when I open a solution file.
So here is my Contosa.proj file so far.
<?xml version="1.0" encoding="utf-8"?>
<Project DefaultTargets="Build" ToolsVersion="12.0" xmlns="http://schemas.microsoft.com/developer/msbuild/2003">
<PropertyGroup>
<Configuration Condition=" '$(Configuration)'=='' ">Debug</Configuration>
<RootNamespace>Contosa</RootNamespace>
<AssemblyName>Contosa</AssemblyName>
</PropertyGroup>
<ItemGroup>
<Projects Include="C:\Users\localuser\Documents\Perforce\Contosa\Branches\Working23\UI\Desktop\ContosaClient\ContosaClient.csproj" />
</ItemGroup>
<Import Project="$(MSBuildToolsPath)\Microsoft.CSharp.targets" />
<Target Name="Build">
<PropertyGroup>
<Contosa>$(MSBuildProjectDirectory)\UI\Desktop\ContosaClient\ContosaClient.csproj</Contosa>
</PropertyGroup>
<MSBuild Projects="$(Contosa)"
Properties="Configuration=QA;
VisualStudioVersion=12.0;
DevEnvDir=C:\Program Files (x86)\Microsoft Visual Studio 12.0\Common7\IDE\;
SolutionDir=$(MSBuildProjectDirectory)\"/>
</Target>
</Project>
Currently double clicking this file with visual studio as its associated application will open the Contosa.proj for text editing. I would really like it to be possible to associate my Contosa.proj file with visual studio like our Contosa.sln file is. So when developers open it with visual studio they get the same view that you get from the Contosa.sln. I don't understand what parts of a csproj or a sln file make them open as projects or solutions in visual studio.
UPDATE 1
I am looking to do what this user Replace .sln with MSBuild and wrap contained projects into targets did but I want the project file to be able to opened by the user like a solution file. I want the Projects I include to be loaded into the solution explorer.
When visual studio installs, it configures explorer to launch visual studio when a .csproj is doubleclicked (How can I set a file association from a custom file type to a program). Your windows, and your developers windows, don't know what a .proj is. So rename it .csproj or distribute a .sln which references .proj

Is there a way to global set the platform toolset to v110 on VS 2013?

I've been perusing through similar questions on stack overflow and could not find a specific or definitive enough answer to this question:
I am currently using MSVS 2013 Ultimate, and have separately downloaded MS build tools 2013 as well. I am trying to install some npm modules that use the earlier platform toolset of MSBuild to compile and after following instructions from MSDN on how to Modify the Target Framework to a different platform, those did not help me successfully download the packages either. My current project is dealing with javascript and I'm not using visual studio in the near future, so I'm extremely flexible in terms of changing its configuration settings at the moment.
I am afraid that I'll have to resort to downloading VS 2012 in order to do this, unless someone found a clear cut alternative.
I am currently running everything on Windows 8 Enterprise x64.
Thanks in advance for all the help.
You can make use of the ImportBefore extension points for MsBuild: add propertysheets to
$(VCTargetsPath)\Platforms\$(Platform)\ImportBefore
and add properties to them forcing the PlatformToolset irregardless of what is set in the vcproj files. With VS2013 it is a bit more difficult to do this compared to VS2012 (I used this trick there to globally build everything using the v110_xp toolset) but it still works.
Suppose you are on a 64bit machine and want to override settings for all C++ projects for the Win32 platform, add a property sheet called override_platformtoolset.props (the name doesn't matter, as long as it ends with .props) to the directory C:\Program Files (x86)\MSBuild\Microsoft.Cpp\v4.0\V120\Platforms\Win32\ImportBefore\Default with this content:
<?xml version="1.0" encoding="utf-8"?>
<Project ToolsVersion="4.0" xmlns="http://schemas.microsoft.com/developer/msbuild/2003">
<PropertyGroup>
<PlatformToolSet>v110</PlatformToolSet>
<DefaultPlatformToolset>v110</DefaultPlatformToolset>
</PropertyGroup>
<Target Name="ShowOverrideInfo1" BeforeTargets="Build">
<Message Text="Overriding PlatformToolset!" Importance="high"/>
</Target>
</Project>
Then add another file called override_platformtoolset to C:\Program Files (x86)\MSBuild\Microsoft.Cpp\v4.0\V120\Platforms\Win32\ImportBefore with this content:
<?xml version="1.0" encoding="utf-8"?>
<Project ToolsVersion="4.0" xmlns="http://schemas.microsoft.com/developer/msbuild/2003">
<PropertyGroup>
<PlatformToolSet>v110</PlatformToolSet>
<ToolsetPropsFound>false</ToolsetPropsFound>
<MinSupportedVCTargetsVersion>v110</MinSupportedVCTargetsVersion>
</PropertyGroup>
<Target Name="ShowOverrideInfo2" BeforeTargets="Build">
<Message Text="Overriding PlatformToolset!" Importance="high"/>
</Target>
</Project>
The targets are just there to make sure you put the files in the correct location: if you build now, you should see the Overriding PlatformToolset! message twice (and see that cl.exe and link.exe are invoked from C:\Program Files (x86)\Microsoft Visual Studio 11.0\VC\bin). Else something is wrong.
If you wonder how/why this works inspect Microsoft.Cpp.Defaults.props and Microsoft.Cpp.props.props in C:\Program Files (x86)\MSBuild\Microsoft.Cpp\v4.0\V120.

How can I use a single Visual Studio solution to build both x86 and x64 at the same time?

I've got an x86 Visual Studio solution with many project files in it. Some of the DLL files are designed to work as plug-ins to other applications on a user's system.
We're expanding some of the DLL files to be able to support 64-bit applications. I'd like to set up the solution/projects so that just hitting "Build" will build both the x86 and x64 versions of those DLL
files. The solution contains both C++ and C# projects.
I realize that "Batch Build" is capable of building both, though it would be more convenient if developers could just click the same button as they have previously and have all of the output DLL files generated.
Here are a couple of the modifications that I've tried to a test project, but that I haven't gotten to work:
I've tried modifying the <Target Name="AfterBuild"> to try:
<Target Name="AfterBuild" Condition=" '$(Platform)' == 'x86' ">
<PropertyGroup>
<Platform>x64</Platform>
<PlatformTarget>x64</PlatformTarget>
</PropertyGroup>
<CallTarget Targets="Build"/>
</Target>
But that results in the following error:
C:\Windows\Microsoft.NET\Framework\v3.5\Microsoft.Common.targets(565,5): error MSB4006: There is a circular dependency in the target dependency graph involving target "Build".
I think my conditions will prevent infinite recursion, but I understand how MSBuild could not see it that way.
I've also tried:
<Project DefaultTargets="MyBuild86;MyBuild64" xmlns="http://schemas.microsoft.com/developer/msbuild/2003" ToolsVersion="3.5">
...
<Target Name="MyBuild86">
<PropertyGroup>
<Platform>x86</Platform>
<PlatformTarget>x86</PlatformTarget>
</PropertyGroup>
<CallTarget Targets="Build"/>
</Target>
<Target Name="MyBuild64">
<PropertyGroup>
<Platform>x64</Platform>
<PlatformTarget>x64</PlatformTarget>
</PropertyGroup>
<CallTarget Targets="Build"/>
</Target>
But my DefaultTargets appears to be ignored from within the Visual Studio IDE.
Last, I've tried creating a separate project that imports the first project:
<?xml version="1.0" encoding="utf-8"?>
<Project ToolsVersion="3.5" DefaultTargets="Build" xmlns="http://schemas.microsoft.com/developer/msbuild/2003">
<PropertyGroup>
<Configuration Condition=" '$(Configuration)' == '' ">Debug</Configuration>
<Platform>x64</Platform>
<PlatformTarget>x64</PlatformTarget>
<ProductVersion>9.0.30729</ProductVersion>
<SchemaVersion>2.0</SchemaVersion>
<OutputPath>..\$(Configuration)\x64\</OutputPath>
<ProjectGuid>{A885CAC3-2BBE-4808-B470-5B8D482CFF0A}</ProjectGuid>
</PropertyGroup>
<Import Project="BuildTest.csproj" />
</Project>
And this so far has shown the most promise. However, Visual Studio seems to ignore my OutputPath setting from this new project and instead outputs the EXE/DLL file to the path specified in the original project. There isn't any PropertyGroup block that I can see that is being executed in the original project to override this, so I'm not sure what's happening.
We do something similar to build core assemblies for .NET Compact Framework.
Try this:
<Target Name="AfterBuild">
<MSBuild Condition=" '$(Platform)' == 'x86' " Projects="$(MSBuildProjectFile)" Properties="Platform=x64;PlatFormTarget=x64" RunEachTargetSeparately="true" />
</Target>
Importing a project in such manner works for me in Visual Studio 2010:
TestProject64.vcxproj
<?xml version="1.0" encoding="utf-8"?>
<Project DefaultTargets="Build" ToolsVersion="4.0" xmlns="http://schemas.microsoft.com/developer/msbuild/2003">
<Import Project="TestProject.vcxproj" />
<ItemGroup Label="ProjectConfigurations">
<ProjectConfiguration Include="Release|x64">
<Configuration>Release</Configuration>
<Platform>x64</Platform>
</ProjectConfiguration>
</ItemGroup>
<PropertyGroup Label="Globals">
<ProjectGuid>{B7D61F1C-B413-4768-8BDB-31FD464AD053}</ProjectGuid>
</PropertyGroup>
</Project>
TestProject64.vcxproj.filters
<?xml version="1.0" encoding="utf-8"?>
<Project ToolsVersion="4.0" xmlns="http://schemas.microsoft.com/developer/msbuild/2003">
<Import Project="TestProject.vcxproj.filters" />
</Project>
TestProject.vcxproj has two configurations defined inside: Release|x86 and Release|x64. As you can see, TestProject64.vcxproj has only the Release|x64 configuration. Defining of at least one configuration in TestProject64.vcxproj is necessary, otherwise Visual Studio will not be able to add TestProject64.vcxproj to a solution.
Now it's possible to include both TestProject.vcxproj and TestProject64.vcxproj to the same solution and build Release|x86 and Release|x64 at the same time.
I think the best way of doing this is to invoke MSBuild from the command line. It shouldn't need editing of MSBuild files. Just run
msbuild myproj.sln /p:Configuration="Debug|Win32"
msbuild myproj.sln /p:Configuration="Debug|x64"
I assume that if a developer is using Visual Studio then they'll only be generating the DLL files so they can debug with them, and that you have a separate build process if you're actually deploying the DLL files.
For C++, and if it's a project whose files/settings don't change often, one way to do it is create two projects within the solution, with both projects referring to the same source files. Then, in x64 builds, set one project to build 64-bit and the other 32-bit. (In x86 builds, set one as 32-bit and turn off the other.)
We've been using this for a while and it works fine.
Of course, you have to be careful that any changes you make to one are also made to its copy. i.e. if you add/remove a file or change its build setting, you have to do it in two places. Source-code changes still only need to be done once, because there's still only one copy of each source file.
And, of course, you may decide that doing this is more complex/risky than switching away from using the IDE. In our case it's worked really well, though.
You are not going to be able to do this with the UI of Visual Studio. For this you will need to hack the MSBuild files.
Try this link from MSDN for MSBuild Overview
I would suggest to create a dummy C++ Makefile project and then invoke MSBuild twice from it:
msbuild myproj.sln /p:Configuration="Debug|Win32"
msbuild myproj.sln /p:Configuration="Debug|x64"
Perhaps I've missed the point of this discussion.
Using Visual Studio, go to menu Build → Configuration Manager. In the Active Solution Platform drop down, select "New...", and a New Solution Platform dialog appears. Select x64 and accept the default Copy From. Close the dialog and the Configuration Manager.
Now open menu Build → Batch Build. Check those configurations you want to build and build them. You will find the x64 build executables separate from the Win32 executable files.
You can verify that these are what was intended by right clicking on the executable files, selecting Properties, and select the Compatibility tab. In the dropdown window you can check to see what operating systems the executable file can be run in.
Obviously, there may be some other tweaking you might have to do to get all the output files in their proper places, but this method seem somewhat simpler than fooling with build than those described above.
I ran into this problem with a project running in Visual Studio 2008 (on Windows XP) (32-bit) and also Visual Studio 2010 (on Windows 7) (64-bit).
The solution I used was to use the $(PROGRAMFILES) variable. It resolved correctly on both machines.

Resources