VC ++ nativo che utilizza un riferimento dll esterno (non di progetto) su come specificare il percorso alla dll

Question

Ho un progetto VC ++ nativo che usa una dll (che non è in un progetto). Ora, devo mettere la dll in uno il percorso di ricerca utilizzato da Windows per individuare una DLL " link

ma non voglio che la dll si trovi nell'esecuibile o corrente o nella directory di Windows o di sistema.

Quindi la mia unica opzione secondo questa è l'aggiunta del percorso alla variabile d'ambiente% PATH%.

C'è un altro modo?

Esiste un modo elegante per farlo (aggiungendo a PATH)? dovrei farlo al momento dell'installazione? dovrei preoccuparmi se lo sto facendo?

Answer 1

Riassumendo tutte le tecniche che ho trovato:

• Se usi un progetto gestito come progetto di avvio (che in realtà è il mio caso) usa la classe Enviroment

string temp = " myFullDirectoryPathToDll " ;; string temp2 = Environment.GetEnvironmentVariable (" PATH ") + " ;; " + temp; Environment.SetEnvironmentVariable (" PATH " ;, temp2);

questo, e penso che MSDN avrebbe dovuto sottolinearlo, cambia la variabile d'ambiente PATH solo in questo processo.

durante il debug in VS l'appPath non "funziona" usa le proprietà > debug- > environment e unisci le variabili d'ambiente link

• Se usi un nativo: fare collegamenti espliciti - sembra un grande lavoro per qualcosa di semplice, forse utilizzare la chiave del registro appPath durante la distribuzione link , nessuno ha avuto una risposta testata e dimostrata

Answer 2

Ecco alcuni suggerimenti:

• Potresti incorporare la dll come risorsa nel tuo eseguibile principale, quindi estrarla in una directory temporanea e caricarla dal loro usando LoadLibrary e quindi ottenere gli indirizzi delle funzioni rilevanti usando GetProcAddress.

• È possibile modificare il percorso di ricerca dei processi principali utilizzando SetDllDirectory () per includere il percorso della DLL. Ciò evita di dover apportare modifiche globali al sistema. E di nuovo usa LoadLibrary / GetProcAddress per risolvere gli indirizzi delle funzioni.

Answer 3

Se si sa dove è probabile che si trovi la DLL, è possibile provare a caricarla in fase di esecuzione utilizzando LoadLibrary (), quindi utilizzare GetProcAddress () per collegarsi alle funzioni che è necessario chiamare.

Answer 4

Non sarei felice se un'applicazione installata aggiungesse elementi casuali al mio PERCORSO globale. Poiché ciò influisce su tutte le applicazioni e può avere effetti collaterali negativi.

Quello che ho visto è avere uno script iniziale.
Lo script appare e si comporta come un'applicazione per l'utente (quindi è ancora doppio clock). Ma lo script imposta il percorso appropriato quindi avvia l'applicazione reale.

Answer 5

Se si utilizza DelayLoad, prima di chiamare qualsiasi funzione che causi il caricamento della dll, chiamare LoadLibrary. Questo sarà "prime" l'applicazione e non andrà a cercarla. Non è necessario GetProcAddress

Answer 6

Se si avvia da un collegamento di Windows, è possibile specificare il percorso della DLL in " Inizia in " posizione, specificando il nome completo e il percorso .exe in " Target " posizione.

Se ci sono DLL nella directory .exe che sono necessarie, Windows dovrebbe essere in grado di trovarle, perché credo che l'ordine di ricerca DLL di Windows cerchi prima nel percorso .exe (il la directory corrente è la quinta nell'elenco).

Ho usato il metodo LoadLibrary / GetProcAddress molte volte, cerco di evitarlo, in quanto comporta un po 'di lavoro extra - molti typedef e typecasts.

Answer 7

Il metodo di caricamento ritardato funziona sulla directory di lavoro nel momento in cui decide di chiamare LoadLibrary . Puoi usarlo a tuo vantaggio. Vedi http://msdn.microsoft.com/en- us / library / ms682586 (VS.85) .aspx per dettagli sull'ordine del percorso di ricerca.

Answer 8

Ho provato a impostare il percorso dell'applicazione nel registro di sistema. Funziona bene solo quando l'utente ha i diritti per accedere a regedit. E anche la modifica della variabile d'ambiente PATH. Il mio utente di prova non ha il diritto di amministratore per modificare la variabile.