What has managed code achieved?

**Tom Shelton** · Oct 21 '08, 06:45 PM

Re: What has managed code achieved?

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

>Scott - most of the time explicit managment of references was not
>necessary in
>VB6 either. About the only time that setting an object reference to
>nothing
>amounted to anything is if the object was a class or module level value -
>which is about the same as VB.NET. In VB6 local variables were
>automaticall y
>claimed when the method exited - well, assuming there wasn't a bug in the
>underlying COM objects implementation :)
>>
>--
>Tom Shelton

>
I don't know how you can make that statement when different VB 6
applications had object references scoped differently. I could just as
easily say that most applications did have module scoped object variables.
In those situations, you (the developer) were required to manage the
object's lifetime and by association, any external resources used by that
object.
>

You make it sound as if it was an onerous task on VB6 developers to manage
object lifetimes. It was not. Almost all applications probably use a mix of
scope - but, the only time that setting a value to nothing really had any
meaning was if that object was scoped at a level that would preclude it from
immediate cleanup (module scope, circular references, etc). This is true in
VB.NET as well (except the part about circular references). A module level
reference will live for the lifetime of the application - unless you as a
developer do something to signal to the gc that you are done with it. And
that something is set it to nothing.

All you are doing is persisting the old myth that you must do object cleanup
on all objects in vb6, which is utterly false.

In .NET, using Using, the developer need not do anything.
>

Just as a developer need do nothing with local values in VB6. Using is
syntactic sugar to ensure that non-managed resources get released in a timely
fashion. Something one didn't have to think about at all in VB6, since
reference counting ensured determinsitc finalization of objects - hence
automatic cleanup.

The downside of course to reference counting has more to do with performance
then anything else.

This is one aspect of what working with managed code buys us.

Not really. I love .NET and managed code - but, GC does not really change the
way that we managed object lifetimes in respect to VB6, except to make it
slightly more difficult, because now the developer has to be more aware of the
objects they are using - do the implement IDispose?

What GC and managed code buys us is more about performance and code saftey. GC
is faster then ref counting - in other words, object allocation/deallocation
is much faster ina GC system.

--
Tom Shelton

**Scott M.** · Oct 21 '08, 09:45 PM

Re: What has managed code achieved?

You make it sound as if it was an onerous task on VB6 developers to manage

object lifetimes. It was not.

All you are doing is persisting the old myth that you must do object
cleanup
on all objects in vb6, which is utterly false.

Tom Shelton

Well, there we have our disagreement. In fact, it was an onerous task in VB
6 to take care of object lifetime. 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 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.

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.

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.

-Scott

**Tom Shelton** · Oct 21 '08, 10:55 PM

Re: What has managed code achieved?

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

>You make it sound as if it was an onerous task on VB6 developers to manage
>object lifetimes. It was not.

>

>All you are doing is persisting the old myth that you must do object
>cleanup
>on all objects in vb6, which is utterly false.

>

>Tom Shelton

>
Well, there we have our disagreement. In fact, it was an onerous task in VB
6 to take care of object lifetime. 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 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.
>

Respectfully, you are wrong.

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.
>

Respectfully, you are wrong.

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.

They are usually developers who do not understand the way reference counting
and object lifetimes work in VB6.

For the 6 years I worked in the VB classic world, as a general rule, I had no
problems with memory leakage - I very rarely set any thing to nothing. In
my experience with helping others deal with memory leak issues, they were
almost the result of sloppy coding then any problem with VB....

--
Tom Shelton

**Jon Skeet [C# MVP]** · Oct 22 '08, 08:15 AM

Re: What has managed code achieved?

Scott M. <s-mar@nospam.nosp amwrote:

<snip>

In .NET, you are likely to adversely affect the performance of your
application by explicitly dereferencing your object (x = Nothing)! The GC
is optimized to look at running methods when collecting and to determine if
objects that still have application roots are actually going to be used in
the remainder of the method running. If you were to be cleaining up your
objects by setting them to Nothing, but hadn't reached that point of the
code yet, the GC would actually NOT mark your object that isn't going to be
used for any meaningful purpose for collection, now that you've got another
reference to it (the clean up code) later in the code.

I believe that was true at some point, and I guess it *might* still be
true for VB.NET, but it's not true for the C# 3.0 compiler and .NET
3.5. The compiler or JIT/GC - not sure which - understands that if the
only operation you're going to do on a variable is to write to it, it
doesn't count as a root.

Here's an example - compile with optimisation and without debug. (It
may work in other configurations, but that's what I've tried.)

