PInvoke图书馆

Question

我在网上看到很多使用PInvoke进行低级平台特定操作的示例，但每次都使用基本相同的方法原型。然后，查看Microsoft Reference Source，每个程序集都定义程序集所需的所有PInvoke函数，并始终将这些类标记为内部。我的问题是＆＃34;为什么？＆＃34;。

为什么，在我们尝试尽可能多地重用代码的世界中，我们是否必须为我们需要的每个项目重写CreateFile的签名？编写几个标准化的WinAPI库有什么问题？我认为存在一些问题，因为在大多数情况下它还没有完成，或者项目很快被放弃了。

Answer 1

将这些p / invoke签名标记为内部的程序集是这样做的，因为它们的目的是提供更高级别的抽象。并且在许多情况下是跨平台的（包括P / Invoke方法不存在的平台）。使它们成为内部确保调用者专注于可在任何地方工作的更高级别的抽象。

  

为什么，在我们尝试尽可能多地重用代码的世界中，我们是否必须为我们需要的每个项目重写CreateFile的签名？编写几个标准化的WinAPI库有什么问题？

这样的库可能会因元数据而变得相当大，并且库的大多数用户可能只需要它所包含的一小部分。但是，当我同情代码重用的愿望和p / invoke签名的可靠来源时，我开始P/Invoke library on GitHub意味着包含你想要的所有P / Invoke签名（至少来自Win32） ）。它有点像pinvoke.net，除了代码总是编译，你可以通过nuget包使用它。 我希望你发现它听起来像是你尝试做的事情对你有用。

Answer 2

内部标记是设计的，他们不希望这些声明暴露给外部组件。

.NET框架旨在包装Win32 API，因此用户不需要直接使用它们，但它们可以处理上面的抽象级别。如果他们公开下面的API，我认为它不是一个很好的抽象层设计。在几层之后，它将暴露下面的太多功能。

我认为问题出在封装和可重用性之间。封装确实降低了可重用性，但它提高了可维护性。