0

I wrote a plugin in the form of a registered C# class library which has COM exposed methods.

Static objects in the class seem to survive between calls of Sub Main. Why is that? Can I prevent it and completely 'reload/restart' the library? (I did set the ctrPlugin object to Nothing)

From VBA, I instantiate classes and call methods from the C# library like this:

Option Explicit

Sub Main
  Dim ctrPlugin
    Set ctrPlugin = CreateObject("MyLibrary.MyExposedClassName")
    ctrPlugin.OpenWpfWindowMethod
    Set ctrPlugin = Nothing
  End If 
End Sub

The problem I'm having with it, is an occasional "Out of memory" error. Which is shown in the host application (an ERP system) after the c# method is completed. The error never shows while running a c# method, always after it completed. I never have these issues when I work with C# applications. Is there a difference between object lifetimes and garbage collecting processes between C# application and class library?

I already memory profiled my library in visual studio, and got rid of some memleaks. (One of which was caused by WPF bindings to objects which weren't DependencyObjects or inherited INotifyPropertyChanged)

Jasper
  • 444
  • 3
  • 19
  • 2
    Probably because the class library assembly is still loaded. – Robert Harvey Jan 28 '21 at 16:53
  • `Is there a difference between object lifetimes and garbage collecting processes between C# application and class library?` -- No, but VBA operates quite differently. – Robert Harvey Jan 28 '21 at 16:56
  • Don't use `static`s ? – Caius Jard Jan 28 '21 at 16:56
  • It's entirely possible that the `static` itself is causing the class library to remain loaded. The .NET Framework holds this `static` *in situ*; it [can't be garbage-collected](https://stackoverflow.com/questions/453023/are-static-fields-open-for-garbage-collection#:~:text=Static%20variables%20cannot%20be%20elected,is%20itself%20collected%20for%20garbage.). – Robert Harvey Jan 28 '21 at 16:59
  • @Caius, I did indeed stop using statics as much as possible. However the inner workings of libraries like log4net and WPF do seem to depend on it. Objects which seem to stay in memory are, for example, objects such as bindings to non-notifypropertychanged objects within in-method instantiated windows. Methods which have already returned their value and therefore must be finished. (Of course I already fixed these bindings, just mentioned these to demonstrate that objects stay in mem) – Jasper Jan 28 '21 at 17:02
  • 1
    It gets worse. Because VBA isn't part of the .NET Framework's ecosystem, there doesn't appear to be a way to unload such assemblies from VBA. Have you considered starting a new .NET process instead of creating a new object from VBA? When that process unloads, it will automatically unload any libraries it is using. – Robert Harvey Jan 28 '21 at 17:03
  • @RobertHarvey, I in fact have considered running a separate process. I've spent quite some time on this issue with my library already so I guess this post is my last effort before I'll have to admit defeat and concede to running a separate executable with command line parameters from the VBA. (Is there a nicer way to do this?) – Jasper Jan 28 '21 at 17:07
  • @RobertHarvey yeah the DLL assembly is com-visible, registered with regasm.exe by its installer – Jasper Jan 28 '21 at 17:14
  • Can you implement your `static` as a singleton instead? – Robert Harvey Jan 28 '21 at 17:16
  • 1
    (if you're running WPF machinery that contains statics, a separate process with some sort of inter-process communication would seem to be the better choice). – Robert Harvey Jan 28 '21 at 17:17
  • Yeah I agree. With the WPF and log4net libs alone there will be static objects in memory. – Jasper Jan 28 '21 at 18:14

0 Answers0