using System;
using System.Threadin g;

public class GcTest
{
~GcTest()
{
Console.WriteLi ne("Finalized") ;
}

static void Main()
{
GcTest test = new GcTest();

Console.WriteLi ne("Before GC.Collect");

GC.Collect();
GC.WaitForPendi ngFinalizers();
// Make it clear this isn't a race condition for the console
Thread.Sleep(50 00);
Console.WriteLi ne("Before test = null");

test = null;
Console.WriteLi ne("After test = null");
}
}

Output:
Before GC.Collect
Finalized
Before test = null
After test = null

I *totally* agree that it's a bad thing to do in terms of clarity, but
it doesn't have the performance effect you described.

--
Jon Skeet - <skeet@pobox.co m>
Web site: http://www.pobox.com/~skeet
Blog: http://www.msmvps.com/jon.skeet
C# in Depth: http://csharpindepth.com

**Cor Ligthert[MVP]** · Oct 22 '08, 10:55 AM

Re: What has managed code achieved?

Jon,

You know that you get a reaction from me on this message.
Did you have lessons from Cato the Elder?

snip
I believe that was true at some point, and I guess it *might* still be
true for VB.NET
>end snip

You know better, before you answer that you wrote "might" I wrote about Cato
the Elder.

:-)

Cor

**Cor Ligthert[MVP]** · Oct 22 '08, 10:55 AM

Re: What has managed code achieved?

I only add too this, it does for me not matter what the price is in
hardware, it cost in OS administration to much.

I hope that I made it clear what I mean

And you know where I am stending in this.

Cor

"William Vaughn (MVP)" <billva@NoSpamB etav.comschreef in bericht
news:%231oiV25M JHA.468@TK2MSFT NGP06.phx.gbl.. .

Yes, but this attitude is myopic. In a client system in a business you
might be able to restrict the application configuration and remove
unnecessary Framework installations but as I understand it, some versions
of the Framework depend on earlier versions. In addition, in a typical
system I expect that even the OS draws on more than one version of the
Framework for its own utilities as do the utilities and applications that
are supplied by the hardware vendor. I expect that we're stuck with any
number of Frameworks for the next decade.
>
As to memory, I think it's arrogant to assume that memory is cheap so it's
ok to just load up the system and take all you need for as long as you
like. This is what kills system are applications that consume every byte
of memory in sight forcing other applications to be swapped out. Consider
that 32-bit systems (Vista or XP) can only use 3.5GB of RAM. Take away the
OS footprint, a couple .NET Frameworks and the memory consumed by the
ancillary utilities like Anti-Virus, Anti-spyware, Anti-spam, SQL Server
Express instances, Adobe, Office and other "helper" DLLs and you don't
have much memory left to load up that set of pictures, documents and
"real" applications. Consider that most (by far) of the systems out there
are owned and run by consumers or offices that permit their employees to
treat their systems as their own--thus they get loaded up with a lot of
memory-hungry applications and wallpapers. I see this attitude toward
memory (and disk space) like the US's approach to cheap oil. We built an
entire infrastructure around it with no eye to the future when oil is
$150/barrel.
>
No, IMHO developers still need to be cognizant about how much memory
they're consuming and holding. Given that the .NET Framework GC only runs
when the system is memory stressed only exacerbates the problem.
>
--
_______________ _______________ _______________ _______________ ______________
William R. Vaughn
President and Founder Beta V Corporation
Author, Mentor, Dad, Grandpa
Microsoft MVP
(425) 556-9205 (Pacific time)
Hitchhiker's Guide to Visual Studio and SQL Server (7th Edition)
_______________ _______________ _______________ _______________ _______________ _______________ __
>
>
>
"Cor Ligthert[MVP]" <Notmyfirstname @planet.nlwrote in message
news:O5IKezyMJH A.4724@TK2MSFTN GP04.phx.gbl...

