What has managed code achieved?

[Ben Voigt [C++ MVP]]

Re: What has managed code achieved?

I don't expect that we'll wind up agreeing on this, but I'm pretty

sure I can find a couple of million VB 6 developers who will tell you
that the need to do object cleanup was not a "myth" in VB 6.

So? Some objects need cleanup, and that hasn't changed from VB6 to VB.NET.
I could find a couple million developers who write buggy software in VB.NET
(or C#, or any other language hosted on the CLR) because people like you
tell them they don't need to worry about object lifetimes, it's all taken
care of magically by .NET. When actually nothing could be further from the
truth. At best they let leave objects rooted and cause memory leaks which
are easy to track down in .NET (Ok, that's an advantage, .NET makes it
easier to find where you're leaking). At worst they let the finalizer clean
their objects, creating hard-to-debug race conditions.

>
-Scott

[Juan T. Llibre]

Re: What has managed code achieved?

re:
!Of course with #2 you could actually kill the process that the web app
!was executing under (with Process Explorer) without needing to stop IIS

The process that the web app was executing under *was* the IIS process.
The only way to update/change a dll in classic ASP was to kill the IIS process.

re:
!although that method isn't very clean in a production environment

You can say that again.
In fact it didn't have a chance of working, never mind being "clean".





Juan T. Llibre, asp.net MVP
asp.net faq : http://asp.net.do/faq/
foros de asp.net, en español : http://asp.net.do/foros/
=============== =============== ========
"Paul Clement" <UseAdddressAtE ndofMessage@sws pectrum.comwrot e in message
news:muouf45o1p 6mthf984qkgigha 0t2dti4v2@4ax.c om...

On Tue, 21 Oct 2008 07:36:44 -0400, "Juan T. Llibre" <nomailreplies@ nowhere.comwrot e:
>
Hi Juan,
>
¤ re:
¤ !But have we traded one kind of DLL hell for another?
¤
¤ Not exactly.
¤
¤ Did you ever develop in Classic ASP ? "Dll Hell" was quite evident there.
¤
¤ 1. Different dll versions *prevented* your application from running in IIS.
¤ 2. Updating a dll meant manually stopping IIS, and all applications, so a single app could be updated
>
Of course with #2 you could actually kill the process that the web app was executing under (with
Process Explorer) without needing to stop IIS, although that method isn't very clean in a production
environment.
>
ASP always late bound to DLL libraries so it just used whatever was last registered. No binary
compatibility enforcement there.
>
>
Paul
~~~~
Microsoft MVP (Visual Basic)

[Ben Voigt [C++ MVP]]

Re: What has managed code achieved?

Contrary to your assertion, simply letting a variable fall out of

scope was not the same thing as setting that variable reference to
nothing before it did. This makes all object variables vulnerable to
memory leaks.

Don't know how I missed this fallacious claim.

Both of them do exactly the same thing, that is call Release on the object,
if any, previously referenced by the variable. Always. Even if you set the
variable to reference a different object instead of Nothing, the old one
gets its Release method called.

[Ben Voigt [C++ MVP]]

Re: What has managed code achieved?

Paul Clement wrote:

On Tue, 21 Oct 2008 07:36:44 -0400, "Juan T. Llibre"
<nomailreplies@ nowhere.comwrot e:
>
Hi Juan,
>
¤ re:
¤ !But have we traded one kind of DLL hell for another?
¤
¤ Not exactly.
¤
¤ Did you ever develop in Classic ASP ? "Dll Hell" was quite evident
there.
¤
¤ 1. Different dll versions *prevented* your application from running
in IIS.
¤ 2. Updating a dll meant manually stopping IIS, and all
applications, so a single app could be updated
>
Of course with #2 you could actually kill the process that the web
app was executing under (with Process Explorer) without needing to
stop IIS, although that method isn't very clean in a production
environment.

There was a convenient button for this in the IIS manager, to stop the
hosting process for just that app (if you selected isolated execution of
course).

>
ASP always late bound to DLL libraries so it just used whatever was
last registered. No binary compatibility enforcement there.
>
>
Paul
~~~~
Microsoft MVP (Visual Basic)

[Ben Voigt [C++ MVP]]

Re: What has managed code achieved?

Gregory A. Beamer (Cowboy) - MVP wrote:

Less Blue Screens by junior developers. ;-)

