Einstellung dllimport programmgesteuert in C#

Ich bin mit DllImport in meiner Lösung.

Mein problem ist, dass ich zwei Versionen der gleichen DLL gebaut, für 32 bit und eine für 64 bit.

Beide setzen die gleichen Funktionen mit identischen Namen und identischen Signaturen.
Mein problem ist, dass ich zwei statische Methoden, die aussetzen, und diese dann zur Laufzeit verwenden IntPtr Größe zu bestimmen, die richtige zu berufen.

private static class Ccf_32
{
    [DllImport(myDllName32)]
    public static extern int func1();
}

private static class Ccf_64
{
    [DllImport(myDllName64)]
    public static extern int func1();
}

Habe ich zu tun, weil myDllName32 und myDllName64 muss konstant sein und ich habe nicht gefunden, einen Weg, um es zur Laufzeit.

Hat jemand eine elegante Lösung, damit konnte ich loswerden der code-Duplizierung und die ständige IntPtr Größe überprüfen.

Wenn ich könnte den Namen der Datei, ich möchte nur noch einmal überprüfen, und ich konnte loswerden von einer Tonne wiederholt-code.

  • Keinen Sinn in der Auswahl zur Laufzeit, wenn der Unterschied ist die ganze Zusammenstellung.
InformationsquelleAutor Matt | 2009-08-23
  1. 12

    Kann man wohl erreichen, das mit der #if Schlüsselwort. Wenn du definieren eines bedingten compiler-symbol genannt win32 dem folgenden code wird die Verwendung der win32-block, wenn Sie es entfernen, wird es mit dem anderen block:

    #if win32
    private static class ccf_32
    {
        [DllImport(myDllName32)]
        public static extern int func1();
    }
#else    
    private static class ccf_64
    {
        [DllImport(myDllName64)]
        public static extern int func1();
    }
#endif

    Bedeutet dies wohl, dass Sie können entfernen Sie die Klasse Verpackung, die Sie jetzt haben:

        private static class ccf
    {
#if win32
        [DllImport(myDllName32)]
        public static extern int func1();
#else    
        [DllImport(myDllName64)]
        public static extern int func1();
#endif
    }

    Für Komfort, ich denke, man könnte erstellen build-Konfigurationen für die Steuerung der compilation-symbol.

    • Ja, aber ich möchte zu halten Sie den "Any CPU" - option im Gegensatz zu 32-und 64-bit-Versionen.
    • Während es funktioniert, ist dieser Ansatz führt immer noch in der code-Duplizierung der original-poster vermeiden will, plus schränkt Sie zu kompilieren separate Versionen für 32-und 64-bit. Sie können entfernen Sie die code-Duplizierung und weiter zum Ziel-beide 32-und 64-bit-Versionen mit einer kompilierten DLL/EXE-Datei durch die Einnahme deanis Ansatz SetDllDirectory, oder mir mit LoadLibrary.
    InformationsquelleAutor Fredrik Mörk
  2. 18

    Ich lieber tun dies, indem Sie die LoadLibrary Anruf von kernel32.dll zu zwingen, eine bestimmte DLL laden von einem bestimmten Pfad.

    Wenn Sie Namen für Ihre 32-bit-und 64-bit-DLLs, die die gleichen, aber Sie in verschiedenen Pfaden haben, können Sie dann den folgenden code verwenden, laden Sie die richtige version von Windows Sie ausgeführt werden. Alles, was Sie tun müssen, ist Anruf ExampleDllLoader.LoadDll (), BEVOR code verweisen auf die ccf Klasse referenziert:

    private static class ccf
{
    [DllImport("myDllName")]
    public static extern int func1();
}

public static class ExampleDllLoader
{
    [DllImport("kernel32", CharSet = CharSet.Unicode, SetLastError = true)]
    private extern static IntPtr LoadLibrary(string librayName);

    public static void LoadDll()
    {
        String path;

        //IntPtr.Size will be 4 in 32-bit processes, 8 in 64-bit processes 
        if (IntPtr.Size == 4)
            path = "c:/example32bitpath/myDllName.dll";
        else
            path = "c:/example64bitpath/myDllName.dll";

        LoadLibrary(path);
    }
}
    • Es sieht aus wie diese Lösung erfordert, dass der Benutzer hat admin-Rechte. Kann das jemand bestätigen?
    • Dies sollte nicht erfordern admin-Rechte, so lange der Benutzer hat die Berechtigungen zum Lesen der DLL, die geladen wird. Ich habe es in Situationen, in denen ein normaler Benutzer die Anwendung ausgeführt wird.
    InformationsquelleAutor Josh Sklare
  3. 10

    Ich weiß, das ist eine wirklich alte Frage (ich bin neu - ist es schlecht um die Antwort auf eine alte Frage?), aber ich hatte einfach zu lösen, dieses problem. Ich hatte zu dynamisch verweisen auf eine 32-bit-oder 64-bit-DLL auf Basis von OS, während meine .EXE-Datei kompiliert wird, die für Jede CPU.

    Können Sie verwenden, DLLImport, und Sie brauchen nicht mit LoadLibrary().

    Ich habe dies mithilfe der SetDLLDirectory. Im Gegensatz zu den Namen, die SetDLLDirectory fügt dem DLL-Suchpfad, und ersetzen nicht den gesamten Pfad. Dies erlaubte mir, um eine DLL mit dem gleichen Namen ("TestDLL.dll" für diese Diskussion) in Win32-und Win64-sub-Verzeichnisse und entsprechend aufgerufen.

    public partial class frmTest : Form
{
    static bool Win32 = Marshal.SizeOf(typeof(IntPtr)) == 4;
    private string DLLPath = Win32 ? @"\Win32" : @"\Win64";

