-1

I've been working on this for a week now and used StackOverflow extensively, but I can't figure this out.

I'm writing a plug-in in C# in an Autodesk product, and I'm connected (with Marshal) to a different 3D application. I've done this for dozens of other plug-ins in the past without issue.

This project is unique. From the different 3D application, I'm running a long-running task (file export) on a large model. It takes 1-60 minutes at times.

I get the poison message: "This action cannot be completed because the 'application' is not responding. Choose "Switch To" and..." Technically, I can let the client just click "Retry" until it finds the application, but that is undesirable.

I originally thought I would just put a DoEvents type thing, and it would wait for the export to finish, but the poison message appears while the export sub is running (this is my first occurrence with poison messages, so I'm learning). Then I looked into running this export operation on a background thread, testing ThreadPool and Thread operations. However, I can "start" the service, but it never exports the model from the different 3D application. It just runs forever. (I removed the error message from my original post because I'm not looking for a solution to that sub-problem, but rather what I'm about to describe below)

Lastly, I tried to modify the NetMsmqBinding (I know nothing about this either, but trying to learn it) in the hopes that it will set the number of allowed retries to a bigger number. 

        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;

However, no matter what I change my NetMsmqBinding values to, I always get the "retry" message at the same time. I must not be writing it correctly. In other examples, I noticed an xml file containing these values, and I don't know what that xml is. Nor do I really want to know, because I'd rather have this run in the plug-in, rather than have another xml file to deal with.

I'm finding lots of examples on how to deal with this in the hypothetical (lots of console.write BS), but nothing that actually has a concrete example where a long running COM process is interrupting the main C# utility.

I'd really like to figure out how to reset the retry frequency and cycles to last longer, so that the poison messages aren't presented. How can I do that?

Here is more code, to give some context:

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
     }
    }
}
Nicholas Pisca
  • 150
  • 1
  • 10
  • 1
    It is not a "poison message", just an MDA notification from the debugger. The ContextSwitchDeadlock Managed Debugger Assistant was designed to detect possible deadlock when a method call doesn't complete for 60 seconds. You already know what caused it, you made your program hang on purpose. Debug + Exceptions, expand the "Managed Debugging Exceptions" node. Untick the warning and you'll never have to look at it again. – Hans Passant Oct 24 '14 at 23:00
  • Thanks for that information, but I'm more interested in the netmsmqbinding issues at the end of the post. I don't think this is a duplicate of the post you mentioned. – Nicholas Pisca Oct 24 '14 at 23:26
  • Never ask two questions. You can re-ask the second one. – Hans Passant Oct 24 '14 at 23:31
  • I didn't ask two questions. I just explained all the steps that I went through so I didn't look like a douche just posting questions without investigating. To reiterate, i asked only one question it is this: "I'd really like to figure out how to reset the retry frequency and cycles to last longer, so that the poison messages aren't presented. How can I do that?" – Nicholas Pisca Oct 26 '14 at 05:37
  • Can you remove the "Duplicate" from the title and remove the link to the irrelevant solution? – Nicholas Pisca Oct 26 '14 at 05:39
  • Are you able to give more on how you are using your `NetMsmqBinding`. It's too difficult to help you figure out why your attempts at setting the retry frequency and cycles unless you show how it connects to your code. – Adrian Sanguineti Oct 26 '14 at 11:20
  • I've added more code, and this appears to change the values of the retry and other parameters (seen in watches), but it does not work. The export process still gets the poison message at the exact same time as the default settings. I would think 1000/1000/10 would be a very very very long time. – Nicholas Pisca Oct 27 '14 at 16:09
  • I was able to read more about the app.config.xml (I briefly mentioned in my original post), and I made a config xml. However, since this is a dll, I can't reference the exe (since this is run as a plug-in on an AutoDesk application). How can I get my dll to read my appconfig.xml? – Nicholas Pisca Oct 27 '14 at 19:22
  • I'm still looking for a solution to this. Any ideas? – Nicholas Pisca Nov 21 '14 at 20:14
  • How can I modify the netmsmqbinding methods? No matter what i change them to, nothing works. – Nicholas Pisca Dec 02 '14 at 23:04
  • Still looking for a solution? Anyone there? – Nicholas Pisca Feb 05 '15 at 17:55

1 Answers1

-1

Because I didn't have anymore time to work on this, I will explain how I resolved this. It is probably not an advisable way to resolve this issue, but it has some advantages.

On a non-related project a few months ago, I did a similar application where I exported the same file format, but from a console application. There was no issues with the console application like these issues arising in the dll from the AutoDesk product.

Using what I remembered from the console app export, I made a new small console app exe that did just the file export. Then I used System.IO.Process.Start(file.exe, "arguments") command in the parent dll to trigger the executable.

This is a very roundabout way to get rid of the pop up messages, but there are some advantages. The executable runs the export, while the C# DLL continues. This allows me to run a simple file-exists loop until the file appears in the directory, then continues on. I put a progress counter in the C# DLL UI, and it gives the client a nice stable read out while the exporter is running.

Like I said, this is not ideal, but this works for me, for now.

Nicholas Pisca
  • 150
  • 1
  • 10