I am a newbie to DirectX SDK, Platfrom SDK and DirectShow. I downloaded latest Platform SDK and DirectX SDK August'09. I tried to build sample project in folder:
Microsoft Platform SDK\Samples\Multimedia\DirectShow\Capture\PlayCap\
And had following building errors:
LINK : fatal error LNK1181: cannot open input file 'D:\Program Files\
Microsoft Platform SDK\samples\multimedia\directshow\baseclasses\
WIN2000_DEBUG\strmbasd.lib'
As far, as I understand, I need to build all sources in "Microsoft Platform SDK\Samples\Multimedia\DirectShow\BaseClasses\" directory to get necessary lib.
I tried nmake in that dir and got following:
D:\Program Files\Microsoft Platform SDK\Samples\Multimedia\DirectShow\
BaseClasses\ctlutil.h(278) : error C4430: missing type specifier - int
assumed. Note: C++ does not support default-int.
Here is code on that lines:
278: STDMETHODIMP
279: CMediaEvent::NonDelegatingQueryInterface(REFIID riid, void **ppv)
What I do wrong? Just can't believe, that using Microsoft's libraries must be so hard.
Microsoft has renamed Platfrom SDK to Windows SDK. The lastest Windows SDK is Microsoft Windows SDK for Windows 7 and .NET Framework 3.5 SP1.
Windows SDK for Windows 7 has Visual Studio 2008 2005 project files for all DirectShow projects.
On my Xp64 box, I managed to get the DirectShow baseclasses libs built in order to run the amcap sample. I have the June 2010 Microsoft DirectX SDK installed as well as the Microsoft Windows SDK for Windows 7 (7.1) with all the C/C++ compilers.
First, we have to compile the DirectShow baseclasses :
open a regular old cmd.exe
cd C:\Program Files\Microsoft SDKs\Windows\v7.1\Samples\multimedia\directshow\baseclasses
If you're getting an error about not have VCBuild.exe installed, it's because the
sln and various project files (eg: C/C++ vcproj) are ancient, the next command will
upgrade them nicely, changing old stanky vcproj files into new crappy vcxproj files
VCUpgrade is here on my machine :
C:\Program Files (x86)\Microsoft Visual Studio 10.0\Common7\Tools\vcupgrade.exe
Note that even after trying the various combinations of params to vcupgrade,
building the sln with msbuild is a no-go (docs be danged), so I had to directly
compile the project I left the batch file var named SLN anyway because I'm a real revolutionary
VCUpgrade -nologo -overwrite baseclasses.vcproj
This makes it a touch easier to compile different configurations
set SLN="baseclasses.vcxproj"
Note that the baseclasses Release build makes strmbase.lib
and Debug makes strmbasd.lib
amcap needs the Release build tho amcap's build can be debug
A) Compile Release Win32 (== x86)
Using the MsSdk's SetEnv.Cmd lets you avoid all that vsvars32.bat quagmire as well
as the 8 million different cmd shells that have been specially designed to be one
or two fatal flaws away from actually working while relying upon an eplipsy-inducing web of
batch files to do they thing (hey! maybe the two are related!?)
"C:\Program Files\Microsoft SDKs\Windows\v7.1\Bin\SetEnv.Cmd" /release /x86 /xp
I've not had any luck using the 64-bit version of MSBuild (maybe targets?),
but x86 MSBuild has been working no problem
"C:\WINDOWS\Microsoft.NET\Framework\v4.0.30319\MSBuild.exe" %SLN% /p:Configuration=Release /p:Platform=Win32
B) Compile Release X64
"C:\Program Files\Microsoft SDKs\Windows\v7.1\Bin\SetEnv.Cmd" /release /x64 /2003
"C:\WINDOWS\Microsoft.NET\Framework\v4.0.30319\MSBuild.exe" %SLN% /p:Configuration=Release /p:Platform=X64
Second, we can now compile both versions of amcap
open a regular old cmd.exe
cd C:\Program Files\Microsoft SDKs\Windows\v7.1\Samples\multimedia\directshow\capture\amcap
VCUpgrade the vcproj to a vcxproj
VCUpgrade -nologo -overwrite amcap.vcproj
set SLN="amcap.vcxproj"
A) Compile Debug Win32 (== x86)
Set compiler,lib,include,... paths and then compile
"C:\Program Files\Microsoft SDKs\Windows\v7.1\Bin\SetEnv.Cmd" /debug /x86 /xp
"C:\WINDOWS\Microsoft.NET\Framework\v4.0.30319\MSBuild.exe" %SLN% /p:Configuration=Debug /p:Platform=Win32
B) Compile Debug X64
"C:\Program Files\Microsoft SDKs\Windows\v7.1\Bin\SetEnv.Cmd" /debug /x64 /2003
"C:\WINDOWS\Microsoft.NET\Framework\v4.0.30319\MSBuild.exe" %SLN% /p:Configuration=Debug /p:Platform=X64
I used SysInternals *Process Explorer* to verify that each exe was actually 32-bit and 64-bit respectively. It seems inexplicable that most developers I've worked with don't even know about Process Explorer -- I'm in that thing all day. And yes, that is what she said.
For me this error meant "open C:\Program Files\Microsoft SDKs\Windows\v7.1\Samples\multimedia\directshow\baseclasses\baseclasses.sln" (in my case, in visual studio express 2010) it asks to convert it, do so, then build both "release" and "debug."
Then in your own project, under project settings for your project
example: add
G:\Program Files\Microsoft SDKs\Windows\v7.1\Samples\multimedia\directshow\baseclasses
to beginning of “VC++ directories” include path, and G:\Program Files\Microsoft SDKs\Windows\v7.1\Samples\multimedia\directshow\baseclasses\debug to your lib path (anywhere in that).
See also https://msdn.microsoft.com/en-us/library/windows/desktop/dd407279(v=vs.85).aspx
Related
I would like to compile a C++ program via Visual Studio command line tools. I would like to target the executable for 32 bit Windows XP. Tried compiling it the usual way, using x86 Native Tools Command Prompt for VS 2019, but it doesn't work on Windows XP, though runs fine on my Windows 10 machine.
Steps I take:
Open x86 Native Tools Command Prompt for VS 2019.
cd to the project directory. There I'll have 2 folders sources and headers, which shall contain .cpp and .h files respectively.
Execute command cl sources\*.cpp /EHsc /D_WIN32_WINNT=0x050103 /I headers /I <path to boost> /link /libpath <path to boost>\boost_1_77_0\bin\x86\lib\libboost_program_options-vc142-mt-s-x32-1_77.lib /out:exec_xp.exe (the project uses the boost library).
Tried this, but it doesn't work. /D \"_USING_V110_SDK71_\" seems to do nothing, and the /SUBSYSTEM:WINDOWS,5.01 piece isn't recognized by the compiler.
I have learnt from this Microsoft page that we should install deprecated Toolset to compile for WinXP. I went ahead to Visual Studio Installer and installed the C++ Windows XP Support for VS 2017 (v141) tools [Deprecated], as said in the tutorial.
But what now? How can I use this Toolset? I can't find it anywhere on my computer, let alone use it! Visual Studio Installer says it's located under C:\Program Files (x86)\Microsoft Visual Studio\2019\BuildTools, but it's too vague.
UPD:
Tried with msbuild /p:PlatformToolset=v141_xp, getting this error:
C:\Program Files (x86)\Microsoft Visual Studio\2019\Community\MSBuild\Microsoft\VC\v160\Microsoft.CppBuild.targets(439,
5): error MSB8020: The build tools for v141_xp (Platform Toolset = 'v141_xp') cannot be found. To build using the v141_
xp build tools, please install v141_xp build tools. Alternatively, you may upgrade to the current Visual Studio tools
by selecting the Project menu or right-click the solution, and then selecting "Retarget solution"
Which suggests, the compiler doesn't see the v141_xp toolset. I wonder why? It's installed for sure, I did it via the Visual Studio Installer.
I suggest you could try to set the PlatformToolset property:
msbuild myProject.vcxproj /p:PlatformToolset=…
For more details, I suggest you could refer to the Doc:MSBuild command-line reference
I installed Visual Studio 2017 15.4.0, then i installed VS2015 Update 3 (
C++ Language only).
I started VS2015 and tried to create a C++ Project (e.g. Console Application) but nothing happens, the dialog just does not close or continue. Only "Cancel" is possible. More important for me, i tried to configure a project (caffe2) as a VS2015 project, but cmake failes to find the VS2015 tool set.
The problem (or a part of the problem) is, that VS2015 normally installs its toolset (cl.exe etc.) to
C:\Program Files (x86)\Microsoft Visual Studio 14.0\VC\bin
But because of VS2017, it uses now:
C:\Program Files (x86)\Microsoft Visual Studio\Shared\14.0\VC\bin
(see also Visual Studio 2015 Installer doesn't install cl.exe)
CMake (3.9.4) does not find the rc.exe or cl.exe of VS2015 anymore
I tried uninstalling both studios and reinstall them starting with VS2015, but VS2015 is still using the shared folder and not its own. (Even worth, i now got a mix of both folders, some minor important files are now duplicated). As a workaround, i started cmd.exe in "C:\Program Files (x86)\Microsoft Visual Studio 14.0\VC",renamed bin,lib,include,redist to bin#,lib#,... and used hardlinks like this
mklink /j bin "C:\Program Files (x86)\Microsoft Visual Studio\Shared\14.0\VC\bin"
mklink /j lib "C:\Program Files (x86)\Microsoft Visual Studio\Shared\14.0\VC\lib"
mklink /j redist "C:\Program Files (x86)\Microsoft Visual Studio\Shared\14.0\VC\redist"
mklink /j include "C:\Program Files (x86)\Microsoft Visual Studio\Shared\14.0\VC\include"
At least, cmake is now working again, but i still cannot create any projects with VS2015 anymore ( i do not need this VS2015 functionality really, but it makes a bad feeling having a broken installation)
Is anyone else having this trouble and got a better solution than the workaround above ?
What I want to be done: Create a 64bit DLL on win7 that interacts with the Windows API including the OLE32.dll.
What I have got:
I am currently stuck. I download Visual Studio 2015 Community Edition. I tried to create a DLL there and on creation it generated everything but no dll. The program did not complain, everything was setup as in the tutorial but no dll file.
So I skipped this and downloaded Eclipse CDT. I set up using the Visual C toolchain and after minor issues I had my DLL generated. So I used Java to fire it up but it complained (I use JNA for integration) and it seams that I have a 32bit DLL.
So I searched the web and read and did stuff but I am totally lost. Since the Visual Studio 2010 Express edition came without a 64bit compiler I am not even sure if the Community edition of Visual Studio supports 64bit dlls this time.
I also have the Windows SDK v7.1 installed. I link to a library file ole32.dll. It contains the method CoCreateInstance which I require. I have to add this manually in order for the compiler to pick it up. If I switch to the 64bit dll version the compiler complains about the CoCreateInstance method can not be linked.
So basically I am lost here. A source on the web gave a work around for the 2010 Express being not able to create x64 DLL and it turned out that the hint was getting windows SDK since it it comes along with a compiler.
Also I noticed that CDT uses Visual Studio 10 files so I guess it is using this compiler.
I set to both compiler and linker the /machine:64 option. But the linker still complains that the obj file from the compiler is 32bit.
Any Ideas?
[Update]
The Compiler prints the following line so basically it is not able to compile 64bit version. Any idea how to replace it? As said it uses the Visual Studio 10 folder but I also have a Visual Studio 12 and 14 folder as well.
cl : Command line warning D9002 : ignoring unknown option '/machine:x64'
Well, I don't think '/machine:x64' is a cl option but it's one of linker option.
If you want to make some dll maybe with windows sdk or visual studio environment.
I am not sure that my solution is fit for yours or not, this is what i did for my 64-bit project to compile with eclipse and windows sdk 7.1.
I have two eclipse IDEs which are 32bit and 64bit neon version.
I choose a 64-bit one. You can check one of my answer about installation here. In my opinion, any version of them will be fine. It is your choice.
First step. run 'Windows SDK 7.1 Command Prompt from the start menu.
then, start my eclipse on the command window after changing 64-bit development level with command as follows.
Second Step. Setting up path variables to my project.
I have my own project with a properties window.
The important variable seems to be both LIB and PATH variable in my point.
I crosschecked this two variable, one was from the windows SDK's prompt window and another was current setting variables after installation.
SDK variables here
My final variables are
LIB:
C:\Windows\Microsoft.NET\Framework64\v4.0.30319;
C:\Windows\Microsoft.NET\Framework\v4.0.30319;
C:\Windows\Microsoft.NET\Framework64\v3.5;
C:\Windows\Microsoft.NET\Framework\v3.5;;
C:\Program Files (x86)\Microsoft Visual Studio 10.0\VC\Lib\amd64;
C:\Program Files\Microsoft SDKs\Windows\v7.1\Lib\X64
PATH:
C:\Windows\Microsoft.NET\Framework64\v4.0.30319;
C:\Windows\Microsoft.NET\Framework\v4.0.30319;
C:\Windows\Microsoft.NET\Framework64\v3.5;
C:\Windows\Microsoft.NET\Framework\v3.5;;
C:\Program Files (x86)\Microsoft Visual Studio 10.0\Common7\IDE;
C:\Program Files (x86)\Microsoft Visual Studio 10.0\Common7\Tools;;
C:\Program Files (x86)\Microsoft Visual Studio 10.0\VC\Bin\amd64;
C:\Program Files (x86)\Microsoft Visual Studio 10.0\VC\Bin\VCPackages;;
C:\Program Files\Microsoft SDKs\Windows\v7.1\Bin\NETFX 4.0 Tools\x64;
C:\Program Files\Microsoft SDKs\Windows\v7.1\Bin\x64;
C:\Program Files\Microsoft SDKs\Windows\v7.1\Bin;;
C:\Windows\system32;C:\Windows;
C:\Windows\System32\Wbem;
C:\Windows\System32\WindowsPowerShell\v1.0\;
Third, I modified my linker flag as you see the picture below.
Finally, I compiled my project successfully.
Here is my build log.
Info: Internal Builder is used for build
cl /c /EHs /MD /Zi /nologo /Foutil.obj "..\util.c"
rc /Fo proc_view.res "..\proc_view.rc"
Microsoft (R) Windows (R) Resource Compiler Version 6.1.7600.16385
Copyright (C) Microsoft Corporation. All rights reserved.
cl /c /EHs /MD /Zi /nologo /Foprocss.obj "..\procss.c"
link /machine:x64 /debug /nologo /OUT:Systemer.exe FreeList.obj LinkedList.obj proc_main.obj proc_view.res procss.obj util.obj Kernel32.lib Psapi.lib User32.lib
The last one had done with checking if my executable file was 64-bit or 32-bit with a dumpbin command.
That is all.
I think the Eclipse with MinGW or cygwin might be a better option.
I hope this is right for you.
How can I get Visual Studio 2012 to use the native amd64 toolchain, rather than the default x86_amd64 cross-compiler?
I am building a large library that causes the linker to run out of memory when doing whole program optimization and link-time code generation.
I found two older posts (here and here) asking this same question, but no answers yet. Microsoft provides documentation on how to specify the toolchain on the command line, but not in the IDE.
There is another method of forcing use of the 64-bit linker on a per-project basis for Visual Studio 2013. Edit your .vcxproj file and insert the following after the <Import...Microsoft.Cpp.Defaults line:
<Import Project="$(VCTargetsPath)\Microsoft.Cpp.Default.props" />
<PropertyGroup>
<PreferredToolArchitecture>x64</PreferredToolArchitecture>
</PropertyGroup>
You need to set the environment variable "_IsNativeEnvironment" to "true" prior to starting Visual Studio 2012 IDE:
set _IsNativeEnvironment=true
start "C:\Program Files (x86)\Microsoft Visual Studio 11.0\Common7\IDE\devenv.exe" your_solution.sln
For Visual Studio 2013, the name of the environment variable is different:
set PreferredToolArchitecture=x64
sbm start "C:\Program Files (x86)\Microsoft Visual Studio 12.0\Common7\IDE\devenv.exe" your_solution.sln
Beware that this technique does not work if the version of the IDE does not match the version of the toolchain. That is, if you use VS2013 IDE configured to run VS2012 compiler, you are out of luck. But such combination is uncommon.
Here are some links for further information:
difference between VS12 and VS13
how to embed PreferredToolArchitecture into the project in VS13
If your goal is to use the native environment rather than specifically amd64_x86, you can set the UseNativeEnvironment property in your project file:
<PropertyGroup>
<UseNativeEnvironment>true</UseNativeEnvironment>
</PropertyGroup>
(I have successfully added it to the "Globals" PropertyGroup.)
You can check which toolchain is being used by adding the /Bv compiler option. Example output is below. Notice that the toolchain directory appears after bin\ (amd64_x86 in this case).
2>ClCompile:
2> Compiler Passes:
2> C:\Program Files (x86)\Microsoft Visual Studio 12.0\VC\bin\amd64_x86\CL.exe: Version 18.00.31101.0
2> C:\Program Files (x86)\Microsoft Visual Studio 12.0\VC\bin\amd64_x86\c1.dll: Version 18.00.31101.0
2> C:\Program Files (x86)\Microsoft Visual Studio 12.0\VC\bin\amd64_x86\c1xx.dll: Version 18.00.31101.0
2> C:\Program Files (x86)\Microsoft Visual Studio 12.0\VC\bin\amd64_x86\c2.dll: Version 18.00.31101.0
2> C:\Program Files (x86)\Microsoft Visual Studio 12.0\VC\bin\amd64_x86\link.exe: Version 12.00.31101.0
2> C:\Program Files (x86)\Microsoft Visual Studio 12.0\VC\bin\amd64\mspdb120.dll: Version 12.00.31101.0
2> C:\Program Files (x86)\Microsoft Visual Studio 12.0\VC\bin\amd64_x86\1033\clui.dll: Version 18.00.31101.0
I know this is a rather old post, but it's still relevant for VS 2017. Here you also have the "PreferredToolArchitecture" environment variable and a "build in" setting in the IDE is not readily available.
However you can integrate that easily on a project by project base so that you can always chose what tool architecture to use. Maybe this is helpful for some. Do this:
Go to Property Manager and create a new property sheet, e. g. named "x64 Toolchain.props" so you know what it does. With a separate property sheet you can then switch the tool architecture as appropriate by including or not including the sheet into a project.
Open the properties of that new sheet, navigate to "Common Properties\User Macros" and click "Add Macro".
In the dialog you set the name to "PreferredToolArchitecture", the value to "x64" and enable the checkbox "Set this macro as an environment variable in the build environment".
Optionally navigate to "Common Properties\C/C++\Command Line" and add "/Bv" under "Additional Options". This will make the compiler output the tools it uses including its path and version number, might be helpful for checking if really the desired architecture is being used. It will place entries in the log output window like so:
Compiler Passes:
C:\Program Files (x86)\Microsoft Visual Studio\2017\Enterprise\VC\Tools\MSVC\14.15.26726\bin\HostX86\x64\CL.exe: Version 19.15.26730.0
C:\Program Files (x86)\Microsoft Visual Studio\2017\Enterprise\VC\Tools\MSVC\14.15.26726\bin\HostX86\x64\c1.dll: Version 19.15.26730.0
C:\Program Files (x86)\Microsoft Visual Studio\2017\Enterprise\VC\Tools\MSVC\14.15.26726\bin\HostX86\x64\c1xx.dll: Version 19.15.26730.0
C:\Program Files (x86)\Microsoft Visual Studio\2017\Enterprise\VC\Tools\MSVC\14.15.26726\bin\HostX86\x64\c2.dll: Version 19.15.26730.0
C:\Program Files (x86)\Microsoft Visual Studio\2017\Enterprise\VC\Tools\MSVC\14.15.26726\bin\HostX86\x64\link.exe: Version 14.15.26730.0
C:\Program Files (x86)\Microsoft Visual Studio\2017\Enterprise\VC\Tools\MSVC\14.15.26726\bin\HostX86\x86\mspdb140.dll: Version 14.15.26730.0
C:\Program Files (x86)\Microsoft Visual Studio\2017\Enterprise\VC\Tools\MSVC\14.15.26726\bin\HostX86\x64\1033\clui.dll: Version 19.15.26730.0
Now for all projects that should be build with the x64 tool architecture include the new property sheet into the project in property manager. And for those that should not simply don't include it. That's it.
HTH
Edit:
It seems unfortunately this is not reliable! See below comments. I would really appreciate if MS would wire this setting to some GUI element and make it work consinstently...
I have a similar problem using Visual Studio 2010 on XP 64 SP2. If I set the VC++ executable directory to the amd64 bin (the native x64 folder) as the first in the search path, then I received the TRK0002 error … Invalid handle value.
But if I set _IsNativeEnvironment=true in a Visual Studio 2010 command prompt and start the ide from the command line as posted before, then the error goes away. Apparently, the 32-bit GUI IDE Environment is receiving info from a 64 bit process and is expecting info from a 32-bit process such as x86\cl.exe or x86_64\cl.exe.
In a scenario where you want to compile an IA64 bit executable, and you use the x86_ia64\cl.exe compiler. Since you are using a 32-bit cross compiler and have the _IsNativeEnvironment variable set to true, this must upset the IDE when posting messages in it's window consoles. Set the _IsNativeEnvironment=false, if you have previously set it to true.
The IDE should pick up that a native compiler was being used on a native 64-bit
machine and should have automatically set this variable to the appropriate value when the native compiler was selected from the IDE. A simple fix has never been applied to patch this problem. Solution. Do it yourself from the prompt, or buy the latest IDE from Microsoft to fix the problem.
So, the real wizards at Microsoft are the developers who work mainly from the command line. And the other developers, who wear the pointy hats and sit in the corner, must have been hired from Apple and were more concerned about appearance than function.
The whole purpose of an IDE is to make coding simple, not more complicated than using a text editor and a Makefile from the command line.
When I compile my C++ program in Visual Studio Express it says that it can't find atlbase.h. Am I missing some SDK or something?
Visual Studio 2017
When running the Visual Studio Installer, select the Individual components tab, and under SDKs, libraries, and frameworks make sure Visual C++ ATL Support is selected.
It is included with the Windows Driver Kit Version 7.1.0.
Microsoft ATL (Active Template Library), which includes the header atlbase.h is included with the Windows 2003 SDK, but it is not included with any newer Windows SDK release. It is also included with Professional editions of Visual Studio.
Solution for Visual Studio 2017 Express edition
I had the same error when building a COM C++ project in Visual Studio 2017 Express edition. As mentioned by several users here, ATL support is not included with the Express edition of Visual Studio. So to build a C++ COM/ATL project you need at least the Community edition.
If you really need to use the Express edition, you can download and install the Build Tools for Visual Studio 2017. Make sure to enable the 'Visual C++ ATL for x86 and x64' component during the setup.
After that add additional VC++ directories in the project properties:
Include directories: C:\Program Files (x86)\Microsoft Visual Studio\2017\BuildTools\VC\Tools\MSVC\14.14.26428\atlmfc\include
Library directories: C:\Program Files (x86)\Microsoft Visual Studio\2017\BuildTools\VC\Tools\MSVC\14.14.26428\atlmfc\lib\x86
The VC++ compiler should now be able to find the ATL source and library files.
For users of Visual Studio 2015, ensure Common Tools for C++ is installed (part of the VS installer).
Situation
With Visual Studio 2017 Community Edition, we installed "Visual C++ ATL support" and MFC and ATL support. The error still occurred in our x64 project.
Solution
We fixed some paths with the following two commands:
C:\Program Files (x86)\Microsoft Visual Studio 14.0\VC>mklink /d atlmfc "C:\Program Files (x86)\Microsoft Visual Studio\2017\Community\VC\Tools\MSVC\14.11.25503\atlmfc"
C:\Program Files (x86)\Microsoft Visual Studio\2017\Community\VC\Tools\MSVC\14.11.25503\atlmfc\lib>mklink /d amd64 "C:\Program Files (x86)\Microsoft Visual Studio\2017\Community\VC\Tools\MSVC\14.11.25503\atlmfc\lib\x64
Details
We eventually found the header atlbase.h in C:\Program Files (x86)\Microsoft Visual Studio\2017\Community\VC\Tools\MSVC\14.11.25503\atlmfc\include. This path simply was not added to the VC Include directory by vsvars32.bat, so the header was not found during build.
vsvars32.bat includes the following line:
#if exist "%VCINSTALLDIR%ATLMFC\INCLUDE" set INCLUDE=%VCINSTALLDIR%ATLMFC\INCLUDE;%INCLUDE%`.
This resolved to C:\Program Files (x86)\Microsoft Visual Studio 14.0\VC\atlmfc\include in our machine.
We created a directory junction, so the build tool finds atlbase.h in the expected directory (this is the first command from the Solution section above):
C:\Program Files (x86)\Microsoft Visual Studio 14.0\VC>mklink /d atlmfc "C:\Program Files (x86)\Microsoft Visual Studio\2017\Community\VC\Tools\MSVC\14.11.25503\atlmfc"
Afterwards, the linker did not find atls.lib (see Cannot Open File atls.lib). This was due to the expected file structure was that lib should directly contain the x86 version of the libs and lib\amd64 should contain the x64 variants. Instead, lib\x86 contained the x86 versions and lib\x64 contained the 64 bit versions. Since we build a 64 bit project, creating another directory junk from amd64 to x64 solved the problem:
C:\Program Files (x86)\Microsoft Visual Studio\2017\Community\VC\Tools\MSVC\14.11.25503\atlmfc\lib>mklink /d amd64 "C:\Program Files (x86)\Microsoft Visual Studio\2017\Community\VC\Tools\MSVC\14.11.25503\atlmfc\lib\x64
That header appears to be a part of the Windows Platform SDK.
You should search your computer for the file. That will tell you if you're missing it.
I had same problem with sample project. I specified the sample project's properties and the sample project compiled successfully.
Visual Studio 8
For header
C:\Program Files\Microsoft Visual Studio 8\VC\atlmfc\include
For .lib file
C:\Program Files\Microsoft Visual Studio 8\VC\atlmfc\lib
I have not yet seen anyone mention Visual Studio 2015 (MSBuild 14.0). In this case I've had to download Visual C++ BuildTools (found here: https://visualstudio.microsoft.com/vs/older-downloads/). After having installed this, running the installer again allowed me to modify the installation and include the ATL libs.
Hope this helps anyone that is still using MSBuild 14.0