I'm creating custom actions to extend for my personal needs in C# (inheriting from StandardAction).
I'm currently experiencing some weird issues and would like to receive some feedback that can help me debug the problem.
I'm using VMware VIX API (COM dll) to invoke some actions against a VM server.
After my custom action completes, Finalbuilder marks it as "Completed" in green, however does not return to design mode (RUN button is still disabled).
I am guessing that some resources have not been fully released back (such as threads that were opened and not aborted).
My questions are:
1. How can i debug such an issue? when i test my actions in Visual Studio i do not experience any such behaviour.
2. What is the object lifetime model in finalbuilder? (when is my custom action class being instantiated and released, etc).
To further clarify the question, when, for example, is the constructor of my custom object is called? during runtime (when running the project) or before that?
I think these things have implications on the design of custom actions (when to create other objects such as COM objects, etc).
This sounds very odd. Does you Execute method actually return? Without seeing your source code it’s difficult to say what might be happening. Also, working with Com objects suggest that it may be a Com threading deadlock. Does the com object you are calling force any particular threading model? We coinitialize com in the main thread as Apartment threaded, and in the execution thread as MultiThreaded. This cannot change, it’s the only scenario we have found that works correctly for the com interop we do.
The action’s constructor will be call when the the project file is loaded, or when the action is added to the project.
It indeed looks like some sort of deadlock occuring.
I am not sure whether debugging it is the best option, can i somehow set my code to be execute in some other manner so this issue with COM will not occur ?
If you send your source to support at finalbuilder dot com we can try it here and see if we can figure out what the problem is. Without that it is very difficult to figure out a deadlock.