【问题标题】:How to parse source code fragment to System.Type如何将源代码片段解析为 System.Type
【发布时间】:2017-06-19 19:28:56
【问题描述】:

我有一组这样的字符串:

System.Int32
string
bool[]
List<MyType.MyNestedType>
Dictionary<MyType.MyEnum, List<object>>

我想测试这些字符串是否真的是有效类型的源代码表示。

我在一个不支持 Roslyn 的环境中,并且合并任何类型的解析器都很困难。这就是为什么我尝试使用 System.Type.GetType(string) 来解决这个问题。

但是,我走在一条肮脏的道路上,因为有很多边缘情况,我需要修改输入字符串以表示 AssemblyQualifiedString。例如。嵌套类型“MyType.MyNestedType”需要是“MyType+MyNestedType”,而且泛型也必须通过艰难的方式来解决。

是否有任何辅助方法可以在 .Net 2.0 中进行这种检查?我在 Unity 游戏引擎中工作,我们没有任何方法可以将我们的系统切换到具有可用解析器的更复杂的环境。

澄清 我公司在 Unity 中开发了一个代码生成系统,目前还不容易更改。我需要添加的一件事是能够获取在类中定义的字段列表(通过反射),然后根据它们是默认运行时程序集的一部分还是包含在 #if 中来分离它们UNITY_EDITOR 预处理器指令。当这些设置好后,我基本上想以不同的方式处理这些字段,但仅靠反射无法告诉我。因此,我决定打开我的脚本文件,查看此类定义区域的文本,然后检查其中是否声明了一个字段,如果为真,则将其放入单独的 FieldInfo[] 数组中。

固定不变的一件事是:所有脚本都将通过反射进行检查,并且 FieldInfo 的集合用于在其他地方生成新的源代码。我只需要将该集合分成单独的集合,用于运行时与编辑器程序集。

【问题讨论】:

    标签: c# parsing types gettype


    【解决方案1】:

    自定义类型和嵌套泛型可能是最难的部分。

    您不能只为所有自定义类型提供“完全限定名称的等效映射”或一些翻译规则吗? 我想你事先知道你会遇到什么。

    或者可能以相反的方式运行它:在启动时,扫描您的程序集并为其中包含的每个类,从@987654323 中的完全限定名称在您的输入文件中生成“应该出现的”等效名称@格式?

    对于其他程序集的自定义类型,请注意,您必须先调用Assembly.LoadFile() 或将第二个参数中的程序集名称传递给GetType() 才能加载它们。 例如,请参见此处:Resolve Type from Class Name in a Different Assembly

    也许这个答案也有帮助:How to parse C# generic type names?

    您能否详细说明项目的最终目的是什么?这个问题有点令人惊讶,尤其是对于一个统一项目。是不是因为您使用了某种奇怪的序列化来保持某些对象的状态?

    这个答案更多的是一些建议和问题,以帮助您澄清需求,而不是一个明确的答案,但它不能放在一个评论中,我认为它提供了有用的信息

    【讨论】:

    • 我不认为你的建议是现实的,你可以从例子中清楚地看到泛型是一种选择,它使目录的类型几乎无限。
    • @ISun > 但是很多都是完全没用和毫无意义的,通常你不会使用很多嵌套的泛型,即使是这样,大部分琐碎的东西都可以轻松解析(例如,dictionary,您只需要智能地拆分字符串部分即可提取 X 和 Y 名称等!)。最初的需求有点奇怪,所以解决方案可能不像“Call Type.GetType()”那么简单;)
    • 您完全正确,泛型类型的大多数排列都是无用的。但是你如何决定哪些有用,哪些没用呢?你能确保你认为无用的类型永远不会被请求吗?
    • @ISun 这就是为什么我还要求澄清需求。 OP 告诉他他与 Unity 合作,这是一个游戏/严肃游戏多用途引擎。他可能不是在编写代码编译器,他可能在“有限”的一组案例和情况下工作。由他来告诉我们细节!只要它们以明确的方式表达,我关于用泛型“解析”名称的评论仍然是相关的。我的答案的链接之一说明了这一点。
    • 感谢您迄今为止的意见。我已经为我的过去添加了更多信息。基本上,我只想知道,FieldInfo 列表中的字段(通过反射)是否在 #if UNITY_EDITOR 之类的预处理器指令中定义。我还没有找到任何 API 方法来查询这个,所以我决定通过我的源文件“解析”,寻找成员声明,​​然后检查它们是否在定义中。但到目前为止,它变得非常“丑陋”。
    猜你喜欢
    • 1970-01-01
    • 2023-04-02
    • 1970-01-01
    • 1970-01-01
    • 1970-01-01
    • 1970-01-01
    • 1970-01-01
    • 2018-05-17
    • 2011-07-26
    相关资源
    最近更新 更多