防止其他开发人员在类中使用基方法
我有一个使用文件系统实体来操作数据的类。我们有几种专门设计的方法来（尝试）解决我们使用此方法面临的一些问题（文件锁定、不存在的文件等）。理想情况下，如果其他开发人员尝试直接通过 System.IO 而不是使用辅助方法访问文件系统，我希望能够发出警告。
这可能吗？我正在寻找的行为是有效地将 File.ReadAllText() 等方法标记为已过时，但仅限于该项目内（而不是解决方案范围内）。
我已经做了一些挖掘，看起来我唯一的选择是“告诉他们确保他们使用你的方法”。我希望有人能给我一个不同的、更有帮助的答案。 ：）
- 编辑 - 自定义 StyleCop 或 FxCop 规则的建议很好，但不幸的是在这种情况下不切实际（并非部门中的每个开发人员都使用这些出色的工具），并且执行文件访问的合法方法确实使用 System .IO。向合法方法添加“忽略”属性也是一个危险的想法。如果有人看到我如何“打破”自己的规则，他们可能会将该属性复制到他们自己的方法中。
I have a class that uses filesystem entities to manipulate data. We have several methods specifically designed to (attempt to) cope with some of the issues we face with this approach (file locking, non-existent files, etc.). Ideally I'd like to be able to issue a warning if another developer attempts access the filesystem directly via System.IO rather than using the helper methods.
Is this possible? The behaviour I'm looking for is to effectively mark methods such as File.ReadAllText() as if they were obsolete, but only within this project (NOT solution-wide).
I've done some digging around, and it looks like my only option is "tell them to make sure they use your methods". I'm hoping someone can give me a different, and more helpful answer. :)
--EDIT--
The suggestions of a custom StyleCop or FxCop rule are good, but unfortunately impractical in this scenario (not every developer in the department uses these excellent tools), and the legitimate methods that do the file access do use System.IO. Adding "ignore" attributes to the legit methods is a dangerous idea, too. If someone sees how I've "broken" my own rule, they'll likely copy the attribute to their own method.
如果你对这篇内容有疑问，欢迎到本站社区发帖提问 参与讨论，获取更多帮助，或者扫码二维码加入 Web 技术交流群。
绑定邮箱获取回复消息
由于您还没有绑定你的真实邮箱，如果其他用户或者作者回复了您的评论，将不能在第一时间通知您！
发布评论
评论（5）
使用静态分析工具（例如 StyleCop 或 FxCop) 与 规则 捕获“不要直接使用
System.IO”。然后将其集成为自动化构建过程的一部分，如果有人尝试直接使用 System.IO，则抛出该错误。没有人喜欢破坏构建。Use a static analysis tool (such as StyleCop or FxCop) with a rule that captures "Do not use
System.IOdirectly." Then integrate it as part of your automated build process and throw up if someone does try to useSystem.IOdirectly. No one likes to break the build.您可以为 FxCop/Visual Studio 代码分析编写自定义分析规则，并将其作为您的自动化构建。
You can write custom analysis rule for FxCop/Visual Studio Code Analysis and run these as part of your automated build.
唔。我自己没有尝试过，但是如何通过使用“隐藏”真正的 System.IO 的命名空间别名来强制人们使用您的自定义文件处理类。如果我没记错的话，这些是在项目级别应用的。
Hmm. Not tried this myself, but how about forcing people to use your custom file handling classes, by using a namespace alias that "hides" the genuine System.IO. If I remember rightly these are applied at a project level.
不确定这些建议是否有效，因为我从未这样做过，但有一些值得思考的地方：
这不是“企业模板”的设计目的吗？他们不允许您制作限制允许的项目引用的策略文件吗？
或者，虽然不是万无一失，但您是否可以向项目添加一个预构建事件，以便在引用 System.IO 时发出警告？
Not sure if either of these suggestions are valid as I've never done them, but some food for thought:
Isn't this what "Enterprise Templates" are designed for? Don't they allow you to craft a policy file that restricts the allowed project references?
Alternatively, while not foolproof, could you add a pre-build event to the project that throws a warning if System.IO is referenced?
您可以向源代码管理提交挂钩添加一些自定义功能吗？它不会发现现有的违规行为（如果有的话），除非这些文件被更改，但应该检测新的用途？
有什么好处吗？
Can you add some custom functionality to a source-control commit hook? It won't find existing violations (if there are any) unless those files are changed but should detect new uses?
Any good?