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