GC: Further Discussion

  • Thread starter Thread starter Sueffel
  • Start date Start date
S

Sueffel

Okay, I saw the post below about GarbageCollector, and have done some
research myself, and still have a concern/issue I'd like to address and
maybe solve.
In VB6, you set an object - Nothing, that sucker was gone. From what I
understand, it's no real difference than using malloc() in C++. how does
one do this in VB.NET?

Here's my concern about it. using the ClassByname functionionality,
I've made a plugin that strictly emulates Win32 API, actually extremely
closely. But, I did notice I couldn't overwrite this "Plugin" dll, or even
delete it as long as my program was running. Well, at first I thought it
was the nature of my plugin system, then, I looked more into GC, an tried
this. I have a couple of C++ libraries that export thier functions (API
Programming) and used .NET's P/Invoke and went through the whole thing, and
what did I find? I couldn't delete that little dll without killing the main
app. Well damn, isn't that half the point of API and how C++ plugins are
designed? Well, it seems that that system has been blown away.
now, back to my situation. Different parts of this application are
constantly changing, that's what the plugins are for, so the functionality
of the program is actually all these dll's and the application is nothing
but a loader/front-end for the plugins. now, before some get into an
uproar, this application is in noway standard, and really can't be
classified by one standard, but several, and it tooks is 3 weeks to identify
the problems and come up with this plugins system to solve it, and 2 hours
to explain it to a senior programmer who finally said that "Yes, I now see
what you are doing and why." So, granted it's not all that difficult for
the user to restart the app to get an update applied, but, what if they
didn't? What if the system, which already determines which plugin is
actually being used, and runs an update on the rest. Well, it does this by
copying them to a sub directory, then when the program has nagged the user
enough and he/she restarts it, it copies these files over. And that's the
bitch of it, no matter if I'm using this Plugin system, or Win32 API, I can
delete/copy all day over these things until they get used. Then it requires
a restart of the app.

So, in a short and sweet answer, can you declare an object, use
ClassByName function to use the object, then destroy it PERMINATLY? Force
GC, bypass GC even, hell, don't matter to me. This way, all the other dll's
get updated, and as soon as the user is done with the object, it's dll get's
an update right there, user never needs to know (Less questions). I can see
a need to be able to bypass the GC on an object level, even if not everyone
agree's with that, that's my porogative, and I like having choices. Even
bad choices should be allowed to be made, that's how llearning happens, and
it seperates the men from the boys.
Just thougth I'd throw my hand in the ring on this one, and it's
something I'd like to be able to difinitavly and affermitavly decide. EVERY
article I've read, and even some of the answers from here ahve never said
that's it's not possible to do this, just have went on to explain the GC,
what it is and how it works. Let's try to break it down for simpler people
and maybe even, with some detective work, definitavly say YES or NO and back
that answer up beyond all doubt.

Thank you and good night,

Just kidding on that last line, too much History Channel LOL

Thanks though definatly,
Sueffel
 
Hi Sueffel,

the problems you experienced are not really directly related to the GC, although
it is part and parcel of the way the runtime works. The issue is that .NET gets
the runtime type information from an assembly, and that assembly cannot be
unloaded, until the appdomain it was loaded in exits. There-in, lays the
solution to your problem, that is load the assembly in another appdomain, hence
allowing you to unload it at will. There have been numerous articles on this,
and I vaguely recall seeing one in msdn magazine about loading add-ins using
this technique.

HTh's

Thank you and good night, <bgd&r>

Bill
 
I will check into that route as a solution to my immediate problem. There
is an interesting point that my coworker brought up about security and the
GC. There's any number of scenerio's that you would not want an object
hanging around in memory. There has to be a way of using a malloc call, or
even the FreeMem API to get rid of that object in one fail swoop.

I have something to look at, thank you for that response Bill,
Sueffel
 
Back
Top