Things to Watch Out for When Creating a DLL

1. Use extern "C" + __declspec(dllexport) to expose functions

#pragma once
#ifdef MYDLL_EXPORTS
#define MYDLL_API __declspec(dllexport)
#else
#define MYDLL_API __declspec(dllimport)
#endif

extern "C" {
    MYDLL_API bool MyFunction(char* buffer, int len);
}

• extern "C" disables C++ name mangling, making the function callable from C# or other languages via DllImport.

2. Specify the target platform clearly (x64 or x86)

• If the application using the DLL is built for x64, the DLL must also be x64.
• C# applications built with AnyCPU typically run as x64 on 64-bit machines.
• However, due to Visual Studio settings or runtime behavior, x86 DLLs might be used. It’s best to explicitly match the bitness.

3. Explicitly declare only the functions you want to expose in the header

• Internal functions should be marked as static or defined only within .cpp files to prevent external access.

4. Be mindful of data marshaling

• C++ uses char* strings, which do not exist in C#. Use StringBuilder on the C# side.
• C++ and C# bool types differ in size (1 byte vs. 4 bytes), so marshaling must be explicitly defined.

[DllImport("mydll.dll", CallingConvention = CallingConvention.Cdecl, CharSet = CharSet.Ansi)]
[return: MarshalAs(UnmanagedType.I1)]
private static extern bool mydll_function([Out][MarshalAs(UnmanagedType.LPStr)] StringBuilder buffer, int bufferMaxLength);

5. If you include SDKs or external libraries

• Ensure .lib and .dll files are built for the same architecture.
• All dependent DLLs must be copied to the execution directory.
• If even one DLL has a mismatched bitness, an error will occur.

How to Handle Common Errors

An attempt was made to load a program with an incorrect format. (0x8007000B)

• Cause: Bitness mismatch e.g. Application is x64, but DLL is x86
• Check with

dumpbin /headers mydll.dll | findstr machine

• Use the Dependencies tool to check bitness of all dependent DLLs. A single mismatch can cause this error.

DllNotFoundException BadImageFormatException

• Cause: DLL is missing from the executable directory, or a dependency is missing, or the DLL failed to load due to path/format issues.

• • Debug with:

    • Dependencies: Check all DLL dependencies

    • ProcMon: Trace the actual path of DLL loading

    • Check if the function is exported using:

       dumpbin /exports mydll.dll
      

AccessViolationException

• Cause: C++ function signature and C# declaration do not match

  Solution: Check function signatures and types.

  • Example: C++ bool is 1 byte, but C# bool is 4 bytes—explicit marshaling is required.

C++ and C# Interop Compatibility Table

Tools

• Dependencies: Check for DLL dependencies

• Procmon: Monitor and trace DLL loading

Initial Problem

In my original code, the #include directives were ordered like this:

cppCopyEdit#include "SDK1.h"
#include "SDK2.h"
#include <opencv2/opencv.hpp>

This worked perfectly fine in a standard C++ executable project.

However, when I used the same headers in a DLL project, several syntax errors and warnings started to appear — all originating from the SDK headers:

bashCopyEdit'(': illegal token on right side of '::'
'std::tr1': warning STL4002: The non-Standard std::tr1 namespace and TR1-only machinery are deprecated and will be REMOVED.
syntax error: ')' was unexpected here; expected ';'
syntax error: unexpected token ')' following 'expression-statement'

Solutions

Reordering the #include statements as shown below resolved all the errors:

cppCopyEdit#include <opencv2/opencv.hpp>
#include "SDK1.h"
#include "SDK2.h"

After this change, all the syntax errors in the SDK headers disappeared, and the DLL built successfully.

Why This Happens

In C++, the order of #include statements can significantly impact how the compiler interprets macros, types, and templates. Some headers may rely on specific macros or definitions being present before they are included.

Here are a few common reasons this issue can occur:

• Macros defined by libraries like OpenCV (e.g., NOMINMAX, or standard headers like <memory>) may influence how later headers (like SDKs) behave.
• DLL builds often have different preprocessor definitions or runtime settings than EXE builds, making them more sensitive to include order.
• Make sure that all relevant macros (e.g., warning suppressors, configuration flags) are defined before including any headers that depend on them. Header files may rely on preprocessor definitions to alter their behavior, so the order of definitions and includes is critical to avoid unexpected compilation issues

In complex C++ projects — especially those using large SDKs or third-party libraries — #include order matters.

Conclusion

Even if two C++ projects use the same SDK, the compilation context (DLL vs EXE) can introduce small differences. The order of your #include directives can make or break a build — especially when working with older SDKs, deprecated features, or platform-specific macros.

• Always include system and standard headers first.
• Then third-party libraries (like OpenCV).
• Finally, project-specific or SDK headers.