This is a proof of concept demonstrating that an Azure Web App
can include a C++ unmanaged library and call functions from it.
The project Ugly
is an unmanaged C++ project.
The file Ugly.cpp
contains a function called fnUgly
:
UGLY_API int fnUgly(void)
{
return 42;
}
The file Ugly.h
exports the fnUgly
function:
extern "C" {
UGLY_API int fnUgly(void);
}
You'll need to compile the DLL against the expected architecture (32 vs 64 bits).
All you need to do to use an unamanged library is to copy it to your bin
directory.
I achieved this by adding the DLLs to the project, have a look at the Api\Ugly\x64
folder.
Build Action
:None
Copy to Output Directory
:Copy if newer
The code is located in HomeController
/*
* The path is relative to the bin folder.
* The function name has to match the function name in the C++ DLL,
* if required you can override this via the EntryPoint property
* in the DllImportAttribute
*/
[DllImport("Ugly\\x64\\Ugly.dll")]
public static extern int fnUgly();
/* [...] */
var value1 = fnUgly().ToString();
By default Serilog will write to D:\home\LogFiles\
, it's a hack I know but it was the fastest way to get logging up and running. You can download the log files via the Kudu console.
If you need to log somewhere else you can create a LogPath
key in your Web.config
.
If you can't manage to call into your unmanaged DLL you can uncomment LoadNativeAssemblies
in WebApiApplication
. This will attempt to load the unmanaged DLLs manually and generate better errors in the logs.
Your unmanaged DLL might depend on other unmanaged libraries that are not deployed on the target machine.
I don't know if you can enable Fusion logs in a PaaS environment or use the dependency walker. The fastest way to figure out which native modules are required is to use Process Monitor to see which files are being accessed by the process.