>William,
>>
>You awake me.
>>
>I agree with you that it is strange that we load all kind of Net
>framework, or better Microsoft does that on our computers.
>>
>As we are not using Net 1.x then the latest version should in fact be
>enough.
>>
>Cor
>>
>>
>"William Vaughn (MVP)" <billva@NoSpamB etav.comwrote in message
>news:5ADAAC5 2-4FA0-4FD0-B7E0-84803F35FF58@mi crosoft.com...

>>But have we traded one kind of DLL hell for another? How many versions
>>of the Framework are loaded on your system? How is COM-based DLL
>>management any different than GAC-cached modules that can be replaced
>>without retesting the consumer applications? Since we now must wait
>>while the code is compiled before it can be executed, the performance
>>argument might not hold water for some applications. Notice how long it
>>takes to launch the Report Manager... I expect that managed code has
>>managed to disenfranchise a lot of perfectly good COM developers...
>>>
>>--
>>_____________ _______________ _______________ _______________ _______________ _
>>William R. Vaughn
>>President and Founder Beta V Corporation
>>Author, Mentor, Dad, Grandpa
>>Microsoft MVP
>>(425) 556-9205 (Pacific time)
>>Hitchhiker' s Guide to Visual Studio and SQL Server (7th Edition)
>>_____________ _______________ _______________ _______________ _______________ _______________ ____
>>>
>>>
>>>
>>"Juan T. Llibre" <nomailreplies@ nowhere.comwrot e in message
>>news:OJP$fstM JHA.5692@TK2MSF TNGP04.phx.gbl. ..
>>>re:
>>>!What are the advantages actually achieved of managed code?
>>>>
>>>Imho, the greatest achievement for managed code is: it gets rid of "dll
>>>hell".
>>>>
>>>There's also automatic memory management, platform-neutrality, and
>>>cross-language integration.
>>>>
>>>Performanc e benefits are gained from executing all code in the CLR.
>>>Calling unmanaged code decreases performance because additional
>>>security checks are required.
>>>>
>>>Other performance advantages are available through the use of the
>>>Just-In-Time compiler,
>>>with gains in built-in security by using code access security and the
>>>avoidance of buffer overruns.
>>>>
>>>>
>>>>
>>>>
>>>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/
>>>============ =============== ===========
>>>"John" <info@nospam.in fovis.co.ukwrot e in message
>>>news:%23A%23 ByekMJHA.3496@T K2MSFTNGP04.phx .gbl...
>>>>Hi
>>>>>
>>>>What are the advantages actually achieved of managed code? I am not
>>>>talking of theory but in reality.
>>>>>
>>>>Thanks
>>>>>
>>>>Regards
>>>>>
>>>>>
>>>>
>>>>

>>

**Cor Ligthert[MVP]** · Oct 22 '08, 10:55 AM

Re: What has managed code achieved?

Juan,

How many OS have you installed.

As I read what you write, then you have probably still MS-Dos 1.0 as well
installed?

Cor

"Juan T. Llibre" <nomailreplies@ nowhere.comschr eef in bericht
news:u2l%23MF3M JHA.1308@TK2MSF TNGP02.phx.gbl. ..

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
>
re:
!How many versions of the Framework are loaded on your system?
>
That's irrelevant.
The fact that several versions of the .Net Framework can coexist hardly
qualifies as "dll hell".
>
>
>
>
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/
=============== =============== ========
"William Vaughn (MVP)" <billva@NoSpamB etav.comwrote in message
news:5ADAAC52-4FA0-4FD0-B7E0-84803F35FF58@mi crosoft.com...

