Рекомендации по организации кода .NET P/Invoke для Win32 API

Вы могли бы подумать, как это было сделано в среде .NET. Он неизменно объявляет статический класс (модуль в VB.NET) с именем NativeMethods, который содержит объявления P/Invoke. Вы могли бы быть более организованными, чем программисты Microsoft, здесь много повторяющихся объявлений. Разные команды работают над разными частями фреймворка.

Однако, если вы хотите поделиться этим со всеми проектами, вы должны объявить эти объявления Public вместо Friend. Что не очень хорошо, это должна быть деталь реализации. Я думаю, вы можете решить эту проблему, повторно используя файл исходного кода в каждом проекте, который в нем нуждается. Обычно это табу, но в данном случае, я думаю, все в порядке.

Я лично объявляю их по мере необходимости в файле исходного кода, которому они нужны, делая их частными. Это также очень помогает при лжи о типах аргументов, особенно для SendMessage.

Организуйте их в класс [Safe|Unsafe]NativeMethods. Отметьте класс как internal static. Если вам нужно предоставить их своим собственным сборкам, вы можете использовать InternalsVisibleTo, хотя было бы более уместно, если бы вы могли сгруппировать связанные в каждую сборку.

Каждый метод должен быть static - я, честно говоря, не знал, что вы можете даже пометить методы экземпляра DllImport.

В качестве первого шага я бы, вероятно, переместил все в сборку Core (если она у вас есть) или создал сборку Product.Native. Тогда вы сможете легко находить дубликаты и перекрытия и искать управляемые эквиваленты. Если ваши p/invokes в беспорядке, я не подозреваю, что у вас есть много способов наслоения других сборок, которые будут направлять вашу группировку.

Почему бы не создать отдельный файл с именем Win32.vb и внутри него логически сгруппировать пинвоки в отдельные пространства имен, например, пространство имен GDI может использовать все пинвоки GDI, пространство имен User32 может использовать все пинвоки, находящиеся в ядре User32, и так далее. .. сначала это может быть болезненно, но, по крайней мере, у вас будет централизованное пространство имен, содержащееся в этом файле? Посмотрите здесь, чтобы понять, что я имею в виду... Что вы думаете?

Являются ли ваши вызовы P/Invoke артефактом миграции с VB6? Я перенес 300 000 строк кода с VB6 на C# (Windows.Forms и System.EnterpriseServices) и исключил все, кроме нескольких вызовов P/Invokes — почти всегда есть управляемый эквивалент. Если вы занимаетесь рефакторингом, вы можете подумать о том, чтобы сделать что-то подобное. Полученный код должен быть проще в обслуживании.

Рекомендуемый способ — иметь класс NativeMethods для каждой сборки со всеми методами DllImported с внутренней видимостью. Таким образом, вы всегда знаете, где находится ваша импортированная функция, и избегаете повторяющихся объявлений.

Что я обычно пытаюсь сделать в этом случае, так это делать то, о чем вы говорите, создавать различные классы, статические или нет, которые обеспечивают функциональность, таким образом, ее можно повторно использовать по мере необходимости. В зависимости от характера вызовов я бы уклонился от реализации статического класса, но это будет зависеть от вашей конкретной реализации.

Расширение выше по запросу.

Учитывая характер P/Invoke, особенно если требуется несколько вызовов и они относятся к разным областям реализации, я считаю, что лучше группировать похожие элементы вместе, таким образом, вы не втягиваете много других беспорядков или других импортов DLL. когда не нужен.

Желание держаться подальше от статических методов связано с вызовами неуправляемых ресурсов и возможностью утечки памяти и т. д.