我正在开发一个使用大量 WIN32 API 调用并需要一些不安全代码的项目。从最佳实践的角度来看，我是否应该将此代码隔离在使用 /unsafe 开关编译的其自己的 DLL 中，同时保持主应用程序的安全？
换一种方式。有什么理由不使用 /unsafe 开关编译项目吗？是否存在潜在风险？
根据定义，程序集是 .NET 中可独立版本化、可重新分发的代码的最小单元。因此，我要问自己的第一个问题是“我是否想要制作不安全代码的新版本并独立于我的应用程序分发它？”
如果答案是肯定的，那么无论如何，将该代码放入其自己的程序集中。
如果答案是否定的，那么请考虑其他因素。例如，在“经典”.NET 安全性中，您可以在同一应用程序域中以不同的信任级别运行不同的程序集。 （在现代 CLR 中，系统要简单得多，只有完全受信任的代码，其他所有内容都在授予应用程序域的信任级别上运行。）执行不安全操作的代码需要完全受信任，但仅调用的代码如果不安全的代码声明了正确的权限集，那么它可能会不太受信任。
您是否会遇到安全代码部分受信任的情况？如果是这样，那么无论如何，将不安全的代码放入其自己的程序集中，然后记录该程序集必须是完全可信的。
如果您不处于这种情况，那么我不会倾向于将不安全的代码放在自己的程序集中。
然而，我倾向于在非托管代码之上编写一个令人愉快的托管对象模型，而不是简单地公开原始 win32 调用。例如，有一天，我需要从 C# 调用一些强名称验证 win32 api，我刚刚创建了一个小库，很好地暴露了它们，将所有讨厌的互操作细节抽象到类的私有内部。
本文内容由网友自发贡献，版权归原作者所有，本站不承担相应法律责任。如您发现有涉嫌抄袭侵权的内容，请联系:hwhale#tublm.com(使用前将#替换为@)