>But have we traded one kind of DLL hell for another? How many versions of
>the Framework are loaded on your system? How is COM-based DLL management
>any different than GAC-cached modules that can be replaced without
>retesting the consumer applications? Since we now must wait while the
>code is compiled before it can be executed, the performance argument
>might not hold water for some applications. Notice how long it takes to
>launch the Report Manager... I expect that managed code has managed to
>disenfranchi se a lot of perfectly good COM developers...
>>
>--
>______________ _______________ _______________ _______________ _______________
>William R. Vaughn
>President and Founder Beta V Corporation
>Author, Mentor, Dad, Grandpa
>Microsoft MVP
>(425) 556-9205 (Pacific time)
>Hitchhiker's Guide to Visual Studio and SQL Server (7th Edition)
>______________ _______________ _______________ _______________ _______________ _______________ ___
>>
>>
>>
>"Juan T. Llibre" <nomailreplies@ nowhere.comwrot e in message
>news:OJP$fstMJ HA.5692@TK2MSFT NGP04.phx.gbl.. .

>>re:
>>!What are the advantages actually achieved of managed code?
>>>
>>Imho, the greatest achievement for managed code is: it gets rid of "dll
>>hell".
>>>
>>There's also automatic memory management, platform-neutrality, and
>>cross-language integration.
>>>
>>Performance benefits are gained from executing all code in the CLR.
>>Calling unmanaged code decreases performance because additional security
>>checks are required.
>>>
>>Other performance advantages are available through the use of the
>>Just-In-Time compiler,
>>with gains in built-in security by using code access security and the
>>avoidance of buffer overruns.
>>>
>>>
>>>
>>>
>>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/
>>============= =============== ==========
>>"John" <info@nospam.in fovis.co.ukwrot e in message
>>news:%23A%23B yekMJHA.3496@TK 2MSFTNGP04.phx. gbl...
>>>Hi
>>>>
>>>What are the advantages actually achieved of managed code? I am not
>>>talking of theory but in reality.
>>>>
>>>Thanks
>>>>
>>>Regards
>>>>
>>>>
>>>
>>>

>
>

**Wolfgang Enzinger** · Oct 22 '08, 01:45 PM

Re: What has managed code achieved?

On Tue, 21 Oct 2008 17:38:14 -0400, "Scott M." wrote:

>Well, there we have our disagreement. In fact, it was an onerous task in VB
>6 to take care of object lifetime. 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 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.
>
>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.
>
>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 can't resist from quoting that all because that's one unique
collection of nonsense.

Wolfgang (professional VB developer, version 3 - 6)

**Juan T. Llibre** · Oct 22 '08, 02:35 PM

Re: What has managed code achieved?

re:
!How many OS have you installed.
!As I read what you write, then you have probably still MS-Dos 1.0 as well installed?

Did you write web apps with MS-DOS 1.0 ?
Please explain the relevancy of your comments, in terms of what "dll hell" means.

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/
=============== =============== ========
"Cor Ligthert[MVP]" <notmyfirstname @planet.nlwrote in message news:%23FGcHPDN JHA.2884@TK2MSF TNGP06.phx.gbl. ..

Juan,
>
How many OS have you installed.
>
As I read what you write, then you have probably still MS-Dos 1.0 as well installed?
>
Cor
>
"Juan T. Llibre" <nomailreplies@ nowhere.comschr eef in bericht news:u2l%23MF3M JHA.1308@TK2MSF TNGP02.phx.gbl. ..

>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
>>
>re:
>!How many versions of the Framework are loaded on your system?
>>
>That's irrelevant.
>The fact that several versions of the .Net Framework can coexist hardly qualifies as "dll hell".
>>
>>
>>
>>
>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/
>============== =============== =========
>"William Vaughn (MVP)" <billva@NoSpamB etav.comwrote in message
>news:5ADAAC5 2-4FA0-4FD0-B7E0-84803F35FF58@mi crosoft.com...

