【问题标题】:How to refactor namespaces in C# without affecting other projects?如何在 C# 中重构命名空间而不影响其他项目?
【发布时间】:2023-04-06 21:22:01
【问题描述】:

我有一个 Nuget 包,开始时我将大部分类和接口保留在基本命名空间中。随着时间的推移,默认命名空间已经变得杂乱无章,有许多彼此独立的类,我想将它们移到它们自己的命名空间中。例如,我想在不影响项目现有用户的情况下转换以下内容:

 namespace WebTestSuite
 {
     /// <summary>
     /// Public test result properties
     /// </summary>
     public interface ITestResult
     {
           /* Interface definition here */
     }
 }

收件人:

 namespace WebTestSuite.Results
 {
     /// <summary>
     /// Public test result properties
     /// </summary>
     public interface ITestResult
     {
           /* Interface definition here */
     }
 }

最终目标是允许我在我的项目中重构命名空间,当用户获得最新版本的包时,他们对 WebTestSuite.ITestResult 的引用将自动更新为 WebTestSuite.Results.ITestResult。

我想我可以编写一个迁移脚本,但不确定这是否有必要,或者是否有任何框架或任何可以使这更容易的东西。任何建议将不胜感激。

【问题讨论】:

  • 好一个 - 对出现的答案感兴趣。我从库/api 提供者那里看到的是 version 更改/升级 + 发行说明/通知/弃用,因此那些有依赖关系的人可以调整(或不调整)。如果它很关键(例如安全性),则会提供“升级”的时间表。
  • 可能不适用于您的情况,因为您提到了“命名/命名空间” - 但如果它是功能性,您可以将“遗留”代码视为“指针” - re:旧用户仍然调用相同的方法并期望相同的结果(无论您在内部如何处理)。
  • @EdSF 结合您的两个答案可能是个好主意。我可能会在新命名空间中创建一个重复的接口,然后更新原始接口以扩展新接口并将旧接口标记为已弃用。然后我可以在发行说明中记录它,并在将来的版本中删除不推荐使用的代码。不过这可能会变得一团糟,我不肯定它会起作用或可能产生影响。

标签: c# namespaces migration refactoring compatibility


【解决方案1】:

你可以试试 Resharper。它将以最小的努力提供对代码重构的大量控制。 使用 resharper,您可以关注 this guideline

【讨论】:

  • 我更担心其他用户项目会受到重构的影响。例如,如果我像上面那样重构我的代码,我的项目将被重构得很好,但是,引用了 WebTestSuite.ITestResult 接口的用户将无法再找到 ITestResult 接口。我的目标是通过某种方式将所有引用从 WebTestSuite.ITestResult 更新为 WebTestSuite.Results.ITestResult,而无需其他项目手动更新其引用。
  • 当您使用 resharper 更改 namchaespace 时,它​​会像往常一样更改其他类的引用。您无需手动更改它们。
  • @Fagun Resharper 仅更改它在 your 项目或解决方案中找到的引用(your 可以指代个人或团队,例如在源代码控制环境中)。 OP “有一个 NUGET 包”(由任何有依赖关系的人使用)
猜你喜欢
  • 2011-10-25
  • 2013-02-16
  • 1970-01-01
  • 2012-09-07
  • 1970-01-01
  • 2019-11-20
  • 2018-04-29
  • 1970-01-01
  • 2011-01-05
相关资源
最近更新 更多