Debugging your deployed native release build on a remote machine with visual studio

Another cpp nightmare.
Debugging managed libraries remotely was rather easy. Have the remote debugging tools installed, run the code on the remote machine, attach to it via your local VS, have the right pdbs ready, done. You're debugging.

Of course, you should be sure that the pdbs actually match the dlls. That can be checked with an appropriate tool.

For native code, apparently, the debug symbols need to be placed into the same directory as on the remote machine. Like, if it's remotely in "C:\some\where\strange\myProg.exe", then you need to create this strange directory on your local machine as well.

I didn't find anything on the web which explicitly stated that.

Here are some other links, which might be of help:
http://www.codeproject.com/Articles/146838/Remote-debugging-with-Visual-Studio
Remote Debugging and Diagnostics (vs 2013)
and, of course, a most cited resource about pdb files in general (native and managed):
http://www.wintellect.com/blogs/jrobbins/pdb-files-what-every-developer-must-know

But they seem to deploy directly what you build to a remote machine, instead of having corporate release builds installed on them and then debugging them with the pdb files which the build machine thankfully published as well.

cpp c++ linker warnings which look like name mangling problems but are cause by classes not being exposed in the dll

Today, I wanted to write some tests for a cpp dynamic library under windows.
Such a build still generates the .lib file, like for static libs, but this .lib file only contains some header information or somesuch.
In the end, the .dll will be used.

Then, when I tried to compile the tests, I got this:
1>SwarmTests.obj : error LNK2001: unresolved external symbol "public: __thiscall Swarm::SpecificChainer::SpecificChainer(long,class std::basic_string<wchar_t,struct std::char_traits<wchar_t>,class std::allocator<wchar_t> > const &,class std::basic_string<wchar_t,struct std::char_traits<wchar_t>,class std::allocator<wchar_t> > const &,class Swarm::ZergLink *)" (??0SpecificChainer@Swarm@@QAE@JABV?$basic_string@_WU?$char_traits@_W@std@@V?$allocator@_W@2@@std@@0PAVZergLink@1@@Z) 1>C:\dev\mycode\SwarmTests\Debug\SwarmTests.exe : fatal error LNK1120: 1 unresolved externals

After several hours of despair, I found out that the class:
Swarm::SpecificChainer
was declared like this:
class SpecificChainer {
 ctor...
  ...
}

But should have been declared like this:
class DLL_PUBLIC SpecificChainer {
 ctor...
  ...
}

The keyword is DLL_PUBLIC which will expose this class to the users of the dynamic library. See here on gnu.gcc.org for further information. All non-exposed classes are only visible internally.

I still don't know, why it's done like this, whether this is only on windows (can't remember that on linux) and if it's common for all dynamic cpp libs, why they didn't invent some smart keyword for that, like in c#: internal.