Como obtenho o caminho do assembly em que o código está?

Existe uma maneira de obter o caminho para o assembly no qual o código atual reside? Eu não quero o caminho do assembly de chamada, apenas aquele que contém o código.

Basicamente, meu teste de unidade precisa ler alguns arquivos de teste xml que estão localizados em relação à dll. Quero que o caminho seja sempre resolvido corretamente, independentemente de a dll de teste ser executada no TestDriven.NET, na GUI do MbUnit ou em qualquer outra coisa.

Edit : As pessoas parecem estar entendendo mal o que estou perguntando.

Minha biblioteca de teste está localizada em digamos

C: \ projetos \ myapplication \ daotests \ bin \ Debug \ daotests.dll

e eu gostaria de pegar esse caminho:

C: \ projetos \ myapplication \ daotests \ bin \ Debug \

Até agora, as três sugestões falham quando executo o MbUnit Gui:

• Environment.CurrentDirectory fornece c: \ Arquivos de programas \ MbUnit

• System.Reflection.Assembly.GetAssembly(typeof(DaoTests)).Location fornece C: \ Documents and Settings \ george \ Configurações locais \ Temp \ .... \ DaoTests.dll

• System.Reflection.Assembly.GetExecutingAssembly().Location dá o mesmo que o anterior.

Eu defini a propriedade a seguir, pois usamos isso frequentemente em testes de unidade.

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

A Assembly.Locationpropriedade, por vezes, dá-lhe alguns resultados engraçados quando usando NUnit (onde montagens executado a partir de uma pasta temporária), então eu prefiro usar CodeBaseo que lhe dá o caminho em formato URI, em seguida, UriBuild.UnescapeDataStringremove o File://no início, e GetDirectoryNamemuda-lo para o formato de janelas normais .

Isso ajuda?

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

É simples assim:

var dir = AppDomain.CurrentDomain.BaseDirectory;

O mesmo que a resposta de John, mas um método de extensão um pouco menos detalhado.

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

Agora você pode fazer:

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

ou se você preferir:

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

A única solução que funcionou para mim ao usar os compartilhamentos de rede CodeBase e UNC foi:

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

Também funciona com URIs normais.

Isso deve funcionar, a menos que a montagem seja copiada pela sombra :

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

Que tal isso:

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

Eu suspeito que o problema real aqui é que o executor de teste está copiando sua montagem para um local diferente. No tempo de execução, não há como dizer de onde a montagem foi copiada, mas você provavelmente pode ativar um botão para informar ao executor de teste que execute a montagem de onde está e não copiá-la para um diretório de sombra.

É provável que essa mudança seja diferente para cada corredor de teste, é claro.

Você já pensou em incorporar seus dados XML como recursos dentro do seu conjunto de teste?

AppDomain.CurrentDomain.BaseDirectory

funciona com a interface gráfica do usuário MbUnit.

Acredito que isso funcionaria para qualquer tipo de aplicativo:

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

Até onde eu sei, a maioria das outras respostas tem alguns problemas.

A maneira correta de fazer isso para um assembly não baseado em disco (baseado na Web) e não no GAC é usar o assembly atualmente em execuçãoCodeBase propriedade .

Isso retorna um URL ( file://). Em vez de mexer com a manipulação de strings ou UnescapeDataString, isso pode ser convertido com o mínimo de barulho, aproveitando a LocalPathpropriedade de Uri.

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

Que tal agora ...

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

Em seguida, basta cortar o que você não precisa

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

Aqui está uma porta VB.NET do código de John Sibly. O Visual Basic não diferencia maiúsculas de minúsculas; portanto, alguns de seus nomes de variáveis ​​estavam colidindo com nomes de tipos.

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

Em todos esses anos, ninguém mencionou esse. Um truque que aprendi com o incrível projeto ApprovalTests . O truque é que você use as informações de depuração no assembly para encontrar o diretório original.

Isso não funcionará no modo RELEASE, nem com as otimizações ativadas, nem em uma máquina diferente daquela em que foi compilada.

Mas você obterá caminhos relativos ao local do arquivo de código-fonte do qual você o chama

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

O diretório atual em que você existe.

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

Se você copiar o arquivo .xml com o build, deverá encontrá-lo.

ou

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

// The location of the Assembly
assembly.Location;

Estou usando Assembly.CodeBase em vez de 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("/", "\\");

Está funcionando, mas não tenho mais certeza de que está 100% correto. A página em http://blogs.msdn.com/suzcook/archive/2003/06/26/assembly-codebase-vs-assembly-location.aspx diz:

"O CodeBase é um URL para o local onde o arquivo foi encontrado, enquanto o Local é o caminho em que ele foi realmente carregado. Por exemplo, se o assembly foi baixado da Internet, seu CodeBase pode começar com" http: // " , mas o local pode começar com "C: \". Se o arquivo foi copiado na sombra, o local seria o caminho para a cópia do arquivo no diretório da cópia de sombra. Também é bom saber que o CodeBase não é garantido no entanto, o local sempre será definido para os assemblies carregados do disco. "

Você pode usar o CodeBase em vez de Local.

Você pode obter o caminho da lixeira por AppDomain.CurrentDomain.RelativeSearchPath

Todas as respostas propostas funcionam quando o desenvolvedor pode alterar o código para incluir o snippet necessário, mas se você quiser fazer isso sem alterar nenhum código, poderá usar o Process Explorer.

Ele listará todas as dlls em execução no sistema; talvez seja necessário determinar a identificação do processo do aplicativo em execução, mas isso geralmente não é muito difícil.

Eu escrevi uma descrição completa de como fazer isso para uma dll dentro do II - http://nodogmablog.bryanhogan.net/2016/09/locating-and-checking-an-executing-dll-on-a-running-web -servidor/

em um aplicativo de formulário do Windows, você pode simplesmente usar Application.StartupPath

mas para DLLs e aplicativos de console o código é muito mais difícil de lembrar ...

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

Você receberá um diretório incorreto se um caminho contiver o símbolo '#'. Então, eu uso uma modificação da resposta John Sibly que é a combinação 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);
     }
}

Isto é o que eu vim com. Entre os projetos da web, testes de unidade (executor de teste de unidade de nunit e resharper) ; Eu achei que isso funcionou para mim.

Eu tenho procurado por código para detectar em qual configuração está a compilação Debug/Release/CustomName,. Infelizmente, o #if DEBUG. Então, se alguém puder melhorar isso !

Sinta-se livre para editar e melhorar.

Obtendo a pasta do aplicativo . Útil para raízes da web, unittests para obter a pasta de arquivos de teste.

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

Obtendo a pasta bin : Útil para executar montagens usando reflexão. Se os arquivos forem copiados lá devido às propriedades de construção.

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

Isso deve funcionar:

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

Estou usando isso para implantar bibliotecas de arquivos DLL junto com algum arquivo de configuração (isso é para usar o log4net de dentro do arquivo DLL).

Acho minha solução adequada para a recuperação do local.

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

Eu tive o mesmo comportamento no NUnitpassado. Por padrão, NUnitcopia sua montagem no diretório temp. Você pode alterar esse comportamento nas NUnitconfigurações:

Talvez TestDriven.NETe a MbUnitGUI tenha as mesmas configurações.

Eu uso isso para obter o caminho para o diretório Bin:

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

Você obtém este resultado:

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

Aplicação web?

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