That's interesting. I tried your code, and the constructor is really
called twice.

However, I don't understand why your Settings::internalFunction is
static. Since Settings is a singleton class, it's not really needed to
make any of its members static. I modified your code this way:

Settings.hpp:
void internalFunction();

Settings.cpp:
void Settings::internalFunction()
{
   getProperty();
}

Wrapper.h:
static void doSomething() {
   Settings::instance().internalFunction();
}

And now it works fine, the constructor is only called once.

I also took a look at your project settings, and noticed that your
SingletonTest.lib is NOT compiled with the /clr. Mixing managed and
unmanaged code can somtimes bring up very subtle problems, as you can
read it at Marcus Heege's blog:

http://www.heege.net/blog/default.aspx#ad5e2c3da-ff4d-40bc-bea9-9da8ec9e091e

Read "Avoid native code in managed object files (".obj" files)"

I'm not sure if your problem is related to this in any way, but guess
what. I recompiled your SingletonTest.lib with the /clr settings, then
the rebuilt the dll and the C# code, and the problem disappeared.

So I gave you 2 different workarounds for your problem.

I'm not sure if this glitch is considered a compiler bug, or simply bad
practice, but it certainly looks serious to me.

Tom

I know exactly what's wrong with your project. When you compile a
project with /clr, the default is #pragma managed. When you compile it
without /clr, the default is #pragma unmanaged. Now you can mix the two
things, but you have to make sure that the *same* piece of header file
is compiled with the same settings.

In your project, when you #include "Settings.hpp" and "Singleton.hpp",
the same declaration is compiled as #pragma unmanged in the unmanaged
LIB, and with #pragma managed in the managed DLL. The two things are
*not* byte compatible! You're compiling the same piece of code with
completely incompatible ways, and then link to two things together.

The simplest fix to your problem is to go to Wrapper\Stdafx.h, and
modify it to the following:

#pragma unmanaged
#include "Settings.hpp"
#pragma managed

Please forget my previous message that I sent yesterday. It's not that
it's not correct, but it doesn't show your real problem. Your real
problem is explained in this message.

Just to clarify things. You are not normally required to compile every
native-style class with #pragam unmanaged. You can very easily compile
ISO C++ classes into managed code:

#pragma managed
class NativeClass { }; // generates managed code

However, you're including a non-/clr header file to your /clr project.
You really have to make sure that the compiler settings are matching.

This is the same kind of mistake as putting #ifdef _DEBUG into your
header file, and linking your library project without _DEBUG defined,
but your main application with _DEBUG defined. When the same header file
is compiled with different compiler options, you're calling for trouble.
You can easily lose byte compatibility. This is exactly what happened
with your project -- Singleton.hpp was compiled with one compiler
setting here, and another compiler setting there, and then the two
things were linked together.

Now I can tell for sure that this was definitely not the compiler's
fault. This is something you have to watch carefully when mixing
unmanaged and managed units.

Hope this helps.

Tom