理论上是否可以从 C# 访问任何库（又名 PInvoke 在幕后做什么）？
与许多地方一样，我的工作场所也有遗留代码和更现代的应用程序。 例如，我们有一个仍然使用 Microsoft Fortran77 编译器的服务器应用程序。 应用程序的较旧部分是为 Visual Studio 6 C 编译器编写的，最近出现了使用 VS .Net 2008 C++ 编写一些新库的情况。 程序/库有许多不同的机制来相互使用/通信，包括静态链接、共享内存（Windows 内存映射文件）、名称管道和 TCP 套接字。
如何阻止 C# 应用程序使用任何旧库（例如用过程语言编写的 Fortran77 库之一）？
如果我的 C# 应用程序理解 Fortan77 或 C 库的文件格式，并且能够找到它想要的过程调用，它是否可以编组托管对象、调用过程并解组结果？
如果我将 .so 库文件从 Linux 复制到 Windows，并且我的 C# 应用程序理解该文件格式，它可以调用该库中的函数吗？
我认为答案与初始化每个库/程序所需的各种 Fortran、C 等运行时有关。 如果是这样，那么从根本上讲，这些运行时是否与 CLR 大致相似（意识到它们在 CLR 的情况下具有不同的功能，例如内存管理等）？
编辑：
以另一种方式提出我的问题。 如果一个外星人顺便给了我一个二进制库文件和文件格式规范，我可以在 C# 中使用它吗？
Like a lot of places my workplace has legacy code floating around along with more modern applications. For example we have a server application that still uses the Microsoft Fortran77 compiler. The less old parts of the application are written for the Visual Studio 6 C compiler and lately there have been runours of writing some new libraries with VS .Net 2008 C++. The programs/libraries have a number of different mechanisms to consume/communicate each other including static linking, shared memory (Windows memory mapped files), name pipes and TCP sockets.
What's to stop a C# application from being able to use any old library such as one of the Fortran77 ones written in a procedural langauge?
If my C# application understood the file format of a Fortan77 or C library and was able to locate the procedure call it wanted could it marshal the managed objects across, call the procedure and unmarshal the result?
If I copied a .so library file from Linux to Windows and my C# application understood the file format could it call functions from that library?
I think the answers are to do with the various Fortran, C etc. runtimes that are needed to initialise each library/program. If that's so then at a fundamental level are those runtimes the broadly similar to the CLR (realising they have different features such as memory management etc. etc. in the CLR's case)?
Edit:
To put my question another way. If an alien dropped in and gave me a binary library file and a file format specification could I use it from C#?
如果你对这篇内容有疑问，欢迎到本站社区发帖提问 参与讨论，获取更多帮助，或者扫码二维码加入 Web 技术交流群。
绑定邮箱获取回复消息
由于您还没有绑定你的真实邮箱，如果其他用户或者作者回复了您的评论，将不能在第一时间通知您！
发布评论
评论（3）
如果 DLL 是有效的 DLL 并且导出的函数使用众所周知的调用约定，那么只要您正确获取 .NET 中的方法签名，即：正确的参数类型和返回类型，就不会有问题。 CLR 不（也不能）关心库是用什么语言编写的。
至于 Linux 共享库，如果你有库的源代码，应该可以使用 Cygwin 或 MiniGW 为 Windows 编译它们。
If the DLLs are valid DLLs and the functions exported use well-known calling conventions, then there should be no problem as long as you get the method signature in .NET right i.e: correct argument types and return type. CLR doesn't (and can't) care what language was the library written in.
As for the Linux shared libraries, if you have the sources of the libraries, it should be possible to compile them for windows using either Cygwin or MiniGW.
我不知道 Linux 中的 Fortan77 或 .so 库，但我知道您可以将 PInvoike 与 C 库一起使用来进行方法调用。 此外，您可能还想查看 C# 中共享内存应用程序的
unsafe关键字。 它允许您退出内存管理，这可能正是您所需要的。 命名管道和 TCP 套接字可以从 System.Net 命名空间完成。基本上你所说的一切都可以做到。 我不知道完成起来有多难或多容易，但您应该能够从 C# 应用程序访问所有这些本机应用程序。
I don't know about Fortan77 or .so library from Linux, but I do know that you can use PInvoike with C libraries for method calls. Also you may want to look at the
unsafekeyword in C# for the shared memory applications. It allows you to drop out of memory management, which may be what you need. Named Pipes and TCP sockets can be done from the System.Net namespace.Basically everything you have said can be done. I don't know how hard or easy it will be to accomplish, but you should be able to access all these native apps from your C# application.
您还可以创建 C++/CLI DLL（编译时的/CLR 选项），这将允许您以托管和非托管代码编写。 这使您可以执行在本机 C++ 中可以执行的任何操作，并且还可以与 .NET 组件交互。 我正在做这样的事情，通过让 C++/CLI dll 本质上位于旧的 C 应用程序与 C# DLL 之间来桥接它们。
You can also create a C++/CLI DLL (/CLR option when compiling) which will allow you to write both in managed and unmanaged code. This allows you to do just about anything you could do in native C++, and also interact with .NET components. I am doing something like this to bridge an old C application with a C# DLL by having the C++/CLI dll essentially sitting between them.