在C#中查找已编译类的源文件 [英] Find source file of compiled class in c#

查看:179
本文介绍了在C#中查找已编译类的源文件的处理方法,对大家解决问题具有一定的参考价值,需要的朋友们下面随着小编来一起学习吧!

问题描述

我正在寻找在一组已编译.net程序集中的特定类的关联源文件.

I'm looking to find the associated source file(s) for specific class(es) in a set of compiled .net assemblies.

例如

MyAsm.Namespace.Foo  -> C:\Source\foo.cs
MyAsm.Namespace.Bar  -> C:\Source\Code\MoreCode\Common.cs
MyAsm.Namespace2.Bar -> C:\Source\Code\MoreCode\Common.cs
...

我具有程序集反射/使用标准的System.Reflection功能提取我感兴趣的Type信息.

I have the assembly reflection / extracting the Type information I'm interested in working using standard System.Reflection functionality.

我现在需要找到该类的原始.cs源文件.虽然我有一个蛮力解决方案来解决,但它的速度慢得令人无法接受.

I now need to find the originating .cs source file for the class. While I have a brute force solution in place as a workaround, its unacceptably slow.

我希望在大约5秒钟内完成整个过程.当前,反射提取部分需要不到1秒的时间,文件关联"需要几分钟的时间.我认为在4秒钟内扫描几MB并不没有道​​理.

I would hope to have the entire process complete in ~5 seconds. Currently, the reflection extraction portion takes less than 1 second, the 'file association' takes minutes. I don't think its unreasonable to scan a couple of MB in 4 seconds.

不幸的是,有一些警告,阻止了捷径.

Unfortunately there are a couple of caveats, which prevent shortcuts.

  • 我不知道文件名,所以我需要在每次运行时都执行dir / s *.cs,以枚举所有潜在的源文件.

  • I don't know the names of the files, so I need to do a dir / s *.cs every run, to enumerate all the potential source files.

类名并不总是与源文件匹配,它可以在可能的位置提示,但不能保证能正常工作.

The class name won't always match the source file, it can hint at a possible location, but its not guaranteed to work.

在某些情况下,同一文件中定义了多个类.

Multiple classes are defined in the same file in some cases.

大约有2万个.cs文件/63MB的源代码.

There are ~20k .cs files / 63MB of source.

我需要约10k个类/它们的文件之间的关联.

I need an association between ~10k of the classes / their files.

我不希望使用声明了文件名/类的方式逐步构建数据库,因为文件内容将更改,并且我将难以维护该数据库,等等(尽管我可能不得不如果其他所有方法都失败,请沿着这条路线走.)

I would prefer not to incrementally build a DB with the file name / classes declared in it, as the file contents will change, and I'll have the trouble of maintaining this DB etc (though I may have to go down this route if everything else fails).

此操作系统将在其上运行,不会启用Windows搜索/索引编制,因此也没有乐趣.

The OS's this will run on, wont have windows search/indexing enabled, so no joy there either.

我尝试过的事情:

  • 使用findstr.exe-太慢了

  • Using findstr.exe - much too slow

创建一个.net应用程序,将所有文件加载到内存中. -太慢,无法找到* .cs/加载所有 文件,一旦文件在内存中就可以快速进行扫描.

Creating a .net app, load all files into memory. - too slow to find *.cs / load all the files, fast to scan the files once they are in memory.

从所有较小的文件中创建一个较大的源文件,然后将其加载,扫描等-太慢了.只需几分钟即可构建文件,加载后速度很快.

Creating one large source file from all the smaller files, loading it, scanning etc - again, too slow. Takes minutes to build the file, fast once loaded.

读取PDB文件-我正在研究PDB2XML.exe,尽管它确实输出文件名并且运行很快,但我看不到如何将类与文件名关联.

Reading PDB files - I'm investigating PDB2XML.exe, and while it does output file names, and runs quickly, I cant see how to associate a class, with the file name.

那么,有人对PDB2XML有其他建议,魔术或经验吗?

So, does anyone have alternate suggestions, magic or some experience with PDB2XML?

推荐答案

使用PDB是IMHO的最佳选择.文件名(由 ISymbolDocument.URL )与序列点有关.序列点与方法(包括属性get/set)有关,而不与类有关.当然,.NET类源可以存储在多个文件中.因此,您必须浏览某个类型的所有成员(例如,使用反射)来确定所有相应的文件.

Using PDBs is your best option IMHO if the files are on the disk. The file names (represented by ISymbolDocument.URL) are related to sequence points. Sequence points are related to methods (including property get/set), not classes. Of course, a .NET class source can be stored in multiple files. So you'll have to browse all members of a type (using reflection for example) to determine all the corresponding files.

这篇关于在C#中查找已编译类的源文件的文章就介绍到这了,希望我们推荐的答案对大家有所帮助,也希望大家多多支持IT屋!

查看全文
登录 关闭
扫码关注1秒登录
发送“验证码”获取 | 15天全站免登陆