【问题标题】:What are the consequences of upgrading my .NET analyzer's target framework to .NET 5.0?将我的 .NET 分析器的目标框架升级到 .NET 5.0 会有什么后果?
【发布时间】:2021-07-14 12:14:35
【问题描述】:

我一直在编写一个分析器并使用 .NET Standard 2.0,以便可以针对 .NET Framework 4.7.2,我在分析器的 VSIX 版本中使用它。但是很快我选择放弃它,因为支持它没有好处。自从我想将受支持的框架升级到 .NET 5.0 之后,我也想在此过程中获得新的语言功能。

这将如何影响通过已发布的 NuGet 包将分析器包含到项目中的最终用户?我还应该继续支持旧的框架版本吗?

【问题讨论】:

    标签: c# .net roslyn roslyn-code-analysis


    【解决方案1】:

    您不能使用 .NET Standard 2.0 以外的任何东西,因为 VS 在 .Net Framework 4.* 下运行,csc Roslyn 编译器在 .Net 5/6 下运行。共同点是 .NET Standard 2.0,其他都行不通。

    VS 2022 仍然是这种情况,它仍然是一个 .Net Framework 应用程序,唯一的区别是它现在是一个 64 位进程,这意味着您的分析器需要Any CPU 才能在两者中工作。

    【讨论】:

    • 我注意到有一些关于在 VS 中使用 .NET 5.0 分析器的选项,它们不会在项目/解决方案的编译期间运行吗? VS 本身可能无法做到这一点,但编译器进程 (csc) 应该发出分析器生成的任何诊断信息,因为它在 .NET 5.0/6.0 中运行。
    • 分析器在VS中打开文件、输入或编译时运行,因此分析器需要VS自己加载。 csc 如果你手动运行它们也会单独运行它们,但是 VS 根本不使用 csc,它直接挂钩到 Roslyn 库和所有链接的分析器。
    • 那么这就解释了为什么有些分析结果在你编译项目之前没有实时显示在 VS 中,比如始终警告字段为空。
    • @Blindy 你知道为什么 VS2022 还在过时的 .NET Framework 上运行吗?我认为在这里我们有充分的理由一劳永逸地摆脱它。
    • 我想这是因为需要将数千个 dll 中的每一个都移至 .net5 的工作。我认为他们专注于在 2022 年将其打造为 64 位,下一个大版本将与现代 .Net 一起发布。
    猜你喜欢
    • 2018-03-21
    • 1970-01-01
    • 1970-01-01
    • 2010-09-27
    • 1970-01-01
    • 1970-01-01
    • 2010-09-08
    • 1970-01-01
    • 1970-01-01
    相关资源
    最近更新 更多