我有了一个消息处理程序，做一些FTP工作的端点。 由于FTP过程可能需要一些时间，我封装TransactionScopeOption.Suppress一个TransactionScope内ftp方法来防止事务超时异常。
这样做摆脱了超时异常，但处理程序被解雇了5次（重试次数设置为5在我的配置文件）
该文件被ftp'd确定，但他们只是ftp'd 5倍。
10或11分钟后的处理程序看上去像是被重新激发。
一些测试代码如下：
public void Handle(FtpMessage msg)
{
using (TransactionScope t = new TransactionScope(TransactionScopeOption.Suppress))
{
FtpFile(msg);
}
}
任何帮助将不胜感激。
谢谢。
我的猜测是，通过没有完成的范围内你造成的外部范围，由NSB创建，回滚。 这将导致NSB重试您FtpMessage。
尝试添加：t.Complete（）; 您的来电FtpFile之后看看是否会为你。
编辑：重读你的问题后，我意识到，这不会解决您的超时问题。 您是否尝试过增加超时？ （10分钟是默认包括maxValue在machine.config中所以不能将其设置为更高，而无需修改machine.config中）
如果这确实是不能交易的超时时间内完成的FTP通信，另一种方法是把它变成一个传奇。
佐贺将由FtpMessage启动，并在处理程序将异步启动FTP工作，无论是在另一个线程，或通过其他进程，或什么的，并存储在佐贺数据足够的信息，以便以后能够查找进度。
然后，它会从TimeoutManager然而，对于长期有道理请求暂停。 在接收到超时，它会查找状态佐贺数据，并检查正在进行的FTP工作。 如果它的建成，标志着传奇的完整的，如果不是，请求另一个超时。
或者，你可以有一个过程包装承载自己的公交车，但并没有任何自己的消息处理程序的FTP通信。 它可以接受通过命令行的FTP信息（包括要求端点），做它的工作，然后将消息发送回请求端点称它是完整的。 然后，你就不必等待超时与进程继续前进。
我建议配置该端点作为非事务，而不是试图抑制交易。 做到这一点，包括.IsTransactional（假）的初始化代码，如果自托管或通过实施IConfigureThisEndpoint，AsA_Client使用通用主机时。
