我可以在 C# 中强制命名空间之间存在依赖关系吗
我可以限制特定命名空间中的类引用另一个特定命名空间中的类吗?两个命名空间都存在于同一个 .NET 程序集中。
示例:
namespace LegacyCode
{
class LegacyClass { ... }
}
namespace NewCode
{
class NewClass {...}
}
我不希望“NewCode”中的类能够引用“LegacyCode”中的类。
选项:
- 使用不同的程序集(使部署更困难,构建需要更长的时间)
- 使用像 NDetect 这样的工具(需要花钱!)
有人还有其他想法吗?
Can I restrict classes from a specific namespace from referencing classes in another specific namespace? Both namespaces exist in the same .NET assembly.
Example:
namespace LegacyCode
{
class LegacyClass { ... }
}
namespace NewCode
{
class NewClass {...}
}
I do not want classes from 'NewCode' to be able to reference classes in 'LegacyCode'.
Options:
- Have different assemblies (makes deployment harder, build takes longer)
- Using a tool like NDetect (costs money!)
Does anyone have any other ideas?
如果你对这篇内容有疑问,欢迎到本站社区发帖提问 参与讨论,获取更多帮助,或者扫码二维码加入 Web 技术交流群。
绑定邮箱获取回复消息
由于您还没有绑定你的真实邮箱,如果其他用户或者作者回复了您的评论,将不能在第一时间通知您!
发布评论
评论(5)
考虑使用过时属性标记这些类。这将导致任何本身未标记为“过时”的代码在编译期间生成警告。
在项目文件的“构建”选项卡上启用“将警告视为错误”设置,以导致此警告编译失败并出现错误。
编辑:
同意单独的程序集是促进淡出此代码的好策略。但这并不能阻止人们提及它。 obsolete 属性清楚地表明这段代码已经过时了。
编辑#2:
感谢 Dan Tao 指出 Obsolete 属性的重载构造函数。这意味着您可以强制执行某些内容的使用是否应被视为错误,而无需启用将警告视为错误。还有一个有用的选项来指定一条消息,指导用户解决方法。此消息在编译期间显示在错误/警告中。
Consider marking the classes with the Obsolete attribute. This will cause any code that isn't itself marked as 'Obsolete' to generate a warning during compilation.
Enable 'Treat warnings as errors' setting on the 'Build' tab of the project file to cause this warning to fail compilation with an error instead.
Edit:
Agree that seperate assemblies is a good strategy to facilitate fading out this code. This won't stop people referring to it though. The obsolete attribute makes it clear that this code is, um, obsolete.
Edit #2:
Thanks to Dan Tao for pointing out the overloaded constructor of the Obsolete attribute. This means you can enforce whether usage of a something should be treated as an error or not, without having to enable treat warnings as errors. There is also usefully the option to specify a message instructing the user of a workaround. This message is displayed during compilation in the error/warning.
记录设计、与人交谈、审查代码。不要试图用技术来解决人们的问题。 (不过,使用 NDetect 等工具,审查部分可以变得更加有效。)
如果您确实需要隔离设计更改,请选择单独的程序集:这就是预期的设计机制。但请确保您对接口和实现都有合理的版本控制方案。
Document the design, talk to people, review code. Don't try to throw technology at people problems. (The review part can become more effective with tools like NDetect, though.)
If you really need the isolation of design changes, go for separate assemblies: that's the intended design mechanism. But be sure you have a reasonable versioning scheme both for the interface and the implementation.
我认为单独的组件是唯一可能的解决方案。
I think separate assemblies are the only possible solution.
MS 使用 System.ObsoleteAttribute 属性来标记过时/遗留代码。此属性提供了一个创建编译器错误的因素。不过,如果没有太多遗留类,我会使用它。
MS uses the System.ObsoleteAttribute attribute to mark obsolete/legacy code. This attribute provides an ctor that creates a compiler error. Though, I'd use this if there are not too many legacy classes.
正如其他人所说,使用过时的属性(即使您必须重命名它)。
但更进一步。尽快删除任何不再使用的旧方法。这将防止以后有人使用它。您应该开始看到编译器警告,因为过时的属性会随着时间的推移而删除。
您甚至可以将其设为每天一小时的测试,以尽可能多地消除编译器警告...也许您会在下班后为每日获胜者买一杯啤酒(或软饮料...;)。
As others have said, use the obsolete attribute (Even if you have to rename it).
But go one step further. DELETE ANY Legacy method that is NO longer used as soon as possible. This will prevent someone from using it later. You should start to see the Compiler warnings due to the obsolete attributes to drop over time.
You might even make it a daily one hour long test to eliminate as many compiler warnings as you can... Maybe you pitch in to buy the daily winner a beer (or soft drink..;) after work.