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

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, maman, papa, ...) en fonction de l'ordinateur / session sur lequel il sera exécuté.

Alors j'aimerais 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 gros problème est que "DllImport" souhaite un paramètre "const string" pour le répertoire de la DLL.

Ma question est donc: que pourrait-on faire dans ce cas?

Contrairement aux suggestions de certaines des autres réponses, l'utilisation de l' DllImportattribut reste la bonne approche.

Honnêtement, je ne comprends pas pourquoi vous ne pouvez pas faire comme tout le monde dans le monde et spécifier un chemin relatif vers votre DLL. Oui, le chemin dans lequel votre application sera installée diffère sur les ordinateurs de différentes personnes, mais c'est fondamentalement une règle universelle en matière de déploiement. Le DllImportmécanisme est conçu dans cet esprit.

En fait, ce n'est même pas cela DllImportqui le gère. Ce sont les règles de chargement de la DLL Win32 native qui régissent les choses, que vous utilisiez ou non les wrappers gérés pratiques (le marshaller P / Invoke appelle simplement LoadLibrary). Ces règles sont énumérées en détail ici , mais les plus importantes sont extraites ici:

Avant que le système 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 s'exécute, 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 SafeDllSearchModeest 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 système. Utilisez la GetSystemDirectoryfonction pour obtenir le chemin de ce répertoire.
3. Le répertoire système 16 bits. Aucune fonction n'obtient le chemin de ce répertoire, mais il est recherché.
4. Le répertoire Windows. Utilisez la GetWindowsDirectoryfonction pour obtenir le chemin de ce répertoire.
5. Le répertoire actuel.
6. Les répertoires répertoriés dans la PATHvariable d'environnement. Notez que cela n'inclut pas le chemin d'accès 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 DLL.

Ainsi, à moins que vous ne nommiez votre DLL de la même manière 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 là pendant l'installation, elle sera trouvée. Tous les problèmes compliqués disparaissent si vous utilisez simplement des chemins relatifs.

Ecrivez:

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

Mais si cela ne fonctionne 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 SetDllDirectoryfonction .
Notez que, selon la documentation:

Après l'appel SetDllDirectory, le chemin de recherche standard de la DLL est:

1. Le répertoire à partir duquel l'application a été chargée.
2. Le répertoire spécifié par le lpPathNameparamètre.
3. Le répertoire système. Utilisez la GetSystemDirectoryfonction pour obtenir le chemin de ce répertoire.
4. Le répertoire système 16 bits. Aucune fonction n'obtient le chemin de ce répertoire, mais il est recherché.
5. Le répertoire Windows. Utilisez la GetWindowsDirectoryfonction pour obtenir le chemin de ce répertoire.
6. Les répertoires répertoriés dans la PATHvariable d'environnement.

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

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

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

Mieux encore que la suggestion d'utilisation de Ran GetProcAddress, faites simplement l'appel à LoadLibraryavant tout appel aux DllImportfonctions (avec seulement un nom de fichier sans chemin) et ils utiliseront automatiquement le module chargé.

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 tas de fonctions P / Invoke-d. Collez le code de chargement dans un constructeur statique pour le type contenant les fonctions importées et tout fonctionnera correctement.

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

Une alternative qui peut vous aider à accomplir ce que je pense que vous essayez est d'utiliser le natif LoadLibraryvia P / Invoke, afin de charger un .dll à partir du chemin dont vous avez besoin, puis de l'utiliser GetProcAddresspour obtenir une référence à la fonction dont vous avez besoin à partir de ce .dll. Utilisez ensuite ces derniers pour créer un délégué que vous pouvez appeler.

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

ÉDITER

Voici un extrait de code qui fonctionne et 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);
    }
}

Remarque: je n'ai pas pris la peine de l'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.

Tant que vous connaissez le répertoire dans lequel vos bibliothèques C ++ peuvent être trouvées au moment de l'exécution, cela devrait être simple. Je vois clairement que c'est le cas dans votre code. Votre myDll.dllserait présent à l'intérieur du myLibFolderrépertoire dans le dossier temporaire de l'utilisateur actuel.

string str = Path.GetTempPath() + "..\\myLibFolder\\myDLL.dll"; 

Vous pouvez maintenant continuer à utiliser l'instruction DllImport en utilisant une chaîne const comme indiqué ci-dessous:

[DllImport("myDLL.dll", CallingConvention = CallingConvention.Cdecl)]
public static extern int DLLFunction(int Number1, int Number2);

Juste au moment de l'exécution avant d'appeler la DLLFunctionfonction (présente dans la bibliothèque C ++), ajoutez cette ligne de code dans le code C #:

string assemblyProbeDirectory = Path.GetTempPath() + "..\\myLibFolder\\myDLL.dll"; 
Directory.SetCurrentDirectory(assemblyProbeDirectory);

Cela demande simplement au CLR de rechercher les bibliothèques C ++ non gérées dans le chemin du répertoire que vous avez obtenu au moment de l'exécution de votre programme. Directory.SetCurrentDirectorycall définit le répertoire de travail actuel de l'application sur le répertoire spécifié. Si votre myDLL.dllest présent sur le chemin représenté par assemblyProbeDirectorychemin, il sera chargé et la fonction souhaitée sera appelée via p / invoke.

définir le chemin dll dans le fichier de configuration

<add key="dllPath" value="C:\Users\UserName\YourApp\myLibFolder\myDLL.dll" />

avant d'appeler la dll dans votre application, procédez comme suit

string dllPath= ConfigurationManager.AppSettings["dllPath"];    
   string appDirectory = Path.GetDirectoryName(dllPath);
   Directory.SetCurrentDirectory(appDirectory);

puis appelez la dll et vous pouvez utiliser comme ci-dessous

 [DllImport("myDLL.dll", CallingConvention = CallingConvention.Cdecl)]
public static extern int DLLFunction(int Number1, int Number2);

DllImport fonctionnera correctement sans le chemin complet spécifié tant que la dll se trouve quelque part sur le chemin du système. Vous pourrez peut-être ajouter temporairement le dossier de l'utilisateur au chemin.

Si tout échoue, placez simplement la DLL dans le windows\system32dossier. Le compilateur le trouvera. Spécifiez la DLL à partir de laquelle charger avec:, DllImport("user32.dll"...définissez EntryPoint = "my_unmanaged_function"pour importer la fonction non gérée souhaitée 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 d' DllImportexemples: http://msdn.microsoft.com/en-us/library/aa288468(v=vs.71).aspx