@Tushar presented at a SEU DEV DAY last year or the year before on App Domians to work around .NET GC issues.
Does anyone have the materials from this presentation?
or likewise, does anyone have a good overview on using App Domains?
Solved! Go to Solution.
yes, he is the one we can look up to.
What makes you think about App Domains, any interesting project that you are handling or contemplating.
I would be interested in learning too.
i'm reading thru an addin code that was developed by others and all throughout they have commets...
''' <remarks>SE will crash if we do not call GC.Collect() at the end of this event.</remarks>
so this made me recall the topic and want to learn more...
The remarks you are referring to are old and no longer relevant. That was back before Solid Edge took a more direct approach to dealing with .NET GC.
Regarding the AppDomain stuff, it came from me and is a rather complex topic for most but in certain situations, I contend it is absolutely necessary. Not everyone agrees with me but that's neither here nor there. This stems from the fact that in .NET, we have non-deterministic releasing of resource (GC) whereas VB6 & C++ have deterministic releasing. Within a given AppDomain, we cannot directly control GC, we can only suggest that GC run. It decides IF it will run and WHAT it will GC.
The best example that I have for when multiple AppDomains are necessary is any batch scenario where you have an out-of-process .EXE that is automating Solid Edge and needs to open\close many files. When your .EXE is executed, the .NET runtime allocates a default AppDomain and loads your application into it. Any COM resource you touch will get a corresponding RCW created that lives inside that AppDomain. So you open a file, process it and close it. Your intention is to release all of the COM resources that you accessed while processing the file but that's not exactly how GC works. So you get 50 files deep (for example) in processing and Solid Edge starts crashing. You get frustrated and blame Solid Edge and\or .NET and give up. The underlying issue is mostly just a misunderstanding of how GC & AppDomains works.
In order to have better control of the releasing of the RCW's, we can leverage the fact that RCW's live inside AppDomains. That is their scope. Since we understand that fact, we can simply create what I call "Isolated AppDomains" that do the dirty COM work and then throw them away when we're done (releasing the RCW's with it).
My attempt at making this as easy as possible, I created the IsolatedTask class in the SolidEdge.Community NuGet package. You can see an example of its usage in my OpenSave sample on GitHub.
There is a second scenario when I leverage AppDomain's and that's in my addin templates. Again, not everyone agreed with me that it was a good approach but it's how I do it so I shared it. Why did I feel it was necessary? Try writing an addin without my templates, load up Solid Edge which loads your addin. Now turn it off in Add-In Manager. Question: Do you think the RCW's your addin touched are fully released? Is your addin REALLY turned off? Answer: Nope
Thank you very much!
Yes, I recalled these scenario's pretty correctly... that's 1 plus...
I will take a look at the examples you cite for more reference...
But ultimately simply pass this info on to others that are much smarter than myself and speak in your native tongue (programmer-eeze)
In addition, look through my Samples on GitHub and try to find GC.Collect or Marshal.ReleaseComObject calls. Ok, you may find a couple of ReleaseComObject calls but those likely could be eliminated. My point: using the multiple AppDomain approach virtually eliminates the need to call GC.Collect or Marshal.ReleaseComObject. It is simply not possible to know or track all of the RCW's that get generated during code execution. Since we can't control that, we move toward what we can control. AppDomains and where certain bits of code execute. I'll be the 1st to admit that the extra layers and code sucks but at the end of the day, we just want our code to execute correctly without failing. If we don't like it, we can always use C++ ;-)
Glad I cam across this. I'm struggling with call rejections at the moment. I don't pretend to understand everything you've presented, but we have folks here that can figure it out. what I really want to know is why olemessage filter doesn't take care of these issues and neither does doidle. very frustrating.