Come ottengo il percorso dell'assembly in cui si trova il codice?

C'è un modo per ottenere il percorso dell'assembly in cui risiede il codice corrente? Non voglio il percorso dell'assembly chiamante, ma solo quello contenente il codice.

Fondamentalmente il mio test unitario deve leggere alcuni file di test XML che si trovano relativamente alla DLL. Voglio che il percorso si risolva sempre correttamente indipendentemente dal fatto che la DLL di test sia eseguita da TestDriven.NET, dalla GUI MbUnit o da qualcos'altro.

Modifica : le persone sembrano fraintendere ciò che sto chiedendo.

La mia libreria di test si trova in dire

C: \ Projects \ MyApplication \ daotests \ bin \ Debug \ daotests.dll

e vorrei ottenere questo percorso:

C: \ projects \ MyApplication \ daotests \ bin \ Debug \

I tre suggerimenti finora mi mancano quando corro dalla MbUnit Gui:

• Environment.CurrentDirectory dà c: \ Programmi \ MbUnit

• System.Reflection.Assembly.GetAssembly(typeof(DaoTests)).Location fornisce C: \ Documents and Settings \ george \ Local Settings \ Temp \ .... \ DaoTests.dll

• System.Reflection.Assembly.GetExecutingAssembly().Location dà lo stesso del precedente.

Ho definito la seguente proprietà poiché la usiamo spesso nei test unitari.

public static string AssemblyDirectory
{
    get
    {
        string codeBase = Assembly.GetExecutingAssembly().CodeBase;
        UriBuilder uri = new UriBuilder(codeBase);
        string path = Uri.UnescapeDataString(uri.Path);
        return Path.GetDirectoryName(path);
    }
}

La Assembly.Locationproprietà a volte ti dà alcuni risultati divertenti quando si utilizza NUnit (dove gli assembly vengono eseguiti da una cartella temporanea), quindi preferisco usare quello CodeBaseche ti dà il percorso in formato URI, quindi UriBuild.UnescapeDataStringrimuove File://l'inizio e lo GetDirectoryNamecambia nel normale formato di Windows .

questo aiuta?

//get the full location of the assembly with DaoTests in it
string fullPath = System.Reflection.Assembly.GetAssembly(typeof(DaoTests)).Location;

//get the folder that's in
string theDirectory = Path.GetDirectoryName( fullPath );

È semplice come questo:

var dir = AppDomain.CurrentDomain.BaseDirectory;

Come la risposta di John, ma un metodo di estensione leggermente meno dettagliato.

public static string GetDirectoryPath(this Assembly assembly)
{
    string filePath = new Uri(assembly.CodeBase).LocalPath;
    return Path.GetDirectoryName(filePath);            
}

Ora puoi fare:

var localDir = Assembly.GetExecutingAssembly().GetDirectoryPath();

o se preferisci:

var localDir = typeof(DaoTests).Assembly.GetDirectoryPath();

L'unica soluzione che ha funzionato per me durante l'utilizzo di condivisioni di rete CodeBase e UNC era:

System.IO.Path.GetDirectoryName(new System.Uri(System.Reflection.Assembly.GetExecutingAssembly().CodeBase).LocalPath);

Funziona anche con URI normali.

Questo dovrebbe funzionare, a meno che l'assembly non sia copiato nell'ombra :

string path = System.Reflection.Assembly.GetExecutingAssembly().Location

Che dire di questo:

System.IO.Path.GetDirectoryName(System.Reflection.Assembly.GetExecutingAssembly().Location);

Sospetto che il vero problema qui sia che il test runner sta copiando l'assembly in una posizione diversa. In fase di runtime non c'è modo di dire da dove è stato copiato l'assembly, ma probabilmente è possibile ruotare un interruttore per dire al test runner di eseguire l'assembly da dove si trova e non copiarlo in una directory shadow.

Un simile interruttore è probabilmente diverso per ogni corridore di prova, ovviamente.

Hai preso in considerazione l'idea di incorporare i tuoi dati XML come risorse all'interno del tuo assieme di test?

AppDomain.CurrentDomain.BaseDirectory

funziona con la GUI di MbUnit.

Credo che questo funzionerebbe per qualsiasi tipo di applicazione:

AppDomain.CurrentDomain.RelativeSearchPath ?? AppDomain.CurrentDomain.BaseDirectory

Per quanto ne so, la maggior parte delle altre risposte presenta alcuni problemi.

Il modo corretto di eseguire questa operazione per un assembly basato su disco (anziché su web), non GACed è utilizzare l'assembly attualmente in esecuzioneCodeBase proprietà .

