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.
Sometimes msbuild will throw an error like this for an x86 project:
"C:\Users\Developer\Versioned\libssh2\build\libssh2.sln" (default target) (1) ->
(ValidateSolutionConfiguration target) ->
C:\Users\Developer\Versioned\libssh2\build\libssh2.sln.metaproj : error MSB4126: The specified solution configuration "Debug|X64" is invalid. Please specify a valid solution configuration using the Configuration and Platform properties
form="Any CPU") or leave those properties blank to use the default solution configuration. [C:\Users\Developer\Versioned\libssh2\build\libssh2.sln]
Cause:
vsvars64.bat will set the environment variable Platform=x64 but vsvars32.bat will not empty this environment variable.
Easiest is to run set Platform= then run vsvars32.bat.
If you are running this in the Visual Studio x64 command window it will set an environment variable Platform=x64 that will be used by msbuild. You can verify this by running echo in the command prompt you are using.
echo %platform%
So you will need to override the default when using x64 cmd, or run from the x86 cmd.
Sometime you might want to protect your data in memory – the greatest example is when dealing with anything related to passwords. It is simply not smart to keep that data around in a plain-text. In .NET there are multiple methods you can use for this purpose, starting with SecureString, ProtectedMemory, and my favorite ProtectedData.…
via: Found this via +Ilya S a post from +Josip Medved – Stuff like this should be way built into an OS, and RTL’s should have a secureMalloc()… – Joe C. Hecht – Google+
Since then I had to maintain too many locales running Windows 10. So here is the batch file:
for /f "delims=" %%A in ('PowerShell -Command "(Get-Culture).Name"') do explorer "%LocalAppData%\Packages\windows.immersivecontrolpanel_cw5n1h2txyewy\LocalState\Indexed\Settings\%%A\AAA_SystemSettings_MusUpdate_UpdateActionButton.settingcontent-ms"
… there’s no need to use WaitForMultipleObjects in Step 2. It’s fairly easy to keep a counter of active threads in the pool (interlocked-incremented when a thread starts, interlocked-decremented when a thread is finished). When the counter reaches zero (no more active threads), signal an event. With only one event to wait for, you can use WaitForSingleObject…
Brilliant Date format converter from dates in Text (almost any format) or timestamp numbers in Unix, Mac, Filetime or Microsoft (which is the same as Delphi TDateTime) format to any of these formats:
It’s Delphi, but I’ve not seen practical implementations in C# either.
(the updated version thanks to Anders Melander).
–jeroen
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
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
This is still one of my gripes from Visual Studio: when a changeset is linked to an incorrect work item, you still have to change this from the work item side:
You cannot change it from the changeset UI, but you can change it from most work item UI’s. You can just add a link to a the specific changeset and the changeset will show the link as well.
You have to be careful with the steps too:
Link it from the correct work item as a changeset link
Unlink it from the wrong work item
If you do it in reverse order, and get the changeset number wrong, you will have an orphan changeset.