Re: Further Discussion
From: Sueffel (someone_at_somewhere.com)
Date: 03/31/04
- Next message: Sueffel: "Re: Installation of dotnetfx.exe - .net framework"
- Previous message: Brian Henry: "Re: How I can access the USB port using vb.net ?"
- Messages sorted by: [ date ] [ thread ]
Date: Tue, 30 Mar 2004 22:16:07 -0500
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
"Bill McCarthy <no spam>" <bill_mcc @ iprimus.com.au> wrote in message
news:OFLSUIhFEHA.712@tk2msftngp13.phx.gbl...
> 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
>
>
>
> "Sueffel" <someone@somewhere.com> wrote in message
> news:eft7PBhFEHA.3324@TK2MSFTNGP09.phx.gbl...
> > 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
> >
> >
>
>
- Next message: Sueffel: "Re: Installation of dotnetfx.exe - .net framework"
- Previous message: Brian Henry: "Re: How I can access the USB port using vb.net ?"
- Messages sorted by: [ date ] [ thread ]
Relevant Pages
|
