【发布时间】: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