Я работаю над проектом, который использует кучу вызовов API WIN32 и требует некоторого небезопасного кода. С точки зрения передовой практики, должен ли я изолировать этот код в собственной DLL, скомпилированной с ключом /unsafe, сохраняя при этом безопасность основного приложения?
Другими словами. Есть ли причина не компилировать проект с ключом /unsafe? Есть ли потенциальные риски?
Сборка по определению является наименьшей единицей независимого версии распространяемого кода в .NET. Поэтому первый вопрос, который я бы себе задал: «Захочу ли я когда-нибудь сделать новую версию небезопасного кода и распространять ее независимо от моего приложения?»
Если да, то обязательно поместите этот код в свою сборку.
Если ответ отрицательный, то рассмотрите другие факторы. Например, в «классической» безопасности .NET вы можете иметь разные сборки, работающие с разными уровнями доверия в одном и том же домене приложения. (В современной CLR система намного проще, есть только полностью доверенный код, а все остальное работает на уровне доверия, предоставленном домену приложения.) Ваш код, который делает что-то небезопасное, должен быть полностью доверенным, но код, который просто вызывает ему можно было бы меньше доверять, если бы небезопасный код утверждал правильный набор разрешений.
Вы когда-нибудь оказывались в ситуации, когда вашему безопасному коду доверяют частично? Если это так, то обязательно поместите небезопасный код в его собственную сборку, а затем задокументируйте, что этой сборке следует полностью доверять.
Если вы не находитесь в таких ситуациях, я бы не стал помещать свой небезопасный код в свою собственную сборку.
Однако я был бы склонен писать приятную управляемую объектную модель поверх моего неуправляемого кода, а не просто выставлять необработанные вызовы win32. Например, на днях мне нужно было вызвать из C# некоторые API-интерфейсы Win32 для проверки строгих имен, и я только что набросал небольшую библиотеку, которая их красиво раскрывает, абстрагируя все неприятные детали взаимодействия в приватную внутренность класса.
