Delay loading dll in release mode

The more I think about this, the more it looks like a [Wikipedia]: XY problem.

1. The X (running the MEX file on a machine with no MATLAB libraries)

According to [MathWorks]: Run MEX File You Receive from Someone Else (emphases are mine):

On Windows® platforms, install the C++ compiler run-time libraries used to create the MEX file.

...

A MEX file is a dynamically linked subroutine that the MATLAB interpreter loads and executes when you call the function. Dynamic linking means that when you call the function, the program looks for dependent libraries. MEX files use MATLAB run-time libraries and language-specific libraries. A MEX file might also use specialized run-time libraries. The code for these libraries is not included in the MEX file; the libraries must be present on your computer when you run the MEX file.

[MathWorks]: MATLAB Runtime contains links for downloading many versions (yours - according to your paths - would be [MathWorks]: MCR Runtime - MCR_R2012a_win32_installer.exe), which are free (I installed 3 of those versions to test this scenario), and also states:

Run compiled MATLAB applications or components without installing MATLAB

So, it's pretty clear (to me) that whoever would like to use that file, should install the MCR.

2. The Y (using Delay Loaded DLLs)

VStudio supports this feature ([MS.Docs]: Linker Support for Delay-Loaded DLLs) for quite some time.

Never worked with MEX files, nor do I have the full problem specs, but allowing one such file to run when there are no MATLAB .dlls present, doesn't look like good design to me (meaning that it also contains other stuff - which on my opinion should be placed separately). The only scenario that makes sense is that the MEX file would be an .exe (don't know whether this is possible or it's just a dumb thing) and it would have some --help equivalent (which would be nice (but not mandatory) to run on environments without the .dll's).
But that too could be solved using other ways (e.g. a README like file)

3. The end problem

Considering that there were / are multiple (logical) errors in the question:

• The .dlls passed to the linker
• The .lib files located in the bin dir
• The latest path (extern/lib/win64/microsoft) contains 64 bit .libs, while the linker is set for 32 bit output
• [MS.Docs]: Linker Tools Error LNK1107 which is pretty clear (as the error message in the question)

I can only conclude that for Release, "C:\Program Files (x86)\MATLAB\R2012a\bin\win32\libmx.dll" was incorrectly fed to the linker (instead of the corresponding .lib).

I played a little bit with MEX:

code.c:

#include <stdio.h>
#include <conio.h>
#include <mex.h>


int main(int argc, char **argv) {
    if (argc > 1) {
        fprintf(stdout, "Argument passed: mexEvalString() returns\n", mexEvalString("n = 1;"));
    } else {
        fprintf(stdout, "Argument NOT passed: pass...\n");
    }
    fprintf(stdout, "Press a key to exit...\n");
    _getch();
    return 0;
}

Notes:

• I used fprintf because in mex.h there is a line:

  #define printf mexPrintf
  

• Didn't know what function to use from libmx.dll, to force it being added directly (not just a dependency for libmex.dll)

• I was able to test the Delay Laded DLLs feature in Debug and Release (when passing no arg, the program ran without adding the MEX .dlls to %PATH%).
  It's true that at runtime I got Access Violation, but that's a totally different issue
• Needless to say that adding any of the .dlls to "Linker -> Input -> Additional Dependencies", triggered the exact same error

At the end, I would like to mention that MCR R2012a (and some others that were released after it), are built with VStudio 9.0 (2008), and building your program with VStudio 10.0 (2010), will yield having both CRT Libs in loaded your process, and in some cases that might trigger some errors (especially since VStudio 9.0's comes as an assembly).
This applies to libmx.dll and libmex.dll, but not libeng.dll.