Выполнение длинной операции COM в C#, неспособной удалить ядовитое сообщение

Question

Я работаю над этим в течение недели и широко использую StackOverflow, но я не могу понять это.

Я пишу плагин на C# в продукте Autodesk, и я подключен (с маршалом) к другому 3D-приложению. Я сделал это для десятков других плагинов в прошлом без проблем.

Этот проект уникален. Из разных 3D-приложений я запускаю многолетнюю задачу (экспорт файлов) на большой модели. Время от времени занимает 1-260 минут.

Я получаю сообщение о яде: «Это действие не может быть выполнено, потому что« приложение »не отвечает. Выберите« Switch To »и ...» Технически я могу позволить клиенту просто нажать «Повторить», пока он не найдет приложение, но это нежелательно.

Первоначально я думал, что просто поставлю объект типа DoEvents, и он будет ждать завершения экспорта, но появляется ядовитое сообщение во время выполнения экспорта (это мое первое появление с ядовитыми сообщениями, м обучения). Затем я запустил эту операцию экспорта в фоновом потоке, протестировал ThreadPool и Thread. Однако я могу «запустить» службу, но она никогда не экспортирует модель из трехмерного приложения. Это просто работает вечно. (я удалил сообщение об ошибке с моей должности, потому что я не ищу для решения этой проблемы к югу, а то, что я собираюсь описать ниже)

Наконец, я попытался изменить NetMsmqBinding (Я тоже ничего об этом не знаю, но пытаюсь изучить его) в надежде, что он установит количество разрешенных попыток на большее число.

 System.TimeSpan TS = new System.TimeSpan(0, 30, 10); 
     System.TimeSpan TB = new System.TimeSpan(10, 0, 0); 
     NetMsmqBinding NMB = new NetMsmqBinding(); 
     NMB.MaxRetryCycles = 1000; 
     NMB.ReceiveRetryCount = 1000; 
     NMB.RetryCycleDelay = TS; 
     NMB.OpenTimeout = TB; 

Однако, независимо от того, что я могу изменить свои ценности NetMsmqBinding, я всегда получаю сообщение «Retry» в то же время. Я не должен писать это правильно. В других примерах я заметил XML-файл, содержащий эти значения, и я не знаю, что это за XML. И я действительно не хочу знать, потому что я предпочел бы запустить этот запуск в подключаемом модуле, а не иметь другой файл xml.

Я нахожу множество примеров того, как справиться с этим в гипотетическом (много консолей BS.Write), но ничего конкретного на самом деле не имеет конкретного примера, когда длительный COM-процесс прерывает основную утилиту C#.

Мне бы очень хотелось выяснить, как сбросить частоту повтора и циклы дольше, чтобы сообщения о яде не были представлены. Как я могу это сделать?

Здесь больше кода, чтобы дать некоторый контекст:

namespace Testing_V0 
{ 
    [PluginAttribute("Testing_V0R1", "ADSK", ToolTip = "Testing the plugin", DisplayName = "Testing the plugin")] 
    [AddInPluginAttribute(AddInLocation.AddIn)] 
    public class MyPlugin : AddInPlugin 
    { 
     public override int Execute(params string[] parameters) 
     { 
     System.TimeSpan TS = new System.TimeSpan(0, 30, 10); 
     System.TimeSpan TB = new System.TimeSpan(10, 0, 0); 
     NetMsmqBinding NMB = new NetMsmqBinding(); 
     NMB.MaxRetryCycles = 1000; 
     NMB.ReceiveRetryCount = 1000; 
     NMB.RetryCycleDelay = TS; 
     NMB.OpenTimeout = TB; 

     //NMB.ReceiveErrorHandling = ReceiveErrorHandling.Drop; 

    //Do the Export process here 
    } 
    } 
} 

Answer 1

Потому что у меня не было больше времени, чтобы работать над этим, я объясню, как я решил это. Вероятно, это не является целесообразным решением этой проблемы, но она имеет некоторые преимущества.

Непростой проект несколько месяцев назад, я сделал аналогичное приложение, в котором я экспортировал тот же формат файла, но из консольного приложения. Не было никаких проблем с консольным приложением, как эти проблемы, возникающие в dll из продукта AutoDesk.

Используя то, что я помню из экспорта консольного приложения, я создал новое небольшое консольное приложение exe, которое выполняло только экспорт файла. Затем я использовал команду System.IO.Process.Start (файл.exe, «arguments») в родительской dll для запуска исполняемого файла.

Это очень крутой способ избавиться от всплывающих сообщений, но есть некоторые преимущества. Исполняемый файл запускает экспорт, а C# DLL - продолжается. Это позволяет мне запускать простой цикл создания файла, пока файл не появится в каталоге, а затем продолжит работу. Я установил счетчик прогресса в C# DLL UI, и он дает клиенту хорошее стабильное считывание во время работы экспортера.

Как я уже сказал, это не идеально, но сейчас это работает для меня.