Questo restituisce un URL ( file://). Invece di scherzare con la manipolazione di stringhe o UnescapeDataString, questo può essere convertito con il minimo sforzo sfruttando la LocalPathproprietà di Uri.

var codeBaseUrl = Assembly.GetExecutingAssembly().CodeBase;
var filePathToCodeBase = new Uri(codeBaseUrl).LocalPath;
var directoryPath = Path.GetDirectoryName(filePathToCodeBase);

Cosa ne pensi di questo ...

string ThisdllDirectory = System.IO.Path.GetDirectoryName(System.Reflection.Assembly.GetExecutingAssembly().Location);

Quindi taglia via quello che non ti serve

var assembly = System.Reflection.Assembly.GetExecutingAssembly();
var assemblyPath = assembly.GetFiles()[0].Name;
var assemblyDir = System.IO.Path.GetDirectoryName(assemblyPath);

Ecco una porta VB.NET del codice di John Sibly. Visual Basic non fa distinzione tra maiuscole e minuscole, quindi un paio dei suoi nomi di variabili si scontrano con nomi di tipi.

Public Shared ReadOnly Property AssemblyDirectory() As String
    Get
        Dim codeBase As String = Assembly.GetExecutingAssembly().CodeBase
        Dim uriBuilder As New UriBuilder(codeBase)
        Dim assemblyPath As String = Uri.UnescapeDataString(uriBuilder.Path)
        Return Path.GetDirectoryName(assemblyPath)
    End Get
End Property

In tutti questi anni, nessuno ha mai menzionato questo. Un trucco che ho imparato dal fantastico progetto ApprovalTests . Il trucco è che si utilizzano le informazioni di debug nell'assembly per trovare la directory originale.

Questo non funzionerà in modalità RELEASE, né con le ottimizzazioni abilitate, né su una macchina diversa da quella su cui è stata compilata.

Ma questo ti porterà percorsi relativi alla posizione del file di codice sorgente da cui lo chiami

public static class PathUtilities
{
    public static string GetAdjacentFile(string relativePath)
    {
        return GetDirectoryForCaller(1) + relativePath;
    }
    public static string GetDirectoryForCaller()
    {
        return GetDirectoryForCaller(1);
    }


    public static string GetDirectoryForCaller(int callerStackDepth)
    {
        var stackFrame = new StackTrace(true).GetFrame(callerStackDepth + 1);
        return GetDirectoryForStackFrame(stackFrame);
    }

    public static string GetDirectoryForStackFrame(StackFrame stackFrame)
    {
        return new FileInfo(stackFrame.GetFileName()).Directory.FullName + Path.DirectorySeparatorChar;
    }
}

La directory corrente in cui esisti.

Environment.CurrentDirectory;  // This is the current directory of your application

Se copi il file .xml con build dovresti trovarlo.

o

System.Reflection.Assembly assembly = System.Reflection.Assembly.GetAssembly(typeof(SomeObject));

// The location of the Assembly
assembly.Location;

Sto usando Assembly.CodeBase invece di Location:

Assembly a;
a = Assembly.GetAssembly(typeof(DaoTests));
string s = a.CodeBase.ToUpper(); // file:///c:/path/name.dll
Assert.AreEqual(true, s.StartsWith("FILE://"), "CodeBase is " + s);
s = s.Substring(7, s.LastIndexOf('/') - 7); // 7 = "file://"
while (s.StartsWith("/")) {
    s = s.Substring(1, s.Length - 1);
}
s = s.Replace("/", "\\");

Funziona, ma non sono più sicuro che sia corretto al 100%. La pagina all'indirizzo http://blogs.msdn.com/suzcook/archive/2003/06/26/assembly-codebase-vs-assembly-location.aspx dice:

"CodeBase è un URL del luogo in cui è stato trovato il file, mentre Location è il percorso in cui è stato effettivamente caricato. Ad esempio, se l'assembly è stato scaricato da Internet, il CodeBase potrebbe iniziare con" http: // " , ma la sua posizione potrebbe iniziare con "C: \". Se il file è stato copiato in ombra, la posizione sarebbe il percorso della copia del file nella directory della copia shadow. È anche utile sapere che CodeBase non è garantito da impostare per gli assembly nel GAC. Tuttavia, la posizione verrà sempre impostata per gli assembly caricati dal disco. "

Si potrebbe voler usare Codebase al posto di Posizione.

È possibile ottenere il percorso bin da AppDomain.CurrentDomain.RelativeSearchPath

Tutte le risposte proposte funzionano quando lo sviluppatore può modificare il codice per includere lo snippet richiesto, ma se si desidera farlo senza modificare alcun codice, è possibile utilizzare Process Explorer.

Elencherà tutte le DLL in esecuzione sul sistema, potrebbe essere necessario determinare l'ID del processo dell'applicazione in esecuzione, ma di solito non è troppo difficile.

Ho scritto una descrizione completa di come farlo per una DLL all'interno di II - http://nodogmablog.bryanhogan.net/2016/09/locating-and-checking-an-executing-dll-on-a-running-web -server/

in un'app di Windows Form, puoi semplicemente usare Application.StartupPath

ma per le DLL e le app per console il codice è molto più difficile da ricordare ...

string slash = Path.DirectorySeparatorChar.ToString();
string root = Path.GetDirectoryName(System.Reflection.Assembly.GetExecutingAssembly().Location);

root += slash;
string settingsIni = root + "settings.ini"

string path = Path.GetDirectoryName(typeof(DaoTests).Module.FullyQualifiedName);

Otterrai una directory errata se un percorso contiene il simbolo '#'. Quindi uso una modifica della risposta John Sibly che è la combinazione UriBuilder.Path e UriBuilder.Fragment:

public static string AssemblyDirectory
{
    get
    {
        string codeBase = Assembly.GetExecutingAssembly().CodeBase;
        UriBuilder uri = new UriBuilder(codeBase);
        //modification of the John Sibly answer    
        string path = Uri.UnescapeDataString(uri.Path.Replace("/", "\\") + 
          uri.Fragment.Replace("/", "\\"));
        return Path.GetDirectoryName(path);
     }
}

Questo è quello che mi è venuto in mente. Tra progetti web, unit test (nunit e resharper test runner) ; Ho trovato che ha funzionato per me.

Sono stato alla ricerca di codice per rilevare quale configurazione della build è in, Debug/Release/CustomName. Ahimè, il #if DEBUG. Quindi se qualcuno può migliorarlo !

Sentiti libero di modificare e migliorare.

Ottenere la cartella dell'app . Utile per web root, unittest per ottenere la cartella dei file di test.

public static string AppPath
{
    get
    {
        DirectoryInfo appPath = new DirectoryInfo(AppDomain.CurrentDomain.BaseDirectory);

        while (appPath.FullName.Contains(@"\bin\", StringComparison.CurrentCultureIgnoreCase)
                || appPath.FullName.EndsWith(@"\bin", StringComparison.CurrentCultureIgnoreCase))
        {
            appPath = appPath.Parent;
        }
        return appPath.FullName;
    }
}

Ottenere cartella bin : utile per eseguire assiemi usando reflection. Se i file vengono copiati lì a causa delle proprietà di compilazione.

public static string BinPath
{
    get
    {
        string binPath = AppDomain.CurrentDomain.BaseDirectory;

        if (!binPath.Contains(@"\bin\", StringComparison.CurrentCultureIgnoreCase)
            && !binPath.EndsWith(@"\bin", StringComparison.CurrentCultureIgnoreCase))
        {
            binPath = Path.Combine(binPath, "bin");
            //-- Please improve this if there is a better way
            //-- Also note that apps like webapps do not have a debug or release folder. So we would just return bin.
#if DEBUG
            if (Directory.Exists(Path.Combine(binPath, "Debug"))) 
                        binPath = Path.Combine(binPath, "Debug");
#else
            if (Directory.Exists(Path.Combine(binPath, "Release"))) 
                        binPath = Path.Combine(binPath, "Release");
#endif
        }
            return binPath;
    }
}

Questo dovrebbe funzionare:

ExeConfigurationFileMap fileMap = new ExeConfigurationFileMap();
Assembly asm = Assembly.GetCallingAssembly();
String path = Path.GetDirectoryName(new Uri(asm.EscapedCodeBase).LocalPath);

string strLog4NetConfigPath = System.IO.Path.Combine(path, "log4net.config");

Sto usando questo per distribuire librerie di file DLL insieme ad alcuni file di configurazione (questo è per usare log4net dall'interno del file DLL).

Trovo la mia soluzione adeguata per il recupero della posizione.

var executingAssembly = new FileInfo((Assembly.GetExecutingAssembly().Location)).Directory.FullName;

Ho avuto lo stesso comportamento in NUnitpassato. Per impostazione predefinita, NUnitcopia l'assembly nella directory temporanea. È possibile modificare questo comportamento nelle NUnitimpostazioni:

Forse TestDriven.NETe la MbUnitGUI hanno le stesse impostazioni.

Lo uso per ottenere il percorso della directory bin:

var i = Environment.CurrentDirectory.LastIndexOf(@"\");
var path = Environment.CurrentDirectory.Substring(0,i); 

Ottieni questo risultato:

"c: \ users \ ricooley \ documenti \ visual studio 2010 \ Projects \ Windows_Test_Project \ Windows_Test_Project \ bin"

Applicazione web?

Server.MapPath("~/MyDir/MyFile.ext")