Currently, It is not possible to use a [DllImport] in .NET for WP8 to directly access an existing native function from a DLL (for example, all Supported Win32 APIs for Windows Phone http://msdn.microsoft.com/en-us/library/windowsphone/develop/jj662956%28v=vs.105%29.aspx), while it is perfectly possible to do this on standard .NET and .NET 4.5 Core (for Win8/WinRT).
The workaround is to develop an almost empty C++ WinPRT component to get an access to these pointer functions (like It as been developed in SharpDX project: http://code.google.com/p/sharpdx/source/browse/Source/SharpDX.WP8/SharpDXWP8.cpp). This C++ WinPRT component is actually acting exactly as a DllImport, except that we have to develop it just to bypass the .NET restriction.
Also, this restriction is implying lots of annoying collateral effects:
- We cannot develop "AnyCpu" library/application, and are forced to have a specific build for WP8 x86 and ARM. It makes the build much more laborious as we have to maintain a special case for WP8. When developing an application (like a Game) that is supposed to run on Desktop, WinRT and WP8, we expect to use most the same code everywhere, without having to compile platform specific assemblies (that is the purpose of DllImport specially when using systems DLL that are automatically redirected to the correct platform dll x86 or x64 for example).
- We cannot use "Portable Library Class" with WP8 when using native code, making "Portable Library Class" useless when using "DllImport" (We can only target .NET and .NET Core, but not WP8).
We understand that WinPRT could be in the future the only way to access native code, but because lots of Win32 API are still not yet ported to the WinRT model, we still need to access directly native code from .NET. The fact that is DllImport access is not possible on WP8 is not consistent with .NET and .NET Core (WinRT).
One great strength of .NET is to have seamlessly native code integration, please, please, fix this in a next release of WP8 SDK!