Comment puis-je spécifier un chemin [DllImport] au moment de l'exécution ?

Question

En fait, j'ai une DLL C++ (fonctionnelle) que je veux importer dans mon projet C# pour appeler ses fonctions.

Cela fonctionne lorsque je spécifie le chemin complet de la DLL, comme ceci :

string str = "C:\\Users\\userName\\AppData\\Local\\myLibFolder\\myDLL.dll";
[DllImport(str, CallingConvention = CallingConvention.Cdecl)]
public static extern int DLLFunction(int Number1, int Number2);

Le problème est que ce sera un projet installable, donc le dossier de l'utilisateur ne sera pas le même (ex : pierre, paul, jack, mum, dad, ...) selon l'ordinateur/session sur lequel il sera exécuté.

J'aimerais donc que mon code soit un peu plus générique, comme ceci :

/* 
goes right to the temp folder of the user 
    "C:\\Users\\userName\\AppData\\Local\\temp"
then go to parent folder
    "C:\\Users\\userName\\AppData\\Local"
and finally go to the DLL's folder
    "C:\\Users\\userName\\AppData\\Local\\temp\\myLibFolder"
*/

string str = Path.GetTempPath() + "..\\myLibFolder\\myDLL.dll"; 
[DllImport(str, CallingConvention = CallingConvention.Cdecl)]
public static extern int DLLFunction(int Number1, int Number2);

Le problème est que "DllImport" désire un paramètre "const string" pour le répertoire de la DLL.

Ma question est donc : : Que peut-on faire dans ce cas ?

Answer 1

Contrairement à ce que suggèrent certaines des autres réponses, l'utilisation de l'option DllImport L'attribut est toujours l'approche correcte.

Honnêtement, je ne comprends pas pourquoi vous ne pouvez pas faire comme tout le monde dans le monde et spécifier un relatif le chemin d'accès à votre DLL. Certes, le chemin dans lequel votre application sera installée diffère selon les ordinateurs, mais il s'agit là d'une règle universelle en matière de déploiement. Le site DllImport est conçu dans cette optique.

En fait, ce n'est même pas DllImport qui s'en occupe. Ce sont les règles de chargement des DLL Win32 natives qui régissent les choses, que vous utilisiez ou non les enveloppes gérées pratiques (le marshaller P/Invoke appelle simplement LoadLibrary ). Ces règles sont énumérées de manière très détaillée ici mais les plus importants sont extraits ici :

Avant que le système ne recherche une DLL, il vérifie les éléments suivants :

• Si une DLL portant le même nom de module est déjà chargée en mémoire, le système utilise la DLL chargée, quel que soit le répertoire dans lequel elle se trouve. Le système ne recherche pas la DLL.
• Si la DLL figure dans la liste des DLL connues pour la version de Windows sur laquelle l'application est exécutée, le système utilise sa copie de la DLL connue (et les DLL dépendantes de la DLL connue, le cas échéant). Le système ne recherche pas la DLL.

---

Si SafeDllSearchMode est activé (par défaut), l'ordre de recherche est le suivant :

1. Le répertoire à partir duquel l'application a été chargée.
2. Le répertoire du système. Utilisez le GetSystemDirectory pour obtenir le chemin de ce répertoire.
3. Le répertoire du système 16 bits. Il n'existe pas de fonction permettant d'obtenir le chemin de ce répertoire, mais il est recherché.
4. Le répertoire de Windows. Utilisez le GetWindowsDirectory pour obtenir le chemin de ce répertoire.
5. Le répertoire actuel.
6. Les répertoires qui figurent dans la liste des PATH variable d'environnement. Notez que cela n'inclut pas le chemin par application spécifié par la clé de registre App Paths. La clé App Paths n'est pas utilisée lors du calcul du chemin de recherche des DLL.

Ainsi, à moins que vous ne donniez à votre DLL le même nom qu'une DLL système (ce que vous ne devriez évidemment pas faire, jamais, en aucune circonstance), l'ordre de recherche par défaut commencera à chercher dans le répertoire à partir duquel votre application a été chargée. Si vous placez la DLL à cet endroit pendant l'installation, elle sera trouvée. Tous ces problèmes compliqués disparaissent si vous utilisez simplement des chemins relatifs.

Ecris juste :

[DllImport("MyAppDll.dll")] // relative path; just give the DLL's name
static extern bool MyGreatFunction(int myFirstParam, int mySecondParam);

Mais si cela n'a pas pour une raison quelconque, et que vous devez forcer l'application à rechercher la DLL dans un autre répertoire, vous pouvez modifier le chemin de recherche par défaut à l'aide de la commande SetDllDirectory fonction .
Notez que, selon la documentation :

Après avoir appelé SetDllDirectory Le chemin de recherche standard des DLL est le suivant

1. Le répertoire à partir duquel l'application a été chargée.
2. Le répertoire spécifié par l'option lpPathName paramètre.
3. Le répertoire du système. Utilisez le GetSystemDirectory pour obtenir le chemin de ce répertoire.
4. Le répertoire du système 16 bits. Il n'existe pas de fonction permettant d'obtenir le chemin de ce répertoire, mais il est recherché.
5. Le répertoire de Windows. Utilisez le GetWindowsDirectory pour obtenir le chemin de ce répertoire.
6. Les répertoires qui figurent dans la liste des PATH variable d'environnement.