Blue screens result from kernel-mode bugs. Always. .NET doesn't change
anything in kernel mode.

>
Realistically, from my COM days, the biggest real world advantage is
not having to register everything and the pain associated with
registering development builds to properly test.
>
Of course, if you use MTS, you had the option of dropping the running
process and droppping a new COM DLL over the old DLL. But this was
thinking WAY outside the box. You also ended up having to add the
weight of MTS to your app. Not too bad with web apps, which already
had most of the weight. Not as exciting for other apps.
>
With .NET, however, you can do this without a kludge. So that is a
real world advantage.
>
>
*************** *************** **************

>Think outside the box! |

*************** *************** **************
"John" <info@nospam.in fovis.co.ukwrot e in message
news:%23A%23Bye kMJHA.3496@TK2M SFTNGP04.phx.gb l...

>Hi
>>
>What are the advantages actually achieved of managed code? I am not
>talking of theory but in reality.
>>
>Thanks
>>
>Regards

[Scott M.]

Re: What has managed code achieved?

¤ The fact remains, sloppy coding or not, that managing memory in VB 6 was

the
¤ responsibility of the developer and in .NET the CLR manages this for us
to a
¤ much larger degree.
>
In most instances that's true. That is, unless COM is involved, then all
bets are off.

And, that's all I've been trying to say.

[Scott M.]

Re: What has managed code achieved?

Inline...


"Wolfgang Enzinger" <weusenet@tempo raryforwarding. comwrote in message
news:3neuf4lciq no7sh27p7ss7m04 j06jktc4v@4ax.c om...

On Wed, 22 Oct 2008 10:31:18 -0400, "Juan T. Llibre" wrote:
>

>>re:
>>!I can't resist from quoting that all because that's one unique
>>collection of nonsense.
>>
>>Can you explain why ?

>
Well, what can I say ... it's all plain wrong, simply.

Oh! Well, thanks for that analysis.

>>>>Well, there we have our disagreement. In fact, it was an onerous task
>>>>in VB
>>>>6 to take care of object lifetime.

>
It's not, and never was. As soon as the last object reference is
released, the object gets distroyed.

That is not in dispute. The conversation is about how to make that happen
in VB 6 as opposed to .NET and the consequences of not doing it in both
environments.

>>>>That is a fact, not a myth. You may
>>>>have not had particular issues dealing with it, but the fact that VB 6
>>>>was
>>>>notorious for memory leaks

>
I honestly never heard about that in all those years.

Well, then you must be right because that in-depth rebuttal can't possibly
stand scritiny.

>>>>and the fact that simply not setting an object
>>>>reference to Nothing was most likely the culprit tell us this. This is
>>>>not
>>>>my opionion. VB 6 was well know for these issues.

>
If I don't need a particular object instance anymore then I'll set all
references to Nothing or let them run out of scope. If however I still
need it, then I don't. You can call that an "issue" or "memory leak".
I don't. I wonder how the system should know about my plans if I don't
state them?!

You've just made my point (the one that you said was wrong). In VB 6.0, you
had to state your intentions by either destroying your object references or
not. In .NET, you don't.

>>>>Contrary to your assertion, simply letting a variable fall out of scope
>>>>was
>>>>not the same thing as setting that variable reference to nothing before
>>>>it
>>>>did. This makes all object variables vulnerable to memory leaks.

>
Strange that I never noticed any difference in all those years. In
fact, by checking whether the Terminate event is executed I can assure
that there *is no difference*.

Again, "all your years" isn't an argument. What COM automation work have
you done that relates to this?

>>>>I don't expect that we'll wind up agreeing on this, but I'm pretty sure
>>>>I
>>>>can find a couple of million VB 6 developers who will tell you that the
>>>>need
>>>>to do object cleanup was not a "myth" in VB 6.

