我有一个使用文件系统实体来操作数据的类。我们有几种专门设计用于（尝试）处理我们使用此方法遇到的一些问题的方法（文件锁定，不存在的文件等）。理想情况下，如果其他开发人员尝试直接通过System.IO访问文件系统而不是使用帮助程序方法，我希望能够发出警告。
这可能吗？我正在寻找的行为是有效地标记File.ReadAllText（）等方法，就像它们已经过时一样，但仅限于此项目（非解决方案范围内）。
我已经做了一些挖掘，看起来我唯一的选择是“告诉他们确保他们使用你的方法”。我希望有人可以给我一个不同的，更有帮助的答案。 ：）
- EDIT-- 自定义StyleCop或FxCop规则的建议是好的，但遗憾的是在这种情况下不是不切实际的（并非部门中的每个开发人员都使用这些优秀的工具），并且执行文件访问的合法方法做使用系统.IO。将“忽略”属性添加到合法方法中也是一个危险的想法。如果有人看到我“破坏”了我自己的规则，他们可能会将属性复制到他们自己的方法中。
答案 0 :(得分：11)
使用静态分析工具（例如StyleCop或FxCop）和rule来捕获“不要直接使用System.IO”。然后将其作为自动构建过程的一部分进行集成，如果有人尝试直接使用System.IO，则会抛弃它。没有人喜欢破坏这个版本。
答案 1 :(得分：1)
您可以为FxCop / Visual Studio代码分析编写custom analysis rule并将其作为自动构建的一部分运行。
答案 2 :(得分：0)
嗯。我自己没有尝试过，但是如何强制人们使用自定义文件处理类，使用“隐藏”真正的System.IO的命名空间别名。如果我没记错的话，这些都是在项目层面上应用的。
答案 3 :(得分：0)
不确定这些建议中的任何一个是否有效，因为我从未做过这些建议，但有些值得深思：
这不是“企业模板”的设计目的吗？它们是否允许您制作限制允许的项目引用的策略文件？
或者，虽然不是万无一失，但是如果引用System.IO，是否可以向项目中添加预生成事件以引发警告？
答案 4 :(得分：0)
您可以在源代码控制提交挂钩中添加一些自定义功能吗？它不会发现现有的违规（如果有的话），除非这些文件被更改但是应该检测到新的用途？
有什么好处吗？