I just installed Windows 10 Creators Update (version 10.0.15063).
I have multiple versions of Visual Studio installed (2012, 2013, 2015 and 2017). I installed VS 2017 only a couple weeks ago.
Problem
CMake (version 3.8.1) no longer finds the C/C++ compiler when run inside a "VS2015 x64 Native Command Prompt" (it does work properly when run inside a VS 2017 command prompt).
Reproduction
Content of CMakeLists.txt:
project (test)
add_executable (test test.cpp)
(Content of test.cpp is irrelevant.)
CMake invocation, in a VS2015 x64 Native Command Prompt:
> mkdir build
> cd build
> cmake -G "Visual Studio 14 2015 Win64" ..
CMake output:
-- The C compiler identification is unknown
-- The CXX compiler identification is unknown
CMake Error at CMakeLists.txt:1 (project):
No CMAKE_C_COMPILER could be found.
CMake Error at CMakeLists.txt:1 (project):
No CMAKE_CXX_COMPILER could be found.
-- Configuring incomplete, errors occurred!
See also "D:/dev/cmaketest/build/CMakeFiles/CMakeOutput.log".
See also "D:/dev/cmaketest/build/CMakeFiles/CMakeError.log".
Analysis
The reason of the failure is clear when looking at CMakeFiles/CMakeError.log:
ClCompile:
C:\Program Files (x86)\Microsoft Visual Studio 14.0\VC\bin\x86_amd64\CL.exe /c /nologo /W0 /WX- /Od /D _MBCS /Gm- /EHsc /RTC1 /MDd /GS /fp:precise /Zc:wchar_t /Zc:forScope /Zc:inline /Fo"Debug\\" /Fd"Debug\vc140.pdb" /Gd /TC /errorReport:queue CMakeCCompilerId.c
CMakeCCompilerId.c
Link:
C:\Program Files (x86)\Microsoft Visual Studio 14.0\VC\bin\x86_amd64\link.exe /ERRORREPORT:QUEUE /OUT:".\CompilerIdC.exe" /INCREMENTAL:NO /NOLOGO kernel32.lib user32.lib gdi32.lib winspool.lib comdlg32.lib advapi32.lib shell32.lib ole32.lib oleaut32.lib uuid.lib odbc32.lib odbccp32.lib /MANIFEST /MANIFESTUAC:"level='asInvoker' uiAccess='false'" /manifest:embed /PDB:".\CompilerIdC.pdb" /SUBSYSTEM:CONSOLE /TLBID:1 /DYNAMICBASE /NXCOMPAT /IMPLIB:".\CompilerIdC.lib" /MACHINE:X64 Debug\CMakeCCompilerId.obj
LINK : fatal error LNK1158: cannot run 'rc.exe' [D:\dev\cmaketest\build\CMakeFiles\3.8.1\CompilerIdC\CompilerIdC.vcxproj]
rc.exe (Resource Compiler) is not found. Indeed, in the same VS 2015 command prompt:
> where rc.exe
INFO: Could not find files for the given pattern(s).
While it is found in a VS 2013 command prompt:
> where rc.exe
C:\Program Files (x86)\Windows Kits\8.1\bin\x64\rc.exe
C:\Program Files (x86)\Windows Kits\8.1\bin\x86\rc.exe
and a VS 2017 command prompt:
> where rc.exe
C:\Program Files (x86)\Windows Kits\10\bin\10.0.15063.0\x64\rc.exe
Checking the content of the PATH environment variables in various VS command prompts:
Inside a VS 2013 command prompt, PATH contains
C:\Program Files (x86)\Windows Kits\8.1\bin\x64
Inside a VS 2017 command prompt, PATH contains
C:\Program Files (x86)\Windows Kits\10\bin\x64
C:\Program Files (x86)\Windows Kits\10\bin\10.0.15063.0\x64
But inside a VS 2015 command prompt, PATH only contains
C:\Program Files (x86)\Windows Kits\10\bin\x64
which does not contain rc.exe.
Questions
Is this a known issue or is it specific to my system?
What could Windows 10 Creators Update possibly install, uninstall or alter in the system (perhaps something related to Windows SDKs) that would trigger this problem?
What is a clean way to resolve this?
Edit: Installed VS 2017 components:
Spent some time looking at this on three machines with Win10 Creators Edition and VS2010, VS2013, VS2015 and VS2017 installed, where it works on two machines and fails on the third. All had VS2015 Update 3 and all should have been installed with the same options.
Running the following batch file
C:\Program Files (x86)\Microsoft Visual Studio 14.0\VC\bin\amd64\vcvars64.bat
should setup the correct environment for VS2015 x64 environment. This should add
C:\Program Files (x86)\Windows Kits\10\bin\x64
to the PATH. This is where rc.exe should be. However on my failing machine rc.exe was missing from here, but it did exist in
C:\Program Files (x86)\Windows Kits\10\bin\10.0.15063.0\x64
I went back and feeling like this was a setup issue I re-ran the VS2015 Update 3 setup and told it to add
Windows and Web Development -> Universal Windows App Development Tools -> Tools (1.4.1) and Windows 10 SDK (10.0.14393)
this caused rc.exe and related files to appear in
C:\Program Files (x86)\Windows Kits\10\bin\x64
Running rc -v on
C:\Program Files (x86)\Windows Kits\10\bin\10.0.15063.0\x64\rc.exe
and
C:\Program Files (x86)\Windows Kits\10\bin\x64\rc.exe
gave the same version number 10.0.10011.16384
Not sure why rc.exe was missing from the original install, but re-running the install and adding the other SDK fixed it for me. It looks like
C:\Program Files (x86)\Windows Kits\10\bin\x64\rc.exe
should be the default rc.exe but it was not setup by a previous install.
It's definitely not just you. I installed VS2017 yesterday and doing so seems to have produced the same problem on my end. I don't have a good solution (this should be reported to Microsoft as a bug) but I do have a hacky workaround.
I was able to copy rc.exe and rc.dll from
C:\Program Files (x86)\Windows Kits\10\bin\10.0.15063.0\x64
to
C:\Program Files (x86)\Windows Kits\10\bin\x86
That resolved the issue for me. My hunch is that it's a registry key being overwritten but I haven't dug into it enough to be sure.
Met the same problem with Windows 10 15063.608 (Windows SDK 10.0.15063.0). The solution working for me is the hard links creation for Windows 10 kit binaries x64 and x86 folders like shown below (use the command prompt with admin rights):
mklink /J "C:\Program Files (x86)\Windows Kits\10\bin\x86" "C:\Program Files (x86)\Windows Kits\10\bin\10.0.15063.0\x86"
mklink /J "C:\Program Files (x86)\Windows Kits\10\bin\x64" "C:\Program Files (x86)\Windows Kits\10\bin\10.0.15063.0\x64"
(prior to running these commands just rename existing Windows Kits\10\bin\x64 and Windows Kits\10\bin\x86 folders - it looks like they are not in use.
P.S. mklink is a CMD command, not available under PowerShell
For whatever reason the built-in Tools (1.4.1) and Windows 10 SDK (10.0.14393) installer didn't work for me:
C:\Program Files (x86)\Windows Kits\10\bin\x86 got populated mid-install (success!)
...then de-populated (sorrow!)
And eventually the installer returned error -2147023293/0x80048646.
The "Windows 10 SDK (ver. 10.0.14393.795)" installer from the Windows SDK and emulator archive worked though: C:\Program Files (x86)\Windows Kits\10\bin\x86 gets and stays populated, including rc.exe.
Windows 7 x64, Visual Studio Professional 2015 Update 3.
Specifying CMAKE_SYSTEM_VERSION=8.1 solved the problem for me.
Similar problem with VS2017 Community 15.4.5 with Windows Sdk version 10.0.16299.0, but only for builds via TeamCity; builds from within VS work fine and so does building with MSBuild when starting from a VS developer command prompt. So this does not exactly answer the OP's question, but is so similar and this is one of the first search matches so I'll add it here.
Found a solution which does not require modifying the installation in any way (no linking/copying so less error-prone and easy to automate):
set the VisualStudioVersion environment variable to 15.0.
You could do this globally using the standard Windows gui for that (example for windows 10 here) but I'd rather strongly advise against it becaus it could interfere with other versions of VS, moreover it is not a change which is easily automated nor checked in into your build code and hence harder to reproduce omn different machines. A better alternative is to set this in the commandline where the build runs (cmd: set VisualStudioVersion=15.0 PS: $env:VisualStudioVersion = '15.0' in TeamCity: add env.VisualStudioVersion Parameter). Another alternative is to pass this directory to MSBuild as a property (pass /p:VisualStudioVersion=15.0 or in teamCity add system.VisualStudioVersion).
run your online installer vs_community2017.exe.
select modify your VS2017
select desktop development with C++
select Windows 10 SDK(my version is 10.0.10586) and install it
Run VS2015 command prompt:
> where rc
> C:\Program Files (x86)\Windows Kits\10\bin\x64\rc.exe
> C:\Program Files (x86)\Windows Kits\10\bin\x86\rc.exe
It seems that vs2017 default installs the newest SDK, and Overwrite old versions.
For anyone who gets stuck on this, one particular problem set is:
get a new windows 10 PC
install VS 2017 [*]
uninstall VS 2017 and
install VS 2015
If you do the above,
it seems that there is a bug or other behavior with the overall suite of Windows/VS installers.
There are basically it seems four problems MSFT have to fix (a) sometimes it just doesn't install rc.exe, (b) it doesn't install rc.exe if you "only" ask for the c++ stuff, you must ask for everything (c) the uninstall-install pipeline seems to be all messed up in various ways (d) even if it randomly installs rc.exe for you, it forgets or fouls-up the path.
:/
Long tedious story short, solutions seem to include one or more of
basically install or re-install 10.0.10011.16384 (but only that one, NOT the two later ones)
look around and see if rc.exe is plain, outright, not there. If so, install it (somewhere, anywhere)
in VS, you'd think you can install "just" the c++ stuff, but no. In practice you MUST check yes to all the web, blah blah development stuff. This seems to give you "more hope" of getting rc.exe. After doing this, revisit point 2, as you may well still not have it.
After doing 2 then 3 and likely 2 again, you likely STILL will not have it in your actual path. I would love to know which is the "best, natural" place to have it in your path, but that seems to be a lost cause. Just shove it in your path somewhere, anywhere.
Create a simple cmake file somewhere - and test it works.
. . . . . .
[*] it may well come with VS 2017, and don't forget VS 2017 may annoyingly get installed with something else, Unity etc.
Open "C:\Program Files (x86)\Microsoft Visual Studio 14.0\Common7\Tools\VsDevCmd.bat" in a text editor in administrator mode and change
the line
#if not "%WindowsSdkDir%" == "" #set PATH=%WindowsSdkDir%bin\x86;%PATH%
to
#if not "%WindowsSdkDir%" == "" #set PATH=%WindowsSdkDir%bin\x86;%WindowsSdkDir%bin\%WindowsSDKVersion%x86;%PATH%
I had the exact same problem. Multiple Visual studio versions, including 2015 and 2017.
My solution was to run the cmake command from 2017 developer command prompt, and specify the 2015 visual studio version with:
cmake -G "Visual Studio 14 2015" ..
Seems like when you install a newer version of Visual Studio the more recent SDK will be chosen by default.
You must select the SDK (8.1) that is installed with VS2015:
%comspec% /k "C:\Program Files (x86)\Microsoft Visual Studio 14.0\VC\vcvarsall.bat" <arch> 8.1
I found the right answer here
execute following command on native 64/86 visual studio command prompt to set correct version For vs2015 --
%comspec% /k "C:\Program Files (x86)\Microsoft Visual Studio 14.0\VC\vcvarsall.bat" amd64 8.1
%comspec% /k "C:\Program Files (x86)\Microsoft Visual Studio 14.0\VC\vcvarsall.bat" x86 8.1
execute following command on native 64/86 visual studio command promptto set correct version For vs2013 -
%comspec% /k "C:\Program Files (x86)\Microsoft Visual Studio 12.0\VC\vcvarsall.bat" amd64 7.1
%comspec% /k "C:\Program Files (x86)\Microsoft Visual Studio 12.0\VC\vcvarsall.bat" x86 7.1
This will set correct path and execute without any issue.
I have tested this on WIN10 with VS2013,VS2015,VS2017 installed.
After trying to install > py -3.11 -m pip zodb I got that pesky LNK1158 error.
I have VC files at:
Host Target Resource Compiler Version 10.0.10011.16384
x64 x64 "C:\Program Files (x86)\Windows Kits\10\bin\10.0.19041.0\x64\rc.exe"
x64 x64 "C:\Program Files (x86)\Windows Kits\10\bin\10.0.19041.0\x64\rcdll.dll"
x64 x86 "C:\Program Files (x86)\Windows Kits\10\bin\10.0.19041.0\x86\rc.exe"
x64 x86 "C:\Program Files (x86)\Windows Kits\10\bin\10.0.19041.0\x86\rcdll.dll"
Host Target Linker Version 14.00.24245.0
x64 x64 "C:\Program Files (x86)\Microsoft Visual Studio 14.0\VC\bin\amd64\link.exe"
x86 x86 "C:\Program Files (x86)\Microsoft Visual Studio 14.0\VC\bin\link.exe"
x64 x86 "C:\Program Files (x86)\Microsoft Visual Studio 14.0\VC\bin\amd64_x86\link.exe"
x86 x64 "C:\Program Files (x86)\Microsoft Visual Studio 14.0\VC\BIN\x86_amd64\link.exe"
LINK need RC for cPersist from persistent-4.9.1.tar.gz
Setup.py run x86_amd64 tools for target Python 3.11.0rc2 64-bit
=> need to copy x64-x64 rc.exe and rcdll.dll to x86_amd64 directory
Because I'm lazy - fast XCOPY was enough and then new try:
PS > py -3.11 -m pip install zodb
... later ...
PS > # NO ERRORS - I AM HAPPY GUY NOW!
I had the same problem as here fatal error C1034: windows.h: no include path set
I typed vcvars32.bat and that solved my problem but I want to link some 64-bit .lib files and when I do:
cl main.cpp xxxlib.lib
I get:
warning LNK4272: library machine type 'x64' conflict with target machine type 'x86'
Is it because I use the vcvars32.bat is 32 bits? Where can I find the 64 bit version?
Thanks
In order to make sure you have the proper environment variables set, the simplest way is to launch the respective command shell in the start menu.
For 64bit, this would be Visual Studio x64 Win64 Command Prompt (2010), then cl.exe is automatically correct. If you show the properties of this entry in the start menu, you'll also find more infos:
Start in: "C:\Program Files (x86)\Microsoft Visual Studio 10.0\VC\"
Target : %comspec% /k ""C:\Program Files (x86)\Microsoft Visual Studio 10.0\VC\vcvarsall.bat"" amd64
From this, you see that the working directory is set, and vcvarsall.bat is called with the amd64 parameter. This is probably what you missed.
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.
I have a Qt project I'm trying to automate. On Windows I build for both 32-bit and 64-bit platforms. I am using Visual Studio 2013. I have the following Qt Kits installed: Desktop Qt 5.5.1 MSVC2013 32bit, and Desktop Qt 5.5.1 MSVC2013 64bit. All four versions (32-bit debug and release, and 64-bit debug and release) can be built and run without any trouble from the IDE. Unfortunately, building from the command line fails with this error:
fatal error LNK1112: module machine type 'X86' conflicts with target machine type 'x64'
My command-line system, intended for eventual use in a batch file, and run in my project directory, is:
pushd Program Files (x86)\Microsoft Visual Studio 12.0\VC\bin
call vcvars32.bat
popd
md build64
cd build64
G:\Qt\5.5\msvc2013_64\bin\qmake.exe -spec win32-msvc2013 -o Makefile ..\Maps.pro
G:\Qt\Tools\QtCreator\bin\jom.exe -f Makefile.Release
I use this command in a command window (after setting up the path using vcvars32 so that the Visual Studio tools like nmake, rc and link can be found) and get the error. Note that the command-line method works perfectly for my 32-bit build.
The qmake command line I use is copied from the one recorded in a comment in the Makefile created by the IDE, which claims it is the command used to create that makefile. I know that the "-spec win32-msvc2013" option looks strange, but it works when the IDE uses it.
The jom command line I use is the one used by the IDE, as logged by the Compile Output window.
The only thing I can think of is that Qt sets up some 'magic' environmental variables which I don't know about.
[Yes, I have googled very extensively and looked at other questions and answers here, and can't find anything that fits this case.]
This code
pushd Program Files (x86)\Microsoft Visual Studio 12.0\VC\bin
vcvars32.bat
popd
sets up environment for building for 32-bit architecture. Run vcvars32.bat from different directory (I think it should have amd64 in its name, don't have Windows computer at the moment so can't say the exact directory name, but you'll figure out).
Or do
pushd "<DRIVE>:\Program Files (x86)\Microsoft Visual Studio <Version>\Common7\Tools"
vsvars32 x64
popd
Update for VS2017:
For 64-bit architecture use this command:
"<DRIVE>:\Program Files (x86)\Microsoft Visual Studio\2017\<Version>\VC\Auxiliary\Build\vcvars64.bat"
and for 32 bits:
"<DRIVE>:\Program Files (x86)\Microsoft Visual Studio\2017\<Version>\VC\Auxiliary\Build\vcvars32.bat"
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