Interoperation of C# application and C++ DLLs

Recently in C# .NET project, extra C++ modules were needed to provide some services. For the inter-module communication between C# and C++, P/Invoke method was chosen because it’s quick.

In the development machine, nothing particular happened in debugging session. But in release mode and in a demo. computer, it started to produce many unexpected results.

I found that Visual Studio IDE does not provide a relevant wizard. Everything is left to a developer to arrange various settings here and there. I believe those efforts are not related to the intrinsic function of the target software, but the efficiency of IDE itself.

However we cannot neglect this point as it usually takes a lot of time in such kind of projects. This memo is for developers including myself to save time in similar projects in future.


I. Backgrounds

1.Module Design

a.Main program: C#;

b.Special functions: C++ DLLs;

c.Interface: P/Invoke;

2.Technical Environment

a.Development: Windows 10;

b.IDE:                  VS2015 Community Edition;

c.Demo. Computer: Windows 8.1;


C++ DLLs function well in the debugger mode in IDE. But since in the release mode, they made errors as follows,

1.”Unresolved external symbols, __imp__CreationFontW” error came out, in build phase;

2.”Unable to load DLL: could not find”, in execution at the demo computer;

III. Analysis

1.”Unresolved Symbols” in Build Phase

IDE needs libraries which have entries available to the C++ source;

2.”Unable to Load DLL: Could Not Find”

The application is trying to load DLLs to fail because of platform mismatch or bad image format. Therefore it is necessary to make the DLL fit to the target platform and run standalone.

IV. Solution

1.For the C++ DLL in development platform

a.In IDE solution explorer, have the project  to retarget SDK version (in my case 8.1);

b.In the project properties, set

(1)Configuration to “Release”;

(2)Platform to “Active(win32)”;

(3)At Configuration Manager:

(a)Active Solution Configuration: “Release”;

(b)Active Solution Platform: “Win32”;

(c)At Project Context:

– Configuration: “Release”;

– Platform: “Win32”;

– Build: Checked;

(4)C/C++  >  Code Generation  >  RunTime Library to “/MT”;

(5)Linker  >  Additional Dependency to the libraries which contain entries from the unresolved external symbols (ex: gdi32.lib);


d.Repeat the above settings for another DLLs, if any;

e.If checking the DLLs in the Dependency Walker, it may shows the CPU x86 while others are x64. Don’t care;

2.For the C# main project.

a.Include the above built DLL files into the main project;

b.Set their “Copy to Output Directory” property to “Copy Always”;

c.Set the main project’s property “Allow unsafe code” to true, if necessary;

d. Publish;

e. Install the application in the demo computer;

V. Conclusion

The solution may vary case by case. In my case, the above solution shot all the problems. My demo system works great even with SQL server 2014.

For this, I rummaged,, and of course as well.

Leave a Comment

Filed under News

Leave a Reply

Your email address will not be published. Required fields are marked *