每个使用P / Invoke Windows API的人都知道一个很长的静态函数声明列表
[DllImport ("kernel32.dll",SetLastError = true,CharSet = CharSet.Auto)]
从WinNT.h这样的Windows头文件或从www.pinvoke.net这样的网站复制的结构的声明在我们的程序中也占有很大的位置。
为什么我们都必须为此花费时间？ 为什么微软不给我们一个简单的方法来包含一个类似于旧的非托pipe程序的行
#include <windows.h>
我们将有机会获得一个静态类Native与所有或最多的Windowsfunction和结构里面？
如何解决在C＃Windows服务处理泄漏
.net应用程序在Linux上运行吗？
.NET中的DLL可以使用不同的扩展名，例如MLL？
无法强制Webbrowser控件使用当前版本的IE呈现
检测HWND可见性更改
更新基于一些答案：
你会对自己诚实，.NET程序的哪些部分不在Windows下运行？ 5％？ 1％？ 如果你在.NET中使用WMI ， Process ， Registry或者ServiceProcess.ServiceBase类等，那么你的程序是如此的“ 独立于平台 ”，如果你不使用本地API，那么它就更加“ 兼容 ”？ 有Thread.ApartmentState到处都感觉到Windows？
SafeHandle或try {…} finally是必需的。 我会很高兴有这些forms的Native API的标准定义。
我知道在windows.h中的一些结构有不同的版本32/64或XP / Vista等。我认为这将足以有不同版本的本机结构，如MIB_IPADDRROW_XP和MIB_IPADDRROW_W2K或IMAGE_NT_HEADERS32和IMAGE_NT_HEADERS64 （请参阅窗口中的相同名称头）。
如果存在的话，应该使用托pipe的.NET类和方法。 可惜的是，Windows的一些最强大的function的实现太晚了，很多只能在非托pipe的世界中访问。 10年前的第一次有关.NET的Microsoft会议之一，我问了我的喜好内存映射文件 。 现在只有.NET 4已经实现了MemoryMappedFile类（请参阅http://blogs.msdn.com/salvapatuel/archive/2009/06/08/working-with-memory-mapped-files-in-net-4.aspx ）。 如果为了pipe理目的而编写实用程序，永久存在相同的问题。 例如，用CreateFile打开文件，用REG_OPTION_BACKUP_RESTORE或REG_OPTION_CREATE_LINK标记FILE_FLAG_BACKUP_SEMANTICS或REG_OPTION_CREATE_LINK 。 硬链接和连接 （请参阅http://msdn.microsoft.com/zh-cn/library/aa365006(v=VS.85).aspx ）是下一个示例。 再举一个例子：使用Job Objects而不是Process（参见http://msdn.microsoft.com/en-us/library/ms684161(VS.85).aspx和http://www.microsoft.com/msj/ 0399 / jobkernelobj / jobkernelobj.aspx ）。 如果你想启动一个进程并等待，直到这个进程，但也直到所有它的subprocess结束，工作是非常有用的。 可以使用CreateJobObject和AssignProcesstoJobObject ，然后使用TerminateJobObject或WaitHandle如.NET版本的（ WaitForSingleObject ）。
只有在.NET 4.0 system.intPtr和System.UIntPtr类支持Add和Subtract方法。
我可以继续这些例子，但是我希望你明白我的意思。 所以我想在.NET中编写一个程序，因为有很多优点，但是我可以做到这一点不总是没有使用本地API 。 而且，有时候客户对软件实现的语言也有要求，我select了所要求的方式。
更新2 ：微软在.NET 4.0中改进了与COM的互操作性，但与C-like Windows API不兼容。 我看到了一些使P / Invoke工作更容易的方法。 用什么方法可以做到这一点？ 我build议我看到三个方向：
一个是在.NET Windows API中声明所有（或者最重要）尚未完全实现的程序集。 这个集合可以只有（或几乎只有）具有静态函数和相应的类/结构的静态Native类的元数据。 这个程序集可以放在GAC中，每个人都可以使用它。 （我这样testing，效果很好。）
一个实现了一个片段的集合，声明和使用不同的本地Windows API的示例。
在www.codeplex.com上启动一个开源项目，在那里创build.NET类和扩展方法到一些最重要的本地Windows API，这些API还没有在.NET中实现。
我相信存在更多的方法来使开发人员更容易使用本机Windows API。 其他build议，欢迎。
如何在Windows上使用.Net构buildiphone应用程序？
Windows 8 Embedded中缺lessMSVCR120_CLR0400.dll
该键集没有定义
如何检测Windows 8操作系统使用C＃4.0？
是否可以禁用Windows中的特定智能卡硬件ID的自动智能卡minidriver安装？
我不知道MSFT为什么做出这个决定，但是这里有几个原因，我认为这个决定是正确的：
Windows SDK头文件（ windows.h等）广泛使用了基于目标Windows版本和体系结构等条件编译的条件编译，以确定哪些函数被声明以及如何布置数据结构。 在.NET语言中，任何一种都不是可能的，因为它不是针对Windows版本，而是针对框架版本，所生成的二进制文件能够在32位和64位体系结构上本地运行，跨多个版本的Windows
许多Windows API调用和数据结构不能通过P / Invoke充分表达。 立即想到的是DeviceIoControl 。 另一个是许多所谓的“可变长度”结构，包含数组中包含未知（在编译时）元素的数组
随着时间的推移，P / Invoke已经发展了，特别是在处理方式暴露的时候（早期版本的IntPtr ;后来的SafeHandle类）; 如果MSFT维护了大多数或全部Win32 API函数的单个静态类，它们也有义务保持与此类的以前版本的兼容性，但是自行锁定，然而P / Invoke本来是实现的
即使MSFT本身也不在框架内部维护一个Native类。 既然.NET Framework 3.5源代码已经可用，那么即使在我们应该用来代替P / Invoke的框架内，您也可以亲自看到P / Invoke是如何临时使用的。 例如，System.Net和System.IO具有自己的单独的P / Invoke声明。
.NET Framework和托管代码从一开始就被设计为一种构建Windows软件的新方法。 提供这种新的方式是多么愚蠢，同时又需要用旧的方式完成许多任务？
我认为这是一个广泛使用P / Invoke的人，例如IOCTL和卷级别的I / O操作。 我使用P / Invoke越多，我越讨厌它。 很难处理，容易出错，速度慢。 每次我使用P / Invoke，都是因为我已经用尽了所有其他选项。 如果您发现自己的问题解决方案需要大量的直接Windows API调用，那么您可能会：
a）在框架中缺少一些功能，将会做你想做的事情
b）正在采取错误的方法来解决这个问题，特别是如果你习惯了原生的Windows API，并且仍然用这些术语思考
c）应该在C ++ / CLI中编写低级代码，并为.NET代码公开更高级的接口
我确信这个想法超出了你的想法，但我认为应该有一个开源项目来做到这一点。 与其等待微软这样做，我们可以收集所有已经实际使用过P / Invoke日的人的知识，以便其他人不必重新发明轮子。
随着人们使用它们，继续收集API，需要它们。
任何志愿者？
版权声明：本文内容由互联网用户自发贡献，该文观点与技术仅代表作者本人。本站仅提供信息存储空间服务，不拥有所有权，不承担相关法律责任。如发现本站有涉嫌侵权/违法违规的内容， 请发送邮件至 [email protected] 举报，一经查实，本站将立刻删除。
