Dynamic-Link Library Best Practices - How to avoid deadlock?

Question

Background

I've read Dynamic-Link Library Best Practices and understood what I can and can't do in DllMain.

Now, say I have a visual studio 2013 solution containing many projects. each project generates different binaries/lib files.

Say I have some utility project, generating a lib file, used by all projects.

Now, this utility project, may define some generic functions that calls, for example, LoadLibrary function which based on the link above is something that: never perform the following tasks from within DllMain

Question

1. How can I implement a generic function, that "knows" that it can't use certain API because it is being called withing the scope of DllMain function?

2. Is it possible to access windows loader lock and by that disable certain calls or change function's algorithm if it is locked?

Example

Project Utility

wstring GetUserName() // just an example!
{
   // do something including LoadLibrary call
}

Project A

BOOL WINAPI DllMain(
  _In_  HINSTANCE hinstDLL,
  _In_  DWORD fdwReason,
  _In_  LPVOID lpvReserved
)
{
   // calls Utility - GetUserName()
}

Project B

int _tmain(int argc, _TCHAR* argv[])
{
   // calls Utility - GetUserName()
}

While the call to function GetUserName() is perfectly fine in Project B, it is prohibited in Project A

I want to make mu solution smart in such way that I avoid such cases.

Theoretical approach

wstring GetUserName() // just an example!
{
   if( IsLoaderLocked() )
      // do something excluding LoadLibrary call
   else
      // do something including LoadLibrary call
}

the if( IsLoaderLocked() ) is not a real code, of course. Just an example of a condition I'd like to evaluate before calling "dangerous" API.