Como posso especificar um caminho [DllImport] em tempo de execução?

Na verdade, eu tenho uma DLL C ++ (funcionando) que quero importar para o meu projeto C # para chamar suas funções.

Ele funciona quando eu especifico o caminho completo para a DLL, assim:

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

O problema é que ele será um projeto instalável, portanto a pasta do usuário não será a mesma (por exemplo: pierre, paul, jack, mãe, pai, ...) dependendo do computador / sessão em que seria executado.

Então, eu gostaria que meu código fosse um pouco mais genérico, assim:

/* 
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);

O grande problema é que "DllImport" deseja um parâmetro "const string" para o diretório da DLL.

Então, minha pergunta é: O que poderia ser feito nesse caso?

Ao contrário das sugestões de algumas das outras respostas, o uso do DllImportatributo ainda é a abordagem correta.

Sinceramente, não entendo por que você não pode fazer como todos os outros no mundo e especificar um caminho relativo para sua DLL. Sim, o caminho em que seu aplicativo será instalado difere nos computadores de outras pessoas, mas isso é basicamente uma regra universal quando se trata de implantação. oDllImport mecanismo é projetado com isso em mente.

De fato, nem isso é o DllImportque lida com isso. São as regras nativas de carregamento da DLL do Win32 que governam as coisas, independentemente de você estar usando os úteis wrappers gerenciados (o empacotador P / Invoke apenas chama LoadLibrary). Essas regras são enumeradas em grandes detalhes aqui , mas as importantes são extraídas aqui:

Antes de o sistema procurar uma DLL, ele verifica o seguinte:

• Se uma DLL com o mesmo nome de módulo já estiver carregada na memória, o sistema utilizará a DLL carregada, independentemente do diretório em que esteja. O sistema não procura a DLL.
• Se a DLL estiver na lista de DLLs conhecidas para a versão do Windows em que o aplicativo está sendo executado, o sistema utilizará sua cópia da DLL conhecida (e as DLLs dependentes da DLL conhecida, se houver). O sistema não procura a DLL.

---

Se SafeDllSearchModeestiver ativado (o padrão), a ordem de pesquisa será a seguinte:

1. O diretório a partir do qual o aplicativo foi carregado.
2. O diretório do sistema. Use oGetSystemDirectory função para obter o caminho deste diretório.
3. O diretório do sistema de 16 bits. Não há função que obtenha o caminho desse diretório, mas ele é pesquisado.
4. O diretório do Windows. Use oGetWindowsDirectory função para obter o caminho deste diretório.
5. O diretório atual.
6. Os diretórios listados na PATHvariável de ambiente. Observe que isso não inclui o caminho por aplicativo especificado pela chave do Registro App Paths. A chave Caminhos do aplicativo não é usada ao calcular o caminho de pesquisa da DLL.

Portanto, a menos que você esteja nomeando sua DLL da mesma forma que uma DLL do sistema (o que você obviamente nunca deveria fazer, em nenhuma circunstância), a ordem de pesquisa padrão começará a procurar no diretório em que seu aplicativo foi carregado. Se você colocar a DLL lá durante a instalação, ela será encontrada. Todos os problemas complicados desaparecem se você apenas usar caminhos relativos.

Apenas escreva:

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

Mas se isso não faz o trabalho por qualquer motivo, e você precisa forçar o aplicativo a olhar em um diretório diferente para o DLL, você pode modificar o caminho de busca padrão usando a SetDllDirectoryfunção .
Observe que, conforme a documentação:

Após a chamada SetDllDirectory, o caminho de pesquisa DLL padrão é:

1. O diretório a partir do qual o aplicativo foi carregado.
2. O diretório especificado pelo lpPathNameparâmetro
3. O diretório do sistema. Use aGetSystemDirectory função para obter o caminho deste diretório.
4. O diretório do sistema de 16 bits. Não há função que obtenha o caminho desse diretório, mas ele é pesquisado.
5. O diretório do Windows. Use aGetWindowsDirectory função para obter o caminho deste diretório.
6. Os diretórios listados na PATHvariável de ambiente.

Portanto, desde que você chame essa função antes de chamar a função importada da DLL pela primeira vez, poderá modificar o caminho de pesquisa padrão usado para localizar DLLs. O benefício, é claro, é que você pode passar um valor dinâmico para essa função que é calculada em tempo de execução. Isso não é possível com o DllImportatributo; portanto, você ainda usará um caminho relativo (apenas o nome da DLL) e contará com a nova ordem de pesquisa para encontrá-lo.

Você terá que P / Invocar esta função. A declaração é assim:

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

Ainda melhor do que a sugestão de Ran de usar GetProcAddress, basta fazer a chamada LoadLibraryantes de qualquer chamada para as DllImportfunções (com apenas um nome de arquivo sem um caminho) e elas usarão o módulo carregado automaticamente.

Usei esse método para escolher, em tempo de execução, se é necessário carregar uma DLL nativa de 32 ou 64 bits sem precisar modificar várias funções de P / Invoke-d. Cole o código de carregamento em um construtor estático para o tipo que possui as funções importadas e tudo funcionará bem.

Se você precisar de um arquivo .dll que não esteja no caminho ou no local do aplicativo, não acho que você possa fazer exatamente isso, porque DllImporté um atributo, e os atributos são apenas metadados definidos em tipos, membros e outros elementos de linguagem.

Uma alternativa que pode ajudá-lo a realizar o que acho que está tentando é usar o nativo LoadLibrarypor meio do P / Invoke, para carregar uma .dll do caminho que você precisa e, em seguida, usar GetProcAddresspara obter uma referência à função que você precisa a partir desse .dll. Em seguida, use-os para criar um delegado que você pode chamar.

Para facilitar o uso, você pode definir esse delegado como um campo da sua classe, para que pareça chamar um método de membro.

EDITAR

Aqui está um trecho de código que funciona e mostra o que eu quis dizer.

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);
    }
}

Nota: Eu não me incomodei em usar FreeLibrary, portanto este código não está completo. Em um aplicativo real, você deve ter o cuidado de liberar os módulos carregados para evitar um vazamento de memória.

Desde que você saiba o diretório em que suas bibliotecas C ++ podem ser encontradas em tempo de execução, isso deve ser simples. Eu posso ver claramente que esse é o caso no seu código. Você myDll.dllestaria presente dentro do myLibFolderdiretório dentro da pasta temporária do usuário atual.

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

Agora você pode continuar usando a instrução DllImport usando uma string const, como mostrado abaixo:

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

Apenas em tempo de execução, antes de chamar a DLLFunctionfunção (presente na biblioteca C ++), adicione esta linha de código no código C #:

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

Isso simplesmente instrui o CLR a procurar as bibliotecas C ++ não gerenciadas no caminho do diretório que você obteve no tempo de execução do seu programa. Directory.SetCurrentDirectorychamada define o diretório de trabalho atual do aplicativo para o diretório especificado. Se você myDLL.dllestiver presente no caminho representado pelo assemblyProbeDirectorycaminho, ele será carregado e a função desejada será chamada através de p / invoke.

defina o caminho da DLL no arquivo de configuração

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

antes de chamar a dll no seu aplicativo, faça o seguinte

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

então chame a dll e você pode usar como abaixo

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

DllImport funcionará bem sem o caminho completo especificado, desde que a dll esteja localizada em algum lugar no caminho do sistema. Você pode adicionar temporariamente a pasta do usuário ao caminho.

Se tudo falhar, basta colocar a DLL na windows\system32pasta. O compilador irá encontrá-lo. Especifique a DLL para carregar de:, DllImport("user32.dll"...defina EntryPoint = "my_unmanaged_function"para importar a função não gerenciada desejada para o aplicativo 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);    
   }
}

Fonte e ainda mais DllImportexemplos: http://msdn.microsoft.com/en-us/library/aa288468(v=vs.71).aspx