我有一个程序，我想为其提供文件系统的抽象，以便始终针对通过给定工厂获得的给定实现执行用于读取文件、创建目录等的 IO 操作。
例如，您需要访问 MyLib.IO.File 而不是访问 System.IO.File，其中包含系统支持的文件的一组给定操作，并且实际实现将由 IOC 或单例工厂提供.
但是，不熟悉系统的人可能只是引用 System.IO 并开始直接处理文件系统中的文件。如果他的实际配置实例化了标准 System.IO 包装器，那么所有这些都将在他的机器上正常工作，但最终会在底层文件系统更改时中断。
有什么方法可以警告甚至更好地禁止在 VS 应用程序中使用某些命名空间，以便用户知道他不应该使用 .NET 框架的那部分，而是提供另一个库来获得该特定功能？
是的。有一种方法，它被称为清晰而简短的 API 文档。足够清晰以鼓励阅读，并且足够短以使开发人员对完成前放弃不感兴趣。
我的意思是强制使用你自己的库听起来不错，你有你的论点，但是模糊 BCL 库听起来很糟糕。
CASPOL 会很烦人，而且没有多少开发人员会阅读 API 文档，直到他们陷入困境。
发布一个构建脚本，使用程序集绑定日志查看器 (Fuslogvw.exe) 询问解决方案，以获取 System.IO 和其他不需要的引用。您也可以更进一步，使用反射甚至自省来查看 System.IO 的使用是否正常。恕我直言，此选项的侵入性最小，并提供了一些保证正确的 DLL/命名空间将用于发布。
不，那里没有。
编辑：
也许。可以使用System.IO.*代码访问安全性（或 .NET 4.x 中的任何替代品）来限制使用，但这意味着您需要完全控制应用程序（例如，您加载插件代码，而不是仅使用您的部件）。