What has managed code achieved?

[John]

Hi

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

Thanks

Regards

[Cor Ligthert[MVP]]

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)" <bi****@NoSpamB etav.comwrote in message
news:5A******** *************** ***********@mic rosoft.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
[phone] (Pacific time)
Hitchhiker's Guide to Visual Studio and SQL Server (7th Edition)
_______________ _______________ _______________ _______________ _______________ _______________ __

"Juan T. Llibre" <no***********@ nowhere.comwrot e in message
news:OJ******** ******@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.

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" <in**@nospam.in fovis.co.ukwrot e in message
news:%2******* ***********@TK2 MSFTNGP04.phx.g bl...

>>Hi

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

Thanks

Regards

[Juan T. Llibre]

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)" <bi****@NoSpamB etav.comwrote in message
news:5A******** *************** ***********@mic rosoft.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
[phone] (Pacific time)
Hitchhiker's Guide to Visual Studio and SQL Server (7th Edition)
_______________ _______________ _______________ _______________ _______________ _______________ __

"Juan T. Llibre" <no***********@ nowhere.comwrot e in message news:OJ******** ******@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.

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" <in**@nospam.in fovis.co.ukwrot e in message news:%2******** **********@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

[Tom Shelton]

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

You're making my point Cor.

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.

Ben's last message seems to indicate that we should still do this in .NET
for optimal object collection. I was correcting him, as doing what he
suggests can actually delay object de-referencing.

In .NET, as you know, as long as you are disposing of your objects, which is
built in using Using, you are all set.

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.

-Scott

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 automatically
claimed when the method exited - well, assuming there wasn't a bug in the
underlying COM objects implementation :)

--
Tom Shelton

[William Vaughn \(MVP\)]

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
[phone] (Pacific time)
Hitchhiker's Guide to Visual Studio and SQL Server (7th Edition)
_______________ _______________ _______________ _______________ _______________ _______________ __

"Cor Ligthert[MVP]" <No************ @planet.nlwrote in message
news:O5******** ******@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)" <bi****@NoSpamB etav.comwrote in message
news:5A******** *************** ***********@mic rosoft.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
[phone] (Pacific time)
Hitchhiker's Guide to Visual Studio and SQL Server (7th Edition)
______________ _______________ _______________ _______________ _______________ _______________ ___

"Juan T. Llibre" <no***********@ nowhere.comwrot e in message
news:OJ******* *******@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" <in**@nospam.in fovis.co.ukwrot e in message
news:%2****** ************@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

[Scott M.]

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

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

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

-Scott

[Tom Shelton]

On 2008-10-21, Scott M. <s-***@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.]

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]

On 2008-10-21, Scott M. <s-***@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]]

Scott M. <s-***@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 - <sk***@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]]

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