>
I'm pretty sure it will be hard to find *one*, except Scott, of
course. *g*
>
Wolfgang

Ask yourself why Microsoft would abandon reference counters in favor of
Garbage Collection and ask yourself if, perhaps, others with "years of
experience" have possible done things you haven't.

[Scott M.]

Re: What has managed code achieved?

That's not at all what I've said and your reply just indicates that you'd
rather have an argument than understand someting.

Did I ever say that anything was magic? Did I ever say that we don't worry
about object lifetimes?

No and no. That makes the rest of your diatribe moot.

The fact remains that in .NET, you should never have to explicitly set an
object reference to Nothing and doing so can in fact hurt application
performance.

-Scott

"Ben Voigt [C++ MVP]" <rbv@nospam.nos pamwrote in message
news:uPv6TGHNJH A.2044@TK2MSFTN GP04.phx.gbl...

>I don't expect that we'll wind up agreeing on this, but I'm pretty
>sure I can find a couple of million VB 6 developers who will tell you
>that the need to do object cleanup was not a "myth" in VB 6.

>
So? Some objects need cleanup, and that hasn't changed from VB6 to
VB.NET. I could find a couple million developers who write buggy software
in VB.NET (or C#, or any other language hosted on the CLR) because people
like you tell them they don't need to worry about object lifetimes, it's
all taken care of magically by .NET. When actually nothing could be
further from the truth. At best they let leave objects rooted and cause
memory leaks which are easy to track down in .NET (Ok, that's an
advantage, .NET makes it easier to find where you're leaking). At worst
they let the finalizer clean their objects, creating hard-to-debug race
conditions.
>

>>
>-Scott

>
>

[Tom Shelton]

Re: What has managed code achieved?

On 2008-10-22, Scott M. <s-mar@nospam.nosp amwrote:

Inline...
>
>
"Wolfgang Enzinger" <weusenet@tempo raryforwarding. comwrote in message
news:3neuf4lciq no7sh27p7ss7m04 j06jktc4v@4ax.c om...

>On Wed, 22 Oct 2008 10:31:18 -0400, "Juan T. Llibre" wrote:
>>

>>>re:
>>>!I can't resist from quoting that all because that's one unique
>>>collection of nonsense.
>>>
>>>Can you explain why ?

>>
>Well, what can I say ... it's all plain wrong, simply.

>
Oh! Well, thanks for that analysis.
>

>>>>>Well, there we have our disagreement. In fact, it was an onerous task
>>>>>in VB
>>>>>6 to take care of object lifetime.

>>
>It's not, and never was. As soon as the last object reference is
>released, the object gets distroyed.

>
That is not in dispute. The conversation is about how to make that happen
in VB 6 as opposed to .NET and the consequences of not doing it in both
environments.
>

The rules are pretty much the same, Scott.

>>>>>That is a fact, not a myth. You may
>>>>>have not had particular issues dealing with it, but the fact that VB 6
>>>>>was
>>>>>notoriou s for memory leaks

>>
>I honestly never heard about that in all those years.

>
Well, then you must be right because that in-depth rebuttal can't possibly
stand scritiny.
>

>>>>>and the fact that simply not setting an object
>>>>>referenc e to Nothing was most likely the culprit tell us this. This is
>>>>>not
>>>>>my opionion. VB 6 was well know for these issues.

>>
>If I don't need a particular object instance anymore then I'll set all
>references to Nothing or let them run out of scope. If however I still
>need it, then I don't. You can call that an "issue" or "memory leak".
>I don't. I wonder how the system should know about my plans if I don't
>state them?!

>
You've just made my point (the one that you said was wrong). In VB 6.0, you
had to state your intentions by either destroying your object references or
not. In .NET, you don't.
>

Your statement is not true - you have to state your intentions, in pretty much
the same way you did in VB6.

With a local value, you don't have to do anything in VB6, release will be
called as soon as the procedure ends and the object will be cleaned up. In
VB.NET, you don't have to do anything, because the reference will be cleared
as soon as the procedure ends - oops, wait, you don't have to do anything
unless that object holds on to unmanaged resources.... Now you have to make
sure you call dispose on the object, either explicitly or via a using
statement.

With module level values, then in both VB6 and VB.NET you must explicitly set
the object to nothing (or set it to a new reference) if you want the object to
go away before the program terminates. Oops, in VB.NET you might have to also
call dispose on that object.

I'm not sure where you are getting the impression that memory management is
easier in .NET? Like I've said it's actually a bit harder and requires you to
know a bit more about the object (is it disposable?).

>>>>>Contrary to your assertion, simply letting a variable fall out of scope
>>>>>was
>>>>>not the same thing as setting that variable reference to nothing before
>>>>>it
>>>>>did. This makes all object variables vulnerable to memory leaks.

>>
>Strange that I never noticed any difference in all those years. In
>fact, by checking whether the Terminate event is executed I can assure
>that there *is no difference*.

>
Again, "all your years" isn't an argument. What COM automation work have
you done that relates to this?
>

It is completely true. VB automatically does a release call on the object
when it leaves scope - which is what happens when you set an object to
nothing.

You know, it's very easy to test that if you don't believe me.

>>>>>I don't expect that we'll wind up agreeing on this, but I'm pretty sure
>>>>>I
>>>>>can find a couple of million VB 6 developers who will tell you that the
>>>>>need
>>>>>to do object cleanup was not a "myth" in VB 6.

>>
>I'm pretty sure it will be hard to find *one*, except Scott, of
>course. *g*
>>
>Wolfgang

>
Ask yourself why Microsoft would abandon reference counters in favor of
Garbage Collection and ask yourself if, perhaps, others with "years of
experience" have possible done things you haven't.

There is no doubt that GC is more efficient then reference counting. But, it
does not change the rules much for VB developers - in fact, memory management
is slightly more complex with vb.net because of the fact that objects now are
freed in a non-deterministic way. This becomes apparent when dealing with
precious unmanaged resources. In vb6 you could do all your cleanup in the
terminate event, and you knew that this would happen as soon as the last
reference was released - you don't have that guarentee in a managed world.
That's the whole purpose behind the dispose pattern that permates the .NET
universe.

--
Tom Shelton

[Ken Halter]

Re: What has managed code achieved?

"Scott M." <s-mar@nospam.nosp amwrote in message
news:ux3usIINJH A.3744@TK2MSFTN GP05.phx.gbl...

>
Again, "all your years" isn't an argument. What COM automation work have
you done that relates to this?

The question should be.... What COM automation work have *you* done that
causes memory leaks? It wasn't the fault of VB6, that much I guarantee. The
COM objects you were using may've not been setup correctly for use with VB6,
but that's not VB's fault.

Ask yourself why Microsoft would abandon reference counters in favor of
Garbage Collection and ask yourself if, perhaps, others with "years of
experience" have possible done things you haven't.

LOL... Let's get Microsoft in here to explain that, eh? There've been many
flamewars over that exact "abandonmen t" issue... and possibly, others with
"years of experience" could've helped with those memory leak problems you
seemed to have problems with, because they've done things *you* haven't.

There's no reason to Set x = Nothing if x falls out of scope. If you
disagree, provide some proof.

In the case of circular references (which VB6 absolutely does not allow,
between projects, if loaded as a group project), you're on your own. Still,
not the fault of VB6 and "years of experience" gives you the tools required
to cure problems like that. A simple Debug.Print in Class_Terminate will
tell the world when the reference count = 0 for any object.

--
Ken Halter
Part time groupie

[mayayana]

Re: What has managed code achieved?

What are the advantages actually achieved of managed code? I am not
talking

of theory but in reality.
>

Something that most people don't seem to notice, in
all this talk of the pros and cons of memory management,
is the achievement from Microsoft's business perspective.

.Net goes a long way toward sandboxing all programmers
who are not MS or MS partners. Each new OS version
also continues in that direction. If MS goes the rest of
the way, blocking all "unsafe" code, they'll have the pieces
in place to achieve a radical transformation of the Windows
product, greatly increasing their own control over how the
product is used and enabling the full redefinition of Windows
as the brains of a service appliance rather than as a software
platform.

As a service appliance a Windows PC can have unhackable
DRM, hosted advertising, subscription software - and limited,
high-level, Java-style programming options. That direction holds
the possible promise of better stability, security and profits
for MS in the long term... Or at least they seem to think so.

Whether or not it's a positive achievement is in the eye of
the beholder.

[Herfried K. Wagner [MVP]]

Re: What has managed code achieved?

"Scott M." <s-mar@nospam.nosp amschrieb:

In VB 6, if you didn't explicitly destroy your object references, you not
only wasted memory, but also potentially tie up external resources. So,
to solve those two problems the developer HAD to dereference objects.

In most cases this was not necessary because references were removed
automatically when the (local) variables went out of scope (for example,
when leaving a procedure). The only fundamental difference is IMO the
automatical cleanup of circular references in .NET, which is a valuable
advantage.

The point being that in .NET, the developer doesn't write memory
management code, as was required in VB 6, and that is one advantage of
working in a managed environment.

Well, I have to disagree. Even in VB you have to remove references to
objects if you do not need them any more. For sure, you do not have to
clean up circular references, but it has even been possible to avoid
circular references in VB (by chosing another architecture or by using weak
references).

--
M S Herfried K. Wagner
M V P <URL:http://dotnet.mvps.org/>
V B <URL:http://dotnet.mvps.org/dotnet/faqs/>

[Herfried K. Wagner [MVP]]

Re: What has managed code achieved?

"Scott M." <s-mar@nospam.nosp amschrieb:

>>>>>and the fact that simply not setting an object
>>>>>referenc e to Nothing was most likely the culprit tell us this. This is
>>>>>not
>>>>>my opionion. VB 6 was well know for these issues.

>>
>If I don't need a particular object instance anymore then I'll set all
>references to Nothing or let them run out of scope. If however I still
>need it, then I don't. You can call that an "issue" or "memory leak".
>I don't. I wonder how the system should know about my plans if I don't
>state them?!

>
You've just made my point (the one that you said was wrong). In VB 6.0,
you had to state your intentions by either destroying your object
references or not. In .NET, you don't.

It's still similar (but different) in .NET: You have to remove references
to the objects you want to be destroyed to make them unreachable from the
current points of execution. Otherwise the CLR does not know that these
objects should be destroyed either.

--
M S Herfried K. Wagner
M V P <URL:http://dotnet.mvps.org/>
V B <URL:http://dotnet.mvps.org/dotnet/faqs/>

[Herfried K. Wagner [MVP]]

Re: What has managed code achieved?

"Juan T. Llibre" <nomailreplies@ nowhere.comschr ieb:

!What are the advantages actually achieved of managed code?
>
Imho, the greatest achievement for managed code is: it gets rid of "dll
hell".

DLL hell has even been solved for unmanaged code using the Side-by-Side
cache (SxS). It's not an advantage which would not be possible without a
managed code execution model.

--
M S Herfried K. Wagner
M V P <URL:http://dotnet.mvps.org/>
V B <URL:http://dotnet.mvps.org/dotnet/faqs/>

[John Saunders]

Re: What has managed code achieved?

"Herfried K. Wagner [MVP]" <hirf-spam-me-here@gmx.atwrot e in message
news:eWbhvYKNJH A.468@TK2MSFTNG P06.phx.gbl...

"Scott M." <s-mar@nospam.nosp amschrieb:

>The point being that in .NET, the developer doesn't write memory
>management code, as was required in VB 6, and that is one advantage of
>working in a managed environment.

>
Well, I have to disagree. Even in VB you have to remove references to
objects if you do not need them any more. For sure, you do not have to
clean up circular references, but it has even been possible to avoid
circular references in VB (by chosing another architecture or by using
weak references).

Would you mind being more specific? Do you mean that in VB.NET we have to
remove references to objects if we don't need them? Do you mean that this is
done by calling Dispose?

--
John Saunders | MVP - Connected System Developer