This might be obvious for CMake regulars, but given the help, I would never have guessed this.
Generate x64:
cmake .. -G"Visual Studio 14 Win64"
Generate x86 is just leaving out the platform away:
cmake .. -G"Visual Studio 14"
In this case they are for Visual Studio 2015 (internally named 14).
The help:
The following generators are available on this platform:
Visual Studio 14 2015 [arch] = Generates Visual Studio 2015 project files.
Optional [arch] can be "Win64" or "ARM".
Visual Studio 12 2013 [arch] = Generates Visual Studio 2013 project files.
Optional [arch] can be "Win64" or "ARM".
Visual Studio 11 2012 [arch] = Generates Visual Studio 2012 project files.
Optional [arch] can be "Win64" or "ARM".
Visual Studio 10 2010 [arch] = Generates Visual Studio 2010 project files.
Optional [arch] can be "Win64" or "IA64".
Visual Studio 9 2008 [arch] = Generates Visual Studio 2008 project files.
Optional [arch] can be "Win64" or "IA64".
Visual Studio 8 2005 [arch] = Generates Visual Studio 2005 project files.
Optional [arch] can be "Win64".
Visual Studio 7 .NET 2003 = Deprecated. Generates Visual Studio .NET
2003 project files.
:: Run the most recent vsvars32.bat
:: test these environment variables that have 110 or 120 in them (future enhancements: support more Visual Studio versions):
:: Visual Studio .NET 2002: VS70COMNTOOLS=C:\Program Files (x86)\Microsoft Visual Studio .NET\Common7\Tools\
:: Visual Studio .NET 2003: VS71COMNTOOLS=C:\Program Files (x86)\Microsoft Visual Studio .NET 2003\Common7\Tools\
:: Visual Studio 2005: VS80COMNTOOLS=C:\Program Files (x86)\Microsoft Visual Studio 8\Common7\Tools\
:: Visual Studio 2008: VS90COMNTOOLS=C:\Program Files (x86)\Microsoft Visual Studio 9.0\Common7\Tools\
:: Visual Studio 2010: VS100COMNTOOLS=C:\Program Files (x86)\Microsoft Visual Studio 10.0\Common7\Tools\
:: Visual Studio 2012: VS110COMNTOOLS=C:\Program Files (x86)\Microsoft Visual Studio 11.0\Common7\Tools\
:: Visual Studio 2013: VS120COMNTOOLS=C:\Program Files (x86)\Microsoft Visual Studio 12.0\Common7\Tools\
:: VS130COMNTOOLS was skipped: http://www.neowin.net/forum/topic/1215607-visual-studio-13-to-be-skipped-vnext-to-be-v14/
:: Visual Studio 2015: VS130COMNTOOLS=C:\Program Files (x86)\Microsoft Visual Studio 14.0\Common7\Tools\
:: They contain `vsvars32.bat` which will update the `PATH` so it includes where `xsd.exe`, `csc.exe`, `editbin.exe` and others reside
:: Different examples: https://github.com/noop-dev/c-cgdk/blob/master/compile-vscpp.bat
:: and https://code.google.com/p/xvid4psp/source/browse/trunk/bin/4Gb+patcher.bat
:: or give it a go for any version: http://chess.eecs.berkeley.edu/ptexternal/src/ptII/ptolemy/actor/lib/fmi/fmus/template/sources/build_fmu.bat
setlocal enabledelayedexpansion
:: delayed expansion allows for the exclamation marks
:: see http://ss64.com/nt/delayedexpansion.html
:: see http://stackoverflow.com/questions/22857407/windows-batch-how-to-assign-variable-with-dynamic-name
for %%v in (70 71 80 90 100 110 120 130) do if not [!VS%%vCOMNTOOLS!]==[] set VSCOMNTOOLS=!VS%%vCOMNTOOLS!
:: http://stackoverflow.com/questions/28682268/assign-variables-past-endlocal-in-a-loop
endlocal & call :do call "%VSCOMNTOOLS%vsvars32.bat"
goto :eof
:do
echo %*
%*
goto :eof
It is next to the “Project Dependencies” in this image from Sara Ford:
Sara Ford: change “Project Build Order”
In the resulting dialog, you can change the build order within your solution.
This can be very useful when – for various reasons – you cannot have Project Level dependencies for an assembly, but have to have Assembly Reference dependencies for individual assemblies.
At a client I bumped into this, and this dialog was a life saver for us.
Ctrl + Shift + . to zoom in and Ctrl + Shift + , to zoom out.
They don’t keep an alternative for Zoom Out, and unlike most tools I know that allow for zooming, there is no keyboard accessible menu entry for Zoom Out in Visual Studio.
So you have to use your mouse to go in the lower left of your editor window in order to Zoom Out (thanks ashteele for putting that in an SO question):
But that is nowhere on the default path, nor in the registry.
What happens during installation of Visual Studio and/or the Microsoft SDK, is that the vsvars32.bat file of Visual Studio is updated so it can add the location of many tools (including xsd.exe) to the PATH.
So the trick is to find the youngest Visual Studio first, then run the according vsvars32.bat, and then xsd.exe is on the path.
This file contains hidden or bidirectional Unicode text that may be interpreted or compiled differently than what appears below. To review, open the file in an editor that reveals hidden Unicode characters. Learn more about bidirectional Unicode characters
Often I want to execute a TF.exe from the console, but don’t have the Visual Studio environment variables setup. Most of the times I want to run TF.exe from the most current Visual Studio installation, hence this TF.bat file figures out the location of it, then runs with the parameters passed to TF.bat: Read the rest of this entry »
The Wiert Corner - irregular stream of stuff 