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