有没有办法获取当前代码所在的程序集的路径?我不想要调用程序集的路径,只需要包含代码的路径 .
基本上我的单元测试需要读取一些相对于dll的xml测试文件 . 无论测试dll是从TestDriven.NET,MbUnit GUI还是其他东西运行,我都希望路径始终正确解析 .
Edit :人们似乎误解了我的要求 .
我的测试库位于说
C:\ projects \ myapplication \ daotests \ bin \ Debug \ daotests.dll
我想得到这条道路:
C:\ projects \ myapplication \ daotests \ bin \ Debug \
当我从MbUnit Gui运行时,到目前为止,这三个建议都让我失望:
-
Environment.CurrentDirectory
给出c:\ Program Files \ MbUnit -
System.Reflection.Assembly.GetAssembly(typeof(DaoTests)).Location
给出C:\ Documents and Settings \ george \ Local Settings \ Temp \ .... \ DaoTests.dll -
System.Reflection.Assembly.GetExecutingAssembly().Location
与前一个相同 .
27 回答
我使用它来获取Bin目录的路径:
你得到这个结果:
在Windows窗体应用程序中,您只需使用
Application.StartupPath
但对于DLL和控制台应用程序,代码更难记住......
您可以通过获取bin路径AppDomain.CurrentDomain.RelativeSearchPath
这很简单:
与John的答案相同,但是一种稍微冗长的扩展方法 .
现在你可以这样做:
或者如果您愿意:
这就是我提出的 . In between web projects, unit tests (nunit and resharper test runner) ;我发现这对我有用 .
我一直在寻找代码来检测构建的配置,
Debug/Release/CustomName
. 唉,#if DEBUG
. 所以如果有人可以改善那个!随意编辑和改进 .
Getting app folder . 对于web根,unittests有用,可以获取测试文件的文件夹 .
Getting bin folder :用于使用反射执行程序集 . 如果由于构建属性而在那里复制文件 .
适用于MbUnit GUI .
当开发人员可以更改代码以包含所需的代码段时,所有建议的答案都有效,但如果您想在不更改任何代码的情况下执行此操作,则可以使用Process Explorer .
它将列出系统上所有正在执行的dll,您可能需要确定正在运行的应用程序的进程ID,但这通常不会太困难 .
我已经写了一个完整的描述,如何为II内部的dll做这个 - http://nodogmablog.bryanhogan.net/2016/09/locating-and-checking-an-executing-dll-on-a-running-web-server/
据我所知,大多数其他答案都有一些问题 .
为disk-based (as opposed to web-based), non-GACed assembly执行此操作的正确方法是使用当前正在执行的程序集的
CodeBase
属性 .这将返回一个URL(
file://
) . 而不是乱用string manipulation或UnescapeDataString,这可以通过利用Uri
的LocalPath
属性进行最小的转换 .我已经定义了以下属性,因为我们经常在单元测试中使用它 .
Assembly.Location
属性有时会在使用NUnit(其中程序集从临时文件夹运行)时给出一些有趣的结果,所以我更喜欢使用CodeBase
,它以URI格式提供路径,然后UriBuild.UnescapeDataString
在开头删除File://
,GetDirectoryName
更改它到正常的Windows格式 .这应该工作:
我使用它来部署DLL文件库以及一些配置文件(这是使用DLL文件中的log4net) .
我一直在使用Assembly.CodeBase而不是Location:
它's been working, but I' m不再确定它是100%正确的 . http://blogs.msdn.com/suzcook/archive/2003/06/26/assembly-codebase-vs-assembly-location.aspx的页面说:
"The CodeBase is a URL to the place where the file was found, while the Location is the path where it was actually loaded. For example, if the assembly was downloaded from the internet, its CodeBase may start with " http:// ", but its Location may start with " C:\“ . 如果文件是阴影复制的,那么Location将是shadow copy dir中文件副本的路径 . 知道CodeBase不能保证是最好的 . 在GAC中为程序集设置 . 但是,总是会为从磁盘加载的程序集设置位置 . “
您可能希望使用CodeBase而不是Location .
这有帮助吗?
我发现我的解决方案足以检索位置 .
Web应用程序?
如果路径包含“#”符号,您将获得不正确的目录 . 所以我使用了John Sibly答案的修改,即UriBuilder.Path和UriBuilder.Fragment的组合:
这应该有效,除非程序集是阴影复制的:
这些年来,没有人真正提到这一个 . 我从令人敬畏的ApprovalTests project中学到了一个技巧 . 诀窍是您使用程序集中的调试信息来查找原始目录 .
This will not work in RELEASE mode, nor with optimizations enabled, nor on a machine different from the one it was compiled on.
但这会让你的路径 relative to the location of the source code file you call it from
我在过去的
NUnit
中有相同的行为 . 默认情况下NUnit
将程序集复制到临时目录中 . 您可以在NUnit
设置中更改此行为:也许
TestDriven.NET
和MbUnit
GUI具有相同的设置 .使用CodeBase和UNC Network共享时唯一有效的解决方案是:
它也适用于普通的URI .
那这个呢:
这是John Sibly代码的VB.NET端口 . Visual Basic不区分大小写,因此他的几个变量名称与类型名称冲突 .
这个怎么样 ...
然后只是砍掉你不需要的东西
我怀疑这里真正的问题是你的测试运行器正在将你的程序集复制到另一个位置 . 在运行时无法确定程序集的复制位置,但您可以翻转一个开关,告诉测试运行程序从何处运行程序集,而不是将其复制到影子目录 .
当然,对于每个测试跑步者来说,这种切换可能是不同的 .
您是否考虑将XML数据作为资源嵌入测试程序集中?
您存在的当前目录 .
如果您使用build复制.xml文件,您应该找到它 .
要么