I have attached one sample driver where I am trying to insert components into PMI Model Views.
I am working with SolidEdge ST8MP5.
Here the issue with this code is that after running this piece of code the other codes are not working as per the requirement.
Please check and let me know whether there is any issue with the written code?
P.S. I have tried releasing com objects at all places but still not able to understand what is wrong.
New to Solid Edge Customisation that's why not able to understand the exact issue.
@MartinBernhard Can You please check this. Thanks in advance.
Thanks for replying.
My question in this context is regarding releasing Com Objects which are created while using the mentioned codes. As per my understanding If I use API like this "occurence.ThisAsOccurence"then it will create a COM Object which I need to release after my work finished. In my case I have released some of the objects but I am not sure whether I have done complete releasing of objects or not.
This is just the driver I have provided I am using this code somewhere in between of my current code;that's why I have not used [STAThread]here.
Thanks and Regards,
At the lowest API level, COM objects are being created as you access them and they must be released. When automating COM APIs like Solid Edge via any .NET application, this gets a lot more complicated. When you access a COM object in .NET, a Runtime Callable Wrapper (RCW) is created and maintained by the .NET runtime. The RCW is responsible for ultimately releasing the underlying COM object. The problem is that .NET uses non-deterministic releasing of objects via Garbage Colection (GC). Since you do not have full control over the GC and it is non-deterministic, you cannot with 100% certainty guarantee that you have fully released any RCW that you touch. What is important to understand is that the RCWs live inside of an AppDomain. When your application starts, you get a "Default" AppDomain that all of your RCWs will reside in. When you application exists, the AppDomain is unloaded and any RCW living in the GC will be immediately freed.
If your application simply automates a single file then exits, there is not problem and calling Marshal.ReleaseComObject() is not necessary. Where it becomes an issue is when you're trying to work with multiple documents (opening & closing) during the lifetime of your application. You can call Document.Close() and Solid Edge will happily close the document but it may not be fully freed until either GC executes or your application exits. My solution to this problem that I personally use in production environments is to create an isolated AppDomain that I do all of my COM automation in. When the code completes, the AppDomain is automatically unloaded and all the RCWs are freed. The best example I have this concept is my OpenSave sample on GitHub. There seemingly is a lot of code to understand but if you will focus on the OpenSaveTask.cs and MainForm.cs, you should be able to get the gist of what I'm doing.
I wish there was an easier way to deal with .NET Interop but I am yet to be shown a better solution than what I just proposed.
p.s. During my presentation at the last Solid Edge University, I told the audience that I NEVER use Marshal.ReleaseComObject() or its variants in ANY of my code. Ever. After the collective gasps, I explained what I just said to you.