DllImport with different entry points (different DLLs for the same import in different projects)?

If the CF and desktop APIs have different entry points you need to work with this. It means you need different DllImport's defined Easiest may be to have two wrapper classes implementing all the internal (.NET) names, which call their import, then instantiate the correct one at runtime depending on platform. Then access the APIs through the common interface Interface IGLImports { IntPtr GetDisplay(EGLNativeDisplayType display_id); } static class CFRawImports { DllImport(DllName, EntryPoint = "eglGetDisplay") static extern IntPtr GetDisplay(EGLNativeDisplayType display_id); } static class DeskRawImports { DllImport(DllName, EntryPoint = "_eglGetDisplay@4") static extern IntPtr GetDisplay(EGLNativeDisplayType display_id); } class DesktopImports : IGLImports { public IntPtr GetDisplay(EGLNativeDisplayType display_id) { return DeskRawImports.

GetDisplay(display_id); } } class CFImports : IGLImports { public IntPtr GetDisplay(EGLNativeDisplayType display_id) { return CFRawImports. GetDisplay(display_id); } } static class ImportLoader { public static IGLImports GetImports() { if (isCF) { return new CFImports(); } else { return new DesktopImports(); } } } class MyApp { private static IGLIMports gl = ImportLoader.GetImports(); // In code use gl. GetDesktop(...) EDIT: The interface and four classes should be creatable with a little code generation.

Input file containing Name DesktopImport CFImport (maybe adding dll names if these vary). Would be an excuse to learn VS's T4 templating.

If the CF and desktop APIs have different entry points you need to work with this. It means you need different DllImport's defined. Easiest may be to have two wrapper classes implementing all the internal (.NET) names, which call their import, then instantiate the correct one at runtime depending on platform.

Then access the APIs through the common interface. Interface IGLImports { IntPtr GetDisplay(EGLNativeDisplayType display_id); } static class CFRawImports { DllImport(DllName, EntryPoint = "eglGetDisplay") static extern IntPtr GetDisplay(EGLNativeDisplayType display_id); } static class DeskRawImports { DllImport(DllName, EntryPoint = "_eglGetDisplay@4") static extern IntPtr GetDisplay(EGLNativeDisplayType display_id); } class DesktopImports : IGLImports { public IntPtr GetDisplay(EGLNativeDisplayType display_id) { return DeskRawImports. GetDisplay(display_id); } } class CFImports : IGLImports { public IntPtr GetDisplay(EGLNativeDisplayType display_id) { return CFRawImports.

GetDisplay(display_id); } } static class ImportLoader { public static IGLImports GetImports() { if (isCF) { return new CFImports(); } else { return new DesktopImports(); } } } class MyApp { private static IGLIMports gl = ImportLoader.GetImports(); // In code use gl. GetDesktop(...) EDIT: The interface and four classes should be creatable with a little code generation. Input file containing Name DesktopImport CFImport (maybe adding dll names if these vary).

Would be an excuse to learn VS's T4 templating ...

I hoped it would be easier. In that case, I think I'll prefer importing them with the right name and without specifying the entry point, and then just putting a wrapper around them to make the name beautiful. – OregonGhost Mar 17 '09 at 13:09 @your edit: Yes, a co-worker suggested a similar solution.

But as I already said, I won't need so many functions and will have to wrap them into my own small library anyway (you know, with classes and objects instead of free-floating functions)... We'll see ;) – OregonGhost Mar 17 '09 at 13:22 Never heard about T4 before, looked it up now. Seems fun! – Camilo Martin Nov 19 '10 at 6:47.

A decorated name is a string created by the compiler during compilation of the function definition or prototype. "@4" in the name means it has total parameter length of 4 bytes (a 32-bit integer? ).

You can use dumpbin. Exe to get the decorated names from you .dll.

Then I'd still have to put them somewhere into the wrapper project. Doesn't appeal to me :) – OregonGhost Mar 17 '09 at 13:07 I just oversaw your explanation of the @4 thing. Yes, it's a 32-bit int in that case.

+1 for that explanation, though it doesn't really help me ;) – OregonGhost Mar 17 '09 at 13:16 Thanks, sorry if it didn't help much. Hope you won't need to wrap too many methods! :) – Groo Mar 17 '09 at 13:22 No, shouldn't be too many, just basic 2D operations - it's just to get the 3D accelerator to be used.

Maybe it'll be OpenVG in the end, but I guess the problem is the same then? :D – OregonGhost Mar 17 '09 at 13:29.

Use #define yourdllname_API extern "C" __declspec(dllexport) to expose methods in your dll, avoiding function decoration that way you won't get above mentioned excepcion, example: DLL: #ifdef DEPLOYHOOK_EXPORTS #define DEPLOYHOOK_API extern "C" __declspec(dllexport) #else #define DEPLOYHOOK_API __declspec(dllimport) #endif // This class is exported from the DeployHook. Dll DEPLOYHOOK_API int nDeployHook; DEPLOYHOOK_API bool InstallHook(void); DEPLOYHOOK_API bool UnInstallHook(void); Calling Project/exe: DllImport("DeployHook. Dll",EntryPoint = "InstallHook",CharSet = CharSet::Auto, SetLastError = true) extern bool InstallHook(void); //EntryPointNotFoundException avoided.

That's unfortunately missing the point, since I don't have control over the imported DLLs. Thanks for your input anyway. – OregonGhost Jul 17 '09 at 8:26.

I cant really gove you an answer,but what I can give you is a way to a solution, that is you have to find the anglde that you relate to or peaks your interest. A good paper is one that people get drawn into because it reaches them ln some way.As for me WW11 to me, I think of the holocaust and the effect it had on the survivors, their families and those who stood by and did nothing until it was too late.