Monthly Archives: February 2016

Symlinks/Junctions in Windows

I’m not sure which version of Windows these became available in, but a useful feature (as per *nix) is the capability of creating a link from one folder to another.

So for example, I have source code which relies on a set of libraries which are supplied in a zip (i.e. no NuGet or other packaging/versioning). So I tend to create a folder with the version number in it to make it easy to immediately see what version I’m using.

Great, but the problem with this approach is I also have tooling which automatically deploys these files and post build events which do similar things. Updating these every time I get a new version is repetitive and easy to make a mistake. Plus, I’m basically lazy, if I do something once I don’t want to do it again.

So it would be far better if we created a symbolic link to the newly downloaded zips/files with a name that all the tooling can expect, for example I’ll instead create a symlink named Latest which points to the actual version (this also means I could switch version if I want easily).

To create such a link we simply use

mklink /J Latest MyLibsv1.234

this command will create a junction (or symlink) named Latest and the folder it links to is MyLibsv1.234

Now we might use nant a batch file or some other means to do this for us, but when the link’s created you cannot update it (or so it seems), instead you need to delete it using

rd Latest

So now our post build events and/or other tooling can just refer to the folder Latest and everything works smoothly.

When it’s time to deploy MyLibsv2.0 we just delete the junction and create it again.

My Visual Studio 2012 C++ 32-bit application is “exe is not a valid Win32 application”

I have a C++ application which I’ve just updated to be built using Visual Studio 2012. The original solution was developed in Visual Studio 2010, so I updated the project properties, Configuration Properties | General | Platform Toolset to Visual Studio 2012.

The application is a 32-bit application, everything was built for 32-bit and all worked well on Windows 7, but on Windows XP (which is still used by some of our users) it failed with the “exe is not a valid Win32 application”.

Checking the configuration manager suggested it was indeed a 32-bit application. Running dumpbin /headers app.exe confirmed it definitely was a 32-bit application but XP said no it wasn’t.

Here’s the thing – I hadn’t noticed when setting the Platform Toolset, there was a second option Visual Studio 2012 – Windows XP (v1100_xp).

Changing to this toolset fixed the problem. So 32-bit does not mean 32-bit on all Windows.