用于在编译时删除未使用的命令行工具或 dotnet 工具

Posted 2023-04-12

【中文标题】用于在编译时删除未使用的命令行工具或 dotnet 工具

【英文标题】：Command line tool or dotnet tool to remove unused using in compile time

【发布时间】：2021-10-26 06:03:46

【问题描述】：

有没有办法在编译时删除未使用的 using 语句？它可以是任何 cli 工具或 dotnet 工具。

原因如下： 我们有代码生成器，这个代码生成器会生成很多using，但在某些情况下需要使用，而有些则不需要。但是在生成时没有办法决定在以后的代码中使用哪个 using 和哪个不使用。

因此，如果我们有工具可以删除未使用的 using 语句，那就太好了。编辑器命令当然不起作用，因为当我们重建项目时，生成的文件将重新生成。因此，mechasnim 必须在生成器完成后在编译时运行。

我检查了dotnet-format 工具，但没有这个选项。

编辑 1： 输入文件有一个简单的示例，它是生成器的输入。

import valuedto.dml
import valuemodel.dml

service: SampleService

    controller: ValueController
    
        public:
        
            PublicValueDTO GetValue( string id );
        
        public:
        
            PrivateValueModel GetValuePrivate( string id );
        
    

如您所见，服务文件导入了两个不同的模型文件。一个 dml 文件包含公共 dto-s，另一个包含私有模型。

生成器以此为输入，生成大量代码：

客户端界面 http 客户端实现 控制器实现 客户端 dll 等等……

其中一个生成器只收集公共函数，并为第 3 方客户端创建一个程序集，以使用公共接口。但在这种情况下，很难决定必须使用哪些进口。在现实世界中，有mor import，import是reported，其他的import是递归的。

如果公共接口包含来自私有模型的using-s，则生成的代码不可编译

---

---

请将主要问题集中在您的回答中，而不是实际的实现中。因为它只是一个非常小的样本，而不是真正的样本（缺少版本、权限、路由、动词、多部分等......）

---

---

【参考方案1】：

免费的 jetbrains cli 工具可以进行代码清理。删除未使用的 using 指令是它可以做的事情之一。

https://www.jetbrains.com/help/resharper/ReSharper_Command_Line_Tools.html#install-and-use-resharper-command-line-tools-as-net-core-tools

【讨论】：

这就是我要找的！！谢谢你。赏金已添加！ THX

【参考方案2】：

你可以按 Ctrl+R , Ctrl+G (visual studio) 删除未使用的 using 并对工作文件中的命名空间进行排序。

我也一直在为此寻找工具。这应该是一个特殊的工具，不应该是编译阶段的一部分。

【讨论】：

亲爱的@Sourabh Rustagi，我当然知道编辑器工具，但它是在管道中的 linux 机器上编译的。整个编译过程自动完成，无需任何手动操作。

【参考方案3】：

由于下面的原因 #1，删除“编译期间”是没有意义的。我怀疑你的意思是“在 IDE 之外/不是手动”。

但是，你为什么要关心？

Using directives 不是 IL 工件，不会影响代码大小等 如果代码生成器由于额外的使用而生成不明确的代码，则无论如何都无法删除“未使用”，并且生成的代码无效，需要修复生成器。 通常，生成的代码应该被视为不可变和不透明的（不要查看它，除非可能是调试）。不要太在意它的美丽。

最后一点可以讨论。就个人而言，我确实关心格式良好且简洁的生成代码，如果仅仅是为了推理或在单步模式下调试它。但这将是生成器的工作。

话虽如此，有可用的 ReSharper 命令行工具可能能够在构建期间执行此操作（请注意“寻找工具”的问题关闭；-)）

再想一想：

但是在生成时没有办法决定使用哪个 using 后面的代码中没有用到。

我会挑战这一点。生成器应该知道它稍后生成/使用的确切类型。毕竟，您通常会先在内存中生成 AST 或类似的东西，然后再将其写入文件。如果不是，那么生成器的设计可能……过于简单化了？例如。首先脱口而出一堆可能的使用指令，然后是实际代码？如果您可以选择改进实际的生成器 - 无论如何这将是处理此类事情的正确位置 - 您应该就此提出一个具体问题并解释，为什么在您的情况下您认为它在生成实际文件之前无法知道事情。

【讨论】：

你说有可能，以后用的时候检测女巫，但是难度很大，而且要花很多功夫。我将编辑我的问题，以使其更清楚。下次请尽量回答问题，不提供替代方式，因为在后台有很多原因，但我想尽可能简化我的问题。