    [DllImport("kernel32.dll", SetLastError = true)]
    public static extern bool SetDllDirectory(string lpPathName);
    [DllImport("TestDLL.dll", SetLastError = true)]
    static extern IntPtr CreateTestWindow();

    private void btnTest_Click(object sender, EventArgs e)
    {
        string dllDir = String.Concat(Directory.GetCurrentDirectory(), DLLPath);
        SetDllDirectory(dllDir);

        IntPtr newWindow = CreateTestWindow();
    }
}
    • Dies ist ein großer Ansatz, vor allem, wenn Sie mehrere DLLs, müssen Sie die 32-und 64-bit-Versionen. Ich glaube, ich mag die SetDllDirectory Ansatz sogar besser als mit der LoadDll Methode, die ich schon in meiner Antwort. Es ist auch eine ganze Menge weniger code als die wrapper-Ansätze, und lassen Sie Sie kompilieren eine Beliebige CPU.
    InformationsquelleAutor deanis
  4. 2

    Warum nicht wickeln Sie Sie in eine Methode?

    private static class ccf_32_64
{
    private static class ccf_32
    {
        [DllImport(myDllName32)]
        private static extern int func1();
    }

    private static class ccf_64
    {
        [DllImport(myDllName64)]
        private static extern int func1();
    }

    public static int func1()
    {
        if (32bit)
        {
            return ccf_32.func1();
        }
        else
        {
            return ccf_64.func1();
        }
    }
}
    • Das ist im Grunde das, was ich jetzt habe 🙂
    • Nun, nachdem du es einpacken, die Sie nicht haben, um über sorgen es.
    InformationsquelleAutor ChaosPandion
  5. 1

    Eine alternative option ist, um sowohl die 32 - und 64-bit-Versionen von der nicht verwalteten DLL müssen den gleichen Namen haben, aber Sie Leben in separaten Ordnern in Ihren build-output (z.B. x86\ und x64\).

    Dann, sich an Ihren Installateur oder wie auch immer man die Verteilung dieser wird aktualisiert, so dass es weiß, zu installieren, die entsprechende DLL für die Plattform, die es installieren.

    InformationsquelleAutor Zack Elan
  6. 1

    können Sie auf zwei Methoden, und wählen Sie eine in einer Laufzeitumgebung, so dass Sie halten können Any CPU

    public static class Ccf
{
    [DllImport(myDllName32)]
    private static extern int func32();

    [DllImport(myDllName64)]
    private static extern int func64();


    public static int func()
    {
        if(Environment.Is64BitProcess)
        {
            return func64();
        }
        return func32();
    }

    }

    InformationsquelleAutor GSerjo
  7. 0

    Können Sie nicht tun, wie Sie wollen. Sie müssen denken, der DllImport - Attribut Metadaten, die verwendet wird zur compile-Zeit. Als Ergebnis können Sie nicht ändern Sie die DLL importiert dynamisch.

    Wenn Sie möchten, um Ihr verwalteten code gezielt auf "Any CPU", dann muss man entweder importieren Sie sowohl die 32-bit-und 64-bit-Bibliotheken gewickelt als zwei verschiedene Funktionen, die Sie aufrufen können, abhängig von der Laufzeitumgebung oder zusätzliche Win32-API-Aufrufe zu spät-laden Sie die richtige version von der nicht verwalteten assembly zur Laufzeit und zusätzliche Win32-Aufrufe zur Ausführung der erforderlichen Methoden. Der Nachteil dort ist, dass Sie nicht haben, compile-time support für diese Art von code für die Art der Sicherheit, etc.

    InformationsquelleAutor Scott Dorman
  8. 0

    Hmm, ich Frage mich, ob Sie könnte eine Schnittstelle erstellen und dann eine Klasse mit den Methoden basierend auf der 32-bit-und 64-bit-dlls.

    Ich bin mir nicht sicher, ob es eine explizite Methode, um zu bestimmen, wenn Sie mit 64 bit, aber Folgendes könnte funktionieren: allow unsafe code und haben eine unsichere Funktion bekommt einen Zeiger auf eine bestimmte Speicheradresse und dann bestimmen, ob der Zeiger ist 4 oder 8 bytes groß. Basierend auf den Ergebnissen bestimmen, welche implementation des interface zu erstellen.

    InformationsquelleAutor Brent Scriver
  9. 0

    Können Sie bestimmen, ob Sie 64 bit oder nicht, indem Sie die Größe der IntPtr-Typ (die nennt sich native int sowieso).
    Sie können dann laden Sie die zugehörige DLL einen importierten LoadLibraryW-Aufruf, die Funktion Zeiger mithilfe von GetProcAddress, und dann, check-out Marschall.GetDelegateForFunctionPointer

    Diese nicht annähernd so kompliziert, wie es Aussehen könnte. Sie müssen DllImport beide LoadLibraryW und GetProcAddress.

    InformationsquelleAutor Robert Giesecke
Schreibe einen Kommentar