.net 导入DLL并在mono下运行应用程序

我使用以下代码导入winmm.dll

  MyUtils = public static class
  private
  protected
  public
    [DllImport("winmm.dll")]
    class method timeBeginPeriod(period:Integer):Integer; external;
    [DllImport("winmm.dll")]
    class method timeEndPeriod(period:Integer):Integer; external;
  end;

访问以下方法

MyUtils.timeBeginPeriod(1); //within winform load event
MyUtils.timeEndPeriod(1);   //within winform formclosing event

在Windows7下，它的工作效果与预期一样好。在Linux系统上的mono下，它也可以工作，但有一个例外。程序启动后，会弹出一个消息框，其中包含导入的dll的名称和OK按钮，如下所示。当我单击“确定”按钮时，我的程序将继续并按预期运行，不会出现任何错误

我仔细检查了我的程序，看看我是否有意在任何地方显示dll文件名，但我根本找不到类似的东西

编辑：更多信息，我需要使用winmm.dll的原因是我需要能够将线程睡眠粒度或默认延迟调整到大约1毫秒或接近1毫秒，而不是播放电影或音乐文件。我能够调整的唯一方法是通过这些方法timeBeginPeriod和timeEndPeriod。这样我的程序就可以通过串口成功地进行通信了。我的程序是每隔几毫秒就进行一次不间断的24/7/365天的来回对话。至关重要的是，它的沟通率达到或超过90%。导入dll文件后，我的程序在windows和linuxs上的通信是完美的，除了我在mono下的Linux上收到了那个恼人的messagebox

我以前从未见过或听说过这样的问题。有人知道为什么吗

---

谢谢，

我想大家对Mono的工作原理有些误解。WinMM.dll是Windows的本机二进制文件。Mono不会自动允许您导入winmm.dll并在linux环境中使用它。我猜您的程序没有正常运行，因为timeBeginPeriod和timeEndPeriod不会执行

除非您有Windows Multimedia Module for linux的某些端口，否则这将不起作用。通过System.Media.SoundPlayer进行单端口传输有什么方法可以从中获得所需的一切

Mono中的p/Invoke工作得很好，但每个平台仍然需要本地构建的二进制文件

有一篇文章是关于

你可能想看看LGPL

更新

问题在于Thread.sleep不是创建确定性行为的精确等待，无论分辨率如何。您不能使用Thread.sleep来同步粒度接近1ms的内容。JVM和.NET平台都可以获得接近1ms的精度，但这并不能保证。如果系统繁忙，您可能无法及时将上下文切换回线程，这意味着可能需要3毫秒、10毫秒，甚至30毫秒

有两件事你应该去寻找。Linux上的高分辨率计时器。以及如何创建实时系统。由于您几乎需要与ms进行通信，因此您需要研究实时系统，并找出如何创建一个确定的计时系统

大多数计时器只能使您获得接近30毫秒的分辨率

如果您在linux上找到了高分辨率的计时器，您仍然需要考虑上下文切换和时间推移，以弥补丢失的时间，或者甚至在亚毫秒级的处理过程中降低速度

我知道你声称它在Windows上工作得很好，但我试图解释它并不是真的按照你的想法工作。目前它还可以工作，但在该机器上可能会出现许多情况，这将导致您的系统不能以1ms的间隔处理数据，因此需要您在以后调试系统

---

有一些事情支持我：

我认为人们对Mono的工作原理有一些误解。WinMM.dll是Windows的本机二进制文件。Mono不会自动允许您导入winmm.dll并在linux环境中使用它。我猜您的程序没有正常运行，因为timeBeginPeriod和timeEndPeriod不会执行

除非您有Windows Multimedia Module for linux的某些端口，否则这将不起作用。通过System.Media.SoundPlayer进行单端口传输有什么方法可以从中获得所需的一切

Mono中的p/Invoke工作得很好，但每个平台仍然需要本地构建的二进制文件

有一篇文章是关于

你可能想看看LGPL

更新

问题在于Thread.sleep不是创建确定性行为的精确等待，无论分辨率如何。您不能使用Thread.sleep来同步粒度接近1ms的内容。JVM和.NET平台都可以获得接近1ms的精度，但这并不能保证。如果系统繁忙，您可能无法及时将上下文切换回线程，这意味着可能需要3毫秒、10毫秒，甚至30毫秒

有两件事你应该去寻找。Linux上的高分辨率计时器。以及如何创建实时系统。由于您几乎需要与ms进行通信，因此您需要研究实时系统，并找出如何创建一个确定的计时系统 大多数计时器只能使您获得接近30毫秒的分辨率

如果您在linux上找到了高分辨率的计时器，您仍然需要考虑上下文切换和时间推移，以弥补丢失的时间，或者甚至在亚毫秒级的处理过程中降低速度

我知道你声称它在Windows上工作得很好，但我试图解释它并不是真的按照你的想法工作。目前它还可以工作，但在该机器上可能会出现许多情况，这将导致您的系统不能以1ms的间隔处理数据，因此需要您在以后调试系统

---

有些事情支持我：

安德鲁·芬奈尔，我知道你在说什么。然而，我的程序确实有效，而且这些方法似乎如预期的那样有效。我无法使Thread.sleep粒度低于10ms以进行串行通信。一旦我能够做到上述，串行通信已经完美无缺，或者在Windows和Linux上100%可靠，除了上述问题，在我无法获得任何良好通信之前。我会研究你的建议。我希望人们能提供更多的信息，而不仅仅是继续投票这个目前对我没有帮助的答案。我需要缩短线程。睡眠延迟尽可能接近实际时间延迟。有没有办法用System.Media.SoundPlayer或LAME实现这一点？@digitalanalog更新了答案，让我们了解为什么关于使用Thread.sleep的答案不多。Andrew-我明白你的意思。自从升级到Windows7后，我的系统就出现了这个问题。即使对于我的应用程序的win32版本，我也必须这样做。我的程序向外部设备发送一个请求，它会在10毫秒内回复。这是程序准备阅读答案的充足时间。问题是这个。不管我说什么，睡眠时间总是大于10毫秒。如果是这样，我的程序将永远没有机会从设备读取回复。所以，它大部分时间都超时了。现在，它没有。是的，它每5000个周期就会超时一次。到目前为止，我的串行通信一直很稳定，我正试图摆脱那个恼人的消息框。安德鲁·芬内尔，我知道你在说什么。然而，我的程序确实有效，而且这些方法似乎如预期的那样有效。我无法使Thread.sleep粒度低于10ms以进行串行通信。一旦我能够做到上述，串行通信已经完美无缺，或者在Windows和Linux上100%可靠，除了上述问题，在我无法获得任何良好通信之前。我会研究你的建议。我希望人们能提供更多的信息，而不仅仅是继续投票这个目前对我没有帮助的答案。我需要缩短线程。睡眠延迟尽可能接近实际时间延迟。有没有办法用System.Media.SoundPlayer或LAME实现这一点？@digitalanalog更新了答案，让我们了解为什么关于使用Thread.sleep的答案不多。Andrew-我明白你的意思。自从升级到Windows7后，我的系统就出现了这个问题。即使对于我的应用程序的win32版本，我也必须这样做。我的程序向外部设备发送一个请求，它会在10毫秒内回复。这是程序准备阅读答案的充足时间。问题是这个。不管我说什么，睡眠时间总是大于10毫秒。如果是这样，我的程序将永远没有机会从设备读取回复。所以，它大部分时间都超时了。现在，它没有。没错，它每5000个周期就会超时一次。到目前为止，我的串行通信一直很稳定，我正试图摆脱那个恼人的消息框。