我正在开发一个使用一堆 WIN32 API 调用并需要一些不安全代码的项目。从最佳实践的角度来看,我是否应该将此代码隔离在使用 /unsafe 开关编译的自己的 DLL 中,同时保持我的主应用程序安全?
换一种方式。是否有任何理由不使用 /unsafe 开关编译项目?有没有潜在的风险?
根据定义,程序集是 .NET 中可独立版本化、可再分发的代码的最小单元。因此,我要问自己的第一个问题是“我是否想要制作一个新版本的不安全代码并独立于我的应用程序分发它?”
如果答案是肯定的,那么无论如何,将该代码放在它自己的程序集中。
如果答案是否定的,那就考虑其他因素。例如,在“经典”.NET 安全中,您可以在同一应用域中以不同的信任级别运行不同的程序集。(在现代 CLR 中,系统要简单得多,只有完全受信任的代码,其他一切都在授予 appdomain 的信任级别上运行。)执行不安全操作的代码需要完全信任,但只是调用的代码如果不安全的代码断言了正确的权限集,则它可能不太受信任。
您是否会遇到安全代码部分受信任的情况?如果是这样,那么无论如何,将不安全的代码放在它自己的程序集中,然后记录这个程序集必须是完全信任的。
如果您不在那种情况下,那么我不会倾向于将我的不安全代码放在它自己的程序集中。
然而,我倾向于在我的非托管代码之上编写一个令人愉快的托管对象模型,而不是简单地公开原始的 win32 调用。例如,前几天我需要从 C# 中调用一些强名称验证 win32 api,我刚刚创建了一个小库,很好地公开了它们,将所有讨厌的互操作细节抽象到类的私有内部。