>>But have we traded one kind of DLL hell for another? How many versions of the Framework are loaded on your system?
>>How is COM-based DLL management any different than GAC-cached modules that can be replaced without retesting the
>>consumer applications? Since we now must wait while the code is compiled before it can be executed, the performance
>>argument might not hold water for some applications. Notice how long it takes to launch the Report Manager... I
>>expect that managed code has managed to disenfranchise a lot of perfectly good COM developers...
>>>
>>--
>>_____________ _______________ _______________ _______________ _______________ _
>>William R. Vaughn
>>President and Founder Beta V Corporation
>>Author, Mentor, Dad, Grandpa
>>Microsoft MVP
>>(425) 556-9205 (Pacific time)
>>Hitchhiker' s Guide to Visual Studio and SQL Server (7th Edition)
>>_____________ _______________ _______________ _______________ _______________ _______________ ____
>>>
>>>
>>>
>>"Juan T. Llibre" <nomailreplies@ nowhere.comwrot e in message news:OJP$fstMJH A.5692@TK2MSFTN GP04.phx.gbl...
>>>re:
>>>!What are the advantages actually achieved of managed code?
>>>>
>>>Imho, the greatest achievement for managed code is: it gets rid of "dll hell".
>>>>
>>>There's also automatic memory management, platform-neutrality, and cross-language integration.
>>>>
>>>Performanc e benefits are gained from executing all code in the CLR.
>>>Calling unmanaged code decreases performance because additional security checks are required.
>>>>
>>>Other performance advantages are available through the use of the Just-In-Time compiler,
>>>with gains in built-in security by using code access security and the avoidance of buffer overruns.
>>>>
>>>>
>>>>
>>>>
>>>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/
>>>============ =============== ===========
>>>"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
>>>>>
>>>>>
>>>>
>>>>

>>
>>

>
>

**Juan T. Llibre** · Oct 22 '08, 02:35 PM

Re: What has managed code achieved?

re:
!I can't resist from quoting that all because that's one unique collection of nonsense.

Can you explain why ?

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/
=============== =============== ========
"Wolfgang Enzinger" <weusenet@tempo raryforwarding. comwrote in message
news:pv9uf4lil2 5vdrbpgf7mb4lv4 k7japgu6o@4ax.c om...

On Tue, 21 Oct 2008 17:38:14 -0400, "Scott M." wrote:
>

>>Well, there we have our disagreement. In fact, it was an onerous task in VB
>>6 to take care of object lifetime. 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 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.
>>
>>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.
>>
>>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 can't resist from quoting that all because that's one unique
collection of nonsense.
>
Wolfgang (professional VB developer, version 3 - 6)

**Wolfgang Enzinger** · Oct 22 '08, 03:25 PM

Re: What has managed code achieved?

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.

>>>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 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.

>>>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?!

>>>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*.

>>>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

**Wolfgang Enzinger** · Oct 22 '08, 03:25 PM

Re: What has managed code achieved?

On Mon, 20 Oct 2008 17:05:27 -0500, "Gregory A. Beamer $Cowboy$ -
MVP" wrote:

>Less Blue Screens by junior developers. ;-)

Yeah, they are white nowadays, aren't they? ;-)

>Realisticall y, 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.

You can have the same with COM.

See: www.datenhaus.de/Downloads/DirectCOMDemo.zip

Wolfgang

**Cor Ligthert[MVP]** · Oct 22 '08, 05:05 PM

Re: What has managed code achieved?

It is about this text from you.

>That's irrelevant.
>The fact that several versions of the .Net Framework can coexist hardly
>qualifies as "dll hell".

Like Bill wrote, it is not about two or more, it is about the situation.
Net Framework is a kind of OS layer. And therefore it in my eyes as
writting.

The fact that several versions of an OS can coexist ............... ......

Cor

"Juan T. Llibre" <nomailreplies@ nowhere.comwrot e in message
news:elew8KFNJH A.2760@TK2MSFTN GP06.phx.gbl...

re:
!How many OS have you installed.
!As I read what you write, then you have probably still MS-Dos 1.0 as
well installed?
>
Did you write web apps with MS-DOS 1.0 ?
Please explain the relevancy of your comments, in terms of what "dll hell"
means.
>
>
>
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/
=============== =============== ========
"Cor Ligthert[MVP]" <notmyfirstname @planet.nlwrote in message
news:%23FGcHPDN JHA.2884@TK2MSF TNGP06.phx.gbl. ..

>Juan,
>>
>How many OS have you installed.
>>
>As I read what you write, then you have probably still MS-Dos 1.0 as
>well installed?
>>
>Cor
>>
>"Juan T. Llibre" <nomailreplies@ nowhere.comschr eef in bericht
>news:u2l%23MF3 MJHA.1308@TK2MS FTNGP02.phx.gbl ...

>>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
>>>
>>re:
>>!How many versions of the Framework are loaded on your system?
>>>
>>That's irrelevant.
>>The fact that several versions of the .Net Framework can coexist hardly
>>qualifies as "dll hell".
>>>
>>>
>>>
>>>
>>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/
>>============= =============== ==========
>>"William Vaughn (MVP)" <billva@NoSpamB etav.comwrote in message
>>news:5ADAAC 52-4FA0-4FD0-B7E0-84803F35FF58@mi crosoft.com...
>>>But have we traded one kind of DLL hell for another? How many versions
>>>of the Framework are loaded on your system? How is COM-based DLL
>>>management any different than GAC-cached modules that can be replaced
>>>without retesting the consumer applications? Since we now must wait
>>>while the code is compiled before it can be executed, the performance
>>>argument might not hold water for some applications. Notice how long it
>>>takes to launch the Report Manager... I expect that managed code has
>>>managed to disenfranchise a lot of perfectly good COM developers...
>>>>
>>>--
>>>____________ _______________ _______________ _______________ _______________ __
>>>William R. Vaughn
>>>President and Founder Beta V Corporation
>>>Author, Mentor, Dad, Grandpa
>>>Microsoft MVP
>>>(425) 556-9205 (Pacific time)
>>>Hitchhiker 's Guide to Visual Studio and SQL Server (7th Edition)
>>>____________ _______________ _______________ _______________ _______________ _______________ _____
>>>>
>>>>
>>>>
>>>"Juan T. Llibre" <nomailreplies@ nowhere.comwrot e in message
>>>news:OJP$fst MJHA.5692@TK2MS FTNGP04.phx.gbl ...
>>>>re:
>>>>!What are the advantages actually achieved of managed code?
>>>>>
>>>>Imho, the greatest achievement for managed code is: it gets rid of
>>>>"dll hell".
>>>>>
>>>>There's also automatic memory management, platform-neutrality, and
>>>>cross-language integration.
>>>>>
>>>>Performan ce benefits are gained from executing all code in the CLR.
>>>>Calling unmanaged code decreases performance because additional
>>>>security checks are required.
>>>>>
>>>>Other performance advantages are available through the use of the
>>>>Just-In-Time compiler,
>>>>with gains in built-in security by using code access security and the
>>>>avoidance of buffer overruns.
>>>>>
>>>>>
>>>>>
>>>>>
>>>>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/
>>>>=========== =============== ============
>>>>"John" <info@nospam.in fovis.co.ukwrot e in message
>>>>news:%23A%2 3ByekMJHA.3496@ TK2MSFTNGP04.ph x.gbl...
>>>>>Hi
>>>>>>
>>>>>What are the advantages actually achieved of managed code? I am not
>>>>>talking of theory but in reality.
>>>>>>
>>>>>Thanks
>>>>>>
>>>>>Regards
>>>>>>
>>>>>>
>>>>>
>>>>>
>>>
>>>

>>
>>

>
>

**Paul Clement** · Oct 22 '08, 05:55 PM

Re: What has managed code achieved?

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)

**Juan T. Llibre** · Oct 22 '08, 06:15 PM

Re: What has managed code achieved?

re:
!It is about this text from you.

I, still, don't see the relevance.

re:
!Net Framework is a kind of OS layer.

Well, it *does* sit on top of the OS, like all programming frameworks do.

re:
!The fact that several versions of an OS can coexist

The .Net framework is not an OS.

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/
=============== =============== ========
"Cor Ligthert[MVP]" <Notmyfirstname @planet.nlwrote in message news:%23rdoWfGN JHA.5232@TK2MSF TNGP05.phx.gbl. ..

It is about this text from you.
>

>>That's irrelevant.
>>The fact that several versions of the .Net Framework can coexist hardly qualifies as "dll hell".

>
Like Bill wrote, it is not about two or more, it is about the situation.
Net Framework is a kind of OS layer. And therefore it in my eyes as writting.
>
The fact that several versions of an OS can coexist ............... ......
>
Cor
>
"Juan T. Llibre" <nomailreplies@ nowhere.comwrot e in message news:elew8KFNJH A.2760@TK2MSFTN GP06.phx.gbl...

>re:
>!How many OS have you installed.
>!As I read what you write, then you have probably still MS-Dos 1.0 as well installed?
>>
>Did you write web apps with MS-DOS 1.0 ?
>Please explain the relevancy of your comments, in terms of what "dll hell" means.
>>
>>
>>
>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/
>============== =============== =========
>"Cor Ligthert[MVP]" <notmyfirstname @planet.nlwrote in message news:%23FGcHPDN JHA.2884@TK2MSF TNGP06.phx.gbl. ..

>>Juan,
>>>
>>How many OS have you installed.
>>>
>>As I read what you write, then you have probably still MS-Dos 1.0 as well installed?
>>>
>>Cor
>>>
>>"Juan T. Llibre" <nomailreplies@ nowhere.comschr eef in bericht news:u2l%23MF3M JHA.1308@TK2MSF TNGP02.phx.gbl. ..
>>>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
>>>>
>>>re:
>>>!How many versions of the Framework are loaded on your system?
>>>>
>>>That's irrelevant.
>>>The fact that several versions of the .Net Framework can coexist hardly qualifies as "dll hell".
>>>>
>>>>
>>>>
>>>>
>>>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/
>>>============ =============== ===========
>>>"William Vaughn (MVP)" <billva@NoSpamB etav.comwrote in message
>>>news:5ADAAC5 2-4FA0-4FD0-B7E0-84803F35FF58@mi crosoft.com...
>>>>But have we traded one kind of DLL hell for another? How many versions of the Framework are loaded on your system?
>>>>How is COM-based DLL management any different than GAC-cached modules that can be replaced without retesting the
>>>>consumer applications? Since we now must wait while the code is compiled before it can be executed, the
>>>>performan ce argument might not hold water for some applications. Notice how long it takes to launch the Report
>>>>Manager.. . I expect that managed code has managed to disenfranchise a lot of perfectly good COM developers...
>>>>>
>>>>--
>>>>___________ _______________ _______________ _______________ _______________ ___
>>>>William R. Vaughn
>>>>President and Founder Beta V Corporation
>>>>Author, Mentor, Dad, Grandpa
>>>>Microsoft MVP
>>>>(425) 556-9205 (Pacific time)
>>>>Hitchhiker' s Guide to Visual Studio and SQL Server (7th Edition)
>>>>___________ _______________ _______________ _______________ _______________ _______________ ______
>>>>>
>>>>>
>>>>>
>>>>"Juan T. Llibre" <nomailreplies@ nowhere.comwrot e in message news:OJP$fstMJH A.5692@TK2MSFTN GP04.phx.gbl...
>>>>>re:
>>>>>!What are the advantages actually achieved of managed code?
>>>>>>
>>>>>Imho, the greatest achievement for managed code is: it gets rid of "dll hell".
>>>>>>
>>>>>There's also automatic memory management, platform-neutrality, and cross-language integration.
>>>>>>
>>>>>Performanc e benefits are gained from executing all code in the CLR.
>>>>>Calling unmanaged code decreases performance because additional security checks are required.
>>>>>>
>>>>>Other performance advantages are available through the use of the Just-In-Time compiler,
>>>>>with gains in built-in security by using code access security and the avoidance of buffer overruns.
>>>>>>
>>>>>>
>>>>>>
>>>>>>
>>>>>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/
>>>>>========== =============== =============
>>>>>"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
>>>>>>>
>>>>>>>
>>>>>>
>>>>>>
>>>>
>>>>
>>>
>>>

>>
>>

>

What has managed code achieved?

Comment

Comment

Comment

Comment

Comment

Comment

Comment

Comment

Comment

Comment

Comment

Comment

Comment

Comment

Comment