Ainsi, tant que vous appelez cette fonction avant d'appeler pour la première fois la fonction importée de la DLL, vous pouvez modifier le chemin de recherche par défaut utilisé pour localiser les DLL. L'avantage, bien sûr, c'est que vous pouvez passer une fonction dynamique à cette fonction qui est calculée au moment de l'exécution. Ce n'est pas possible avec la fonction DllImport Vous continuerez donc à utiliser un chemin d'accès relatif (le nom de la DLL uniquement) et vous compterez sur le nouvel ordre de recherche pour la trouver pour vous.

Vous devrez P/Invoke cette fonction. La déclaration ressemble à ceci :

[DllImport("kernel32.dll", CharSet = CharSet.Auto, SetLastError = true)]
static extern bool SetDllDirectory(string lpPathName);

Answer 2

Encore mieux que la suggestion de Ran d'utiliser GetProcAddress il suffit de faire l'appel à LoadLibrary avant tout appel à la DllImport (avec seulement un nom de fichier sans chemin) et elles utiliseront le module chargé automatiquement.

J'ai utilisé cette méthode pour choisir, au moment de l'exécution, de charger une DLL native 32 bits ou 64 bits sans avoir à modifier un grand nombre de fonctions P/Invoke. Placez le code de chargement dans un constructeur statique pour le type qui a les fonctions importées et tout fonctionnera bien.

Answer 3

Si vous avez besoin d'un fichier .dll qui ne se trouve pas dans le chemin d'accès ou à l'emplacement de l'application, je ne pense pas que vous puissiez faire cela, car DllImport est un attribut, et les attributs sont uniquement des métadonnées qui sont définies sur les types, les membres et d'autres éléments de langage.

Une alternative qui peut vous aider à accomplir ce que je pense que vous essayez de faire, est d'utiliser la fonction native LoadLibrary via P/Invoke, afin de charger une .dll à partir du chemin dont vous avez besoin, puis d'utiliser GetProcAddress pour obtenir une référence à la fonction dont vous avez besoin à partir de ce fichier .dll. Utilisez-les ensuite pour créer un délégué que vous pouvez invoquer.

Pour faciliter son utilisation, vous pouvez ensuite définir ce délégué comme un champ de votre classe, de sorte que son utilisation ressemble à l'appel d'une méthode membre.

EDIT

Voici un extrait de code qui fonctionne et qui montre ce que je voulais dire.

class Program
{
    static void Main(string[] args)
    {
        var a = new MyClass();
        var result = a.ShowMessage();
    }
}

class FunctionLoader
{
    [DllImport("Kernel32.dll")]
    private static extern IntPtr LoadLibrary(string path);

    [DllImport("Kernel32.dll")]
    private static extern IntPtr GetProcAddress(IntPtr hModule, string procName);

    public static Delegate LoadFunction<T>(string dllPath, string functionName)
    {
        var hModule = LoadLibrary(dllPath);
        var functionAddress = GetProcAddress(hModule, functionName);
        return Marshal.GetDelegateForFunctionPointer(functionAddress, typeof (T));
    }
}

public class MyClass
{
    static MyClass()
    {
        // Load functions and set them up as delegates
        // This is just an example - you could load the .dll from any path,
        // and you could even determine the file location at runtime.
        MessageBox = (MessageBoxDelegate) 
            FunctionLoader.LoadFunction<MessageBoxDelegate>(
                @"c:\windows\system32\user32.dll", "MessageBoxA");
    }

    private delegate int MessageBoxDelegate(
        IntPtr hwnd, string title, string message, int buttons); 

    /// <summary>
    /// This is the dynamic P/Invoke alternative
    /// </summary>
    static private MessageBoxDelegate MessageBox;

    /// <summary>
    /// Example for a method that uses the "dynamic P/Invoke"
    /// </summary>
    public int ShowMessage()
    {
        // 3 means "yes/no/cancel" buttons, just to show that it works...
        return MessageBox(IntPtr.Zero, "Hello world", "Loaded dynamically", 3);
    }
}

Note : Je n'ai pas pris la peine d'utiliser FreeLibrary donc ce code n'est pas complet. Dans une application réelle, vous devez prendre soin de libérer les modules chargés pour éviter une fuite de mémoire.

Answer 4

DllImport fonctionnera sans que le chemin d'accès complet soit spécifié, à condition que la dll soit située quelque part dans le chemin d'accès du système. Vous pouvez peut-être ajouter temporairement le dossier de l'utilisateur au chemin.

Answer 5

Si tout échoue, il suffit de placer la DLL dans le répertoire windows\system32 dossier . Le compilateur le trouvera. Spécifiez la DLL à charger à partir de : DllImport("user32.dll"... ensemble EntryPoint = "my_unmanaged_function" pour importer la fonction non gérée de votre choix dans votre application C# :

 using System;
using System.Runtime.InteropServices;

class Example
{
   // Use DllImport to import the Win32 MessageBox function.

   [DllImport ("user32.dll", CharSet = CharSet.Auto)]
   public static extern int MessageBox 
      (IntPtr hWnd, String text, String caption, uint type);

   static void Main()
   {
      // Call the MessageBox function using platform invoke.
      MessageBox (new IntPtr(0), "Hello, World!", "Hello Dialog", 0);    
   }
}

Source et encore plus DllImport exemples : http://msdn.microsoft.com/en-us/library/aa288468(v=vs.71).aspx