Visual Studio 2017 support for Matlab 2016a

Back to Blog

27.03.2017 (08.12.2017)

In this post I will provide an unofficial way to add Visual Studio 2017 support into Matlab 2016a. The same files may or may not also work with previous or upcoming versions. The compiler build number changes at each new minor version. Current versions include 15, 15.4, and 15.5.

64-bit Matlab

In a default-installation of Matlab 2016a 64-bit, the option-files and scripts are located at one of the following directories:

C:\Program Files\MATLAB\R2016a\bin\win64\mexopts
C:\Program Files\MATLAB\MATLAB Production Server\R2016a\bin\win64\mexopts

Extract the .zip package from below into the directory above.

VS2017 support for Matlab 2016a 64-bit

32-bit Matlab

Starting from Matlab 2016a, a 32-bit version of Matlab is no longer produced.

Modifications to the files

To produce the given files for the original VS2017, I took the option files for VS2015

msvc2015.xml
msvcpp2015.xml

and copied them to

msvc2017.xml
msvcpp2017.xml

The config-files for C and C++ are almost identical.

Replacements

I then replaced strings as follows:

When replacing amd64, I left CommandLineShellArg="amd64" as it is.

VSCOMMONDIR

I added the following entry after VCINSTALLDIR:

<VSCOMMONDIR>
      <and>
          <or>
              <hklmExists path="SOFTWARE\Microsoft\VisualStudio\SxS\VS7" name="15.0" />
              <hkcuExists path="SOFTWARE\Microsoft\VisualStudio\SxS\VS7" name="15.0" />
              <hklmExists path="SOFTWARE\Wow6432Node\Microsoft\VisualStudio\SxS\VS7" name="15.0" />
              <hkcuExists path="SOFTWARE\Wow6432Node\Microsoft\VisualStudio\SxS\VS7" name="15.0" />
          </or>
          <dirExists name="$$\Common7" />
      </and>
</VSCOMMONDIR>

PROF_ENV

Visual Studio does not define the VS150COMNTOOLS environment variable, which would be used in the PROF_ENV section. Therefore, I replaced the PROF_ENV section with:

<PROF_ENV>
  <and>
      <or>
          <hklmExists path="SOFTWARE\Microsoft\VisualStudio\SxS\VS7" name="15.0" />
          <hkcuExists path="SOFTWARE\Microsoft\VisualStudio\SxS\VS7" name="15.0" />
          <hklmExists path="SOFTWARE\Wow6432Node\Microsoft\VisualStudio\SxS\VS7" name="15.0" />
          <hkcuExists path="SOFTWARE\Wow6432Node\Microsoft\VisualStudio\SxS\VS7" name="15.0" />
      </or>
      <fileExists name="$$\Common7\IDE\devenv.exe" />
  </and>
</PROF_ENV>

Later versions

Later minor versions 15.4 and 15.5 updated the Windows SDK from 8.1 to 10.0, as well the compiler build number. These required some additional replacements, but the idea remains the same.

Config files

The config files work with the following logic. Keyword hklmExists looks up a key name in the registry path path in HKEY_LOCAL_MACHINE. Similarly for hkcuExists, but in HKEY_CURRENT_USER.

Whenever a test such hklmExists or dirExists succeeds, it assigns the found path as the current path, which can then be accessed by double-dollars $$. Tests can be combined with either and or or.

When paths are looked up inside the locationFinder, a lookup cannot reuse a previously computed value, such as VCROOT; variables such as VCROOT are available only after locationFinder. This explains why the config-file is so repetitive.

Sometimes a file such as cl.exe is looked up as a check using fileExists, whose containing directory is recovered by a trivial dirExists.

Disclaimer

Of course, adding full support for a compiler cannot be as simple as that. This means that the above may or may not work for you, depending on which kind of things you will build. However, it does work for me, and it’s worth trying if you have no other option. If it does not work, then you will probably have linking errors, or crashing mex files, but you’ll find soon enough:p

Remark 1.7.8 - Page generated 01.01.2023 00:19.