Hi
What are the advantages actually achieved of managed code? I am not talking
of theory but in reality.
Thanks
Regards
66  3260 
"John" <in**@nospam.infovis.co.ukwrote in message
news:%2******************@TK2MSFTNGP04.phx.gbl...
Hi
What are the advantages actually achieved of managed code? I am not
talking of theory but in reality.
http://en.wikipedia.org/wiki/CLI_Languages
<http://it.toolbox.com/blogs/paytonbyrd/day-1-introduction-to-managed-code-and-the-net-infrastructure-6588>
If you think about VB 6.0, which was not managed, developers had to write
lots of extra code that didn't necessarially have anything to do with the
programming problem. Developers had to write extra code to ensure memory
was managed correctly (set x = Nothing) and if they didn't, the program
would develop memory leaks. Developers also had to write addional code to
handle certain security and performance issues as well.
In the managed environment of the .NET CLR, much of this work is
automatically managed by the CLR through its code access security, garbage
collection, & MSIL.
The real, tangible advantages are that less code is written and that the
resulting programs are more robust and cross-language compatible.
-Scott
"John" <in**@nospam.infovis.co.ukwrote in message
news:%2******************@TK2MSFTNGP04.phx.gbl...
Hi
What are the advantages actually achieved of managed code? I am not
talking of theory but in reality.
Thanks
Regards
John,
What do you think?
Cor
"John" <in**@nospam.infovis.co.ukwrote in message
news:%2******************@TK2MSFTNGP04.phx.gbl...
Hi
What are the advantages actually achieved of managed code? I am not
talking of theory but in reality.
Thanks
Regards
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.infovis.co.ukwrote in message news:%2******************@TK2MSFTNGP04.phx.gbl...
Hi
What are the advantages actually achieved of managed code? I am not talking of theory but in reality.
Thanks
Regards
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" <no***********@nowhere.comwrote in message
news:OJ**************@TK2MSFTNGP04.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.infovis.co.ukwrote in message
news:%2******************@TK2MSFTNGP04.phx.gbl...
>Hi
What are the advantages actually achieved of managed code? I am not
talking of theory but in reality.
Thanks
Regards
"Juan T. Llibre" <no***********@nowhere.comwrote in message
news:OJ**************@TK2MSFTNGP04.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".
I think this depends on whether or not your regard the problems with the GAC
as another type of DLL hell,as it sounds like both I and Bill do. ;-)
For most, however, this is a definite advantage, as most do not use the GAC
much and those who do know how to version (maybe?).
--
Gregory A. Beamer
MVP, MCP: +I, SE, SD, DBA
Subscribe to my blog http://feeds.feedburner.com/GregoryBeamer#
or just read it: http://feeds.feedburner.com/GregoryBeamer
********************************************
| Think outside the box! |
********************************************
Less Blue Screens by junior developers. ;-)
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.
--
Gregory A. Beamer
MVP, MCP: +I, SE, SD, DBA
Subscribe to my blog http://feeds.feedburner.com/GregoryBeamer#
or just read it: http://feeds.feedburner.com/GregoryBeamer
********************************************
| Think outside the box! |
********************************************
"John" <in**@nospam.infovis.co.ukwrote in message
news:%2******************@TK2MSFTNGP04.phx.gbl...
Hi
What are the advantages actually achieved of managed code? I am not
talking of theory but in reality.
Thanks
Regards
Juan T. Llibre wrote:
re:
!What are the advantages actually achieved of managed code?
Imho, the greatest achievement for managed code is: it gets rid of
"dll hell".
Replaces it with assembly-hell, and since most assemblies still end in .dll
....
>
There's also automatic memory management, platform-neutrality, and
cross-language integration.
Ok.
>
Performance benefits are gained from executing all code in the CLR.
Calling unmanaged code decreases performance because additional
security checks are required.
That's "enabling partial trust scenarios", not improving performance.
Native performance is still better.
>
Other performance advantages are available through the use of the
Just-In-Time compiler,
Like? Sure, the JIT *could* use information about the hardware environment,
such as cache size or availability of extended instruction sets. But that's
more theory than reality.
with gains in built-in security by using code access security and the
avoidance of buffer overruns.
JIT doesn't avoid buffer overruns, bounds checking does. And precompilation
does a lot better job of reasoning about bounds checks at compile time and
optimizing them away than the JIT.
Almost all runtime performance gains from .NET are the fact that memory
allocation from a stack is a LOT cheaper than from a heap. In most cases
that actually pays for all the inefficiencies of .NET so managed code comes
out even with native on average, on many apps managed is a little faster,
for some native is a lot faster.
>
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.infovis.co.ukwrote in message
news:%2******************@TK2MSFTNGP04.phx.gbl...
>Hi
What are the advantages actually achieved of managed code? I am not
talking of theory but in reality. Thanks
Regards
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****@NoSpamBetav.comwrote in message
news:5A**********************************@microsof t.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" <no***********@nowhere.comwrote in message
news:OJ**************@TK2MSFTNGP04.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.infovis.co.ukwrote in message
news:%2******************@TK2MSFTNGP04.phx.gbl. ..
>>Hi
What are the advantages actually achieved of managed code? I am not
talking of theory but in reality.
Thanks
Regards
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****@NoSpamBetav.comwrote in message
news:5A**********************************@microsof t.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" <no***********@nowhere.comwrote in message news:OJ**************@TK2MSFTNGP04.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.infovis.co.ukwrote in message news:%2******************@TK2MSFTNGP04.phx.gbl...
>>Hi
What are the advantages actually achieved of managed code? I am not talking of theory but in reality.
Thanks
Regards
On 2008-10-21, Scott M. <s-***@nospam.nospamwrote:
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
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]" <No************@planet.nlwrote in message
news:O5**************@TK2MSFTNGP04.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****@NoSpamBetav.comwrote in message
news:5A**********************************@microsof t.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" <no***********@nowhere.comwrote in message
news:OJ**************@TK2MSFTNGP04.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.infovis.co.ukwrote in message
news:%2******************@TK2MSFTNGP04.phx.gbl.. .
Hi
What are the advantages actually achieved of managed code? I am not
talking of theory but in reality.
Thanks
Regards
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
On 2008-10-21, Scott M. <s-***@nospam.nospamwrote:
>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.
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
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
On 2008-10-21, Scott M. <s-***@nospam.nospamwrote:
>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
Scott M. <s-***@nospam.nospamwrote:
<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.Threading;
public class GcTest
{
~GcTest()
{
Console.WriteLine("Finalized");
}
static void Main()
{
GcTest test = new GcTest();
Console.WriteLine("Before GC.Collect");
GC.Collect();
GC.WaitForPendingFinalizers();
// Make it clear this isn't a race condition for the console
Thread.Sleep(5000);
Console.WriteLine("Before test = null");
test = null;
Console.WriteLine("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.com>
Web site: http://www.pobox.com/~skeet
Blog: http://www.msmvps.com/jon.skeet
C# in Depth: http://csharpindepth.com
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
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)" <bi****@NoSpamBetav.comschreef in bericht
news:%2***************@TK2MSFTNGP06.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]" <No************@planet.nlwrote in message
news:O5**************@TK2MSFTNGP04.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****@NoSpamBetav.comwrote in message
news:5A**********************************@microso ft.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" <no***********@nowhere.comwrote in message
news:OJ**************@TK2MSFTNGP04.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.infovis.co.ukwrote in message
news:%2******************@TK2MSFTNGP04.phx.gbl. ..
Hi
>
What are the advantages actually achieved of managed code? I am not
talking of theory but in reality.
>
Thanks
>
Regards
>
>
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" <no***********@nowhere.comschreef in bericht
news:u2****************@TK2MSFTNGP02.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)" <bi****@NoSpamBetav.comwrote in message
news:5A**********************************@microsof t.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" <no***********@nowhere.comwrote in message
news:OJ**************@TK2MSFTNGP04.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.infovis.co.ukwrote in message
news:%2******************@TK2MSFTNGP04.phx.gbl.. .
Hi
What are the advantages actually achieved of managed code? I am not
talking of theory but in reality.
Thanks
Regards
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)
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]" <no************@planet.nlwrote in message news:%2****************@TK2MSFTNGP06.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" <no***********@nowhere.comschreef in bericht news:u2****************@TK2MSFTNGP02.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)" <bi****@NoSpamBetav.comwrote in message
news:5A**********************************@microso ft.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" <no***********@nowhere.comwrote in message news:OJ**************@TK2MSFTNGP04.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.infovis.co.ukwrote in message news:%2******************@TK2MSFTNGP04.phx.gbl...
Hi
>
What are the advantages actually achieved of managed code? I am not talking of theory but in reality.
>
Thanks
>
Regards
>
>
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" <we******@temporaryforwarding.comwrote in message
news:pv********************************@4ax.com...
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)
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
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? ;-)
>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.
You can have the same with COM.
See: www.datenhaus.de/Downloads/DirectCOMDemo.zip
Wolfgang
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" <no***********@nowhere.comwrote in message
news:el**************@TK2MSFTNGP06.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]" <no************@planet.nlwrote in message
news:%2****************@TK2MSFTNGP06.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" <no***********@nowhere.comschreef in bericht
news:u2****************@TK2MSFTNGP02.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)" <bi****@NoSpamBetav.comwrote in message
news:5A**********************************@micros oft.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" <no***********@nowhere.comwrote in message
news:OJ**************@TK2MSFTNGP04.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.infovis.co.ukwrote in message
news:%2******************@TK2MSFTNGP04.phx.gbl ...
>Hi
>>
>What are the advantages actually achieved of managed code? I am not
>talking of theory but in reality.
>>
>Thanks
>>
>Regards
>>
>>
>
>
On Tue, 21 Oct 2008 07:36:44 -0400, "Juan T. Llibre" <no***********@nowhere.comwrote:
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)
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]" <No************@planet.nlwrote in message news:%2****************@TK2MSFTNGP05.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" <no***********@nowhere.comwrote in message news:el**************@TK2MSFTNGP06.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]" <no************@planet.nlwrote in message news:%2****************@TK2MSFTNGP06.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" <no***********@nowhere.comschreef in bericht news:u2****************@TK2MSFTNGP02.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)" <bi****@NoSpamBetav.comwrote in message
news:5A**********************************@micro soft.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" <no***********@nowhere.comwrote in message news:OJ**************@TK2MSFTNGP04.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.infovis.co.ukwrote in message news:%2******************@TK2MSFTNGP04.phx.gbl...
>>Hi
>>>
>>What are the advantages actually achieved of managed code? I am not talking of theory but in reality.
>>>
>>Thanks
>>>
>>Regards
>>>
>>>
>>
>>
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
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" <Us***********************@swspectrum.comwrote in message
news:mu********************************@4ax.com...
On Tue, 21 Oct 2008 07:36:44 -0400, "Juan T. Llibre" <no***********@nowhere.comwrote:
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)
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.
Paul Clement wrote:
On Tue, 21 Oct 2008 07:36:44 -0400, "Juan T. Llibre"
<no***********@nowhere.comwrote:
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)
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" <in**@nospam.infovis.co.ukwrote in message
news:%2******************@TK2MSFTNGP04.phx.gbl...
>Hi
What are the advantages actually achieved of managed code? I am not
talking of theory but in reality.
Thanks
Regards
¤ 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.
Inline...
"Wolfgang Enzinger" <we******@temporaryforwarding.comwrote in message
news:3n********************************@4ax.com...
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.
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]" <rb*@nospam.nospamwrote in message
news:uP**************@TK2MSFTNGP04.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
On 2008-10-22, Scott M. <s-***@nospam.nospamwrote:
Inline...
"Wolfgang Enzinger" <we******@temporaryforwarding.comwrote in message
news:3n********************************@4ax.com...
>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
>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.
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
"Scott M." <s-***@nospam.nospamwrote in message
news:ux**************@TK2MSFTNGP05.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 "abandonment" 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
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.
"Scott M." <s-***@nospam.nospamschrieb:
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/>
"Scott M." <s-***@nospam.nospamschrieb:
>>>>>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.
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/>
"Juan T. Llibre" <no***********@nowhere.comschrieb:
!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/>
"Herfried K. Wagner [MVP]" <hi***************@gmx.atwrote in message
news:eW*************@TK2MSFTNGP06.phx.gbl...
"Scott M." <s-***@nospam.nospamschrieb:
>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
Tom,
>
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.
You know that in VB.Net the object is not removed by either dispose or
setting it to nothing.
That is done by the Garbage Collector
As you really want to remove the object that has no references anymore then
you have to startl the GC.
I believe that this is only done by persons who still thinking in the style
of the 128Kb memory computers.
Cpr
re:
!(if you selected isolated execution of course)
....which not everybody used.
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/
======================================
"Ben Voigt [C++ MVP]" <rb*@nospam.nospamwrote in message news:Of**************@TK2MSFTNGP04.phx.gbl...
Paul Clement wrote:
>On Tue, 21 Oct 2008 07:36:44 -0400, "Juan T. Llibre"
<no***********@nowhere.comwrote:
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)
re:
!DLL hell has even been solved for unmanaged code using the Side-by-Side cache (SxS)
Have you ever implemented SxS for web applications ?
See : http://msdn.microsoft.com/en-us/libr...55(VS.85).aspx
and http://msdn.microsoft.com/en-us/libr...38(VS.85).aspx
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/
======================================
"Herfried K. Wagner [MVP]" <hi***************@gmx.atwrote in message news:uJ**************@TK2MSFTNGP06.phx.gbl...
"Juan T. Llibre" <no***********@nowhere.comschrieb:
>!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/>
On 2008-10-23, Cor Ligthert[MVP] <No************@planet.nlwrote:
>
Tom,
>>
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.
You know that in VB.Net the object is not removed by either dispose or
setting it to nothing.
That is done by the Garbage Collector
Yes, but it will never be collected as long at the reference remains active -
which is the point. Just as a VB6 object will never terminate under the same
circumstances.
--
Tom Shelton
Tom,
As I often forgot(maybe I do this still) the question mark, this time it was
no question. I simply knew that you was knowing this.
:-)
Cor
"Tom Shelton" <to*********@comcastXXXXXXX.netschreef in bericht
news:_-******************************@comcast.com...
On 2008-10-23, Cor Ligthert[MVP] <No************@planet.nlwrote:
>>
Tom,
>>>
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.
You know that in VB.Net the object is not removed by either dispose or
setting it to nothing.
That is done by the Garbage Collector
Yes, but it will never be collected as long at the reference remains
active -
which is the point. Just as a VB6 object will never terminate under the
same
circumstances.
--
Tom Shelton
This thread has been closed and replies have been disabled. Please start a new discussion. Similar topics
by: John |
last post by:
Hi
What are the advantages actually achieved of managed code? I am not talking
of theory but in reality.
Thanks
Regards
|
by: Faith0G |
last post by:
I am starting a new it consulting business and it's been a while since I setup a new website. Is wordpress still the best web based software for hosting a 5 page website? The webpages will be...
|
by: ryjfgjl |
last post by:
In our work, we often need to import Excel data into databases (such as MySQL, SQL Server, Oracle) for data analysis and processing. Usually, we use database tools like Navicat or the Excel import...
|
by: taylorcarr |
last post by:
A Canon printer is a smart device known for being advanced, efficient, and reliable. It is designed for home, office, and hybrid workspace use and can also be used for a variety of purposes. However,...
|
by: Charles Arthur |
last post by:
How do i turn on java script on a villaon, callus and itel keypad mobile phone
|
by: aa123db |
last post by:
Variable and constants
Use var or let for variables and const fror constants.
Var foo ='bar';
Let foo ='bar';const baz ='bar';
Functions
function $name$ ($parameters$) {
}
...
|
by: ryjfgjl |
last post by:
If we have dozens or hundreds of excel to import into the database, if we use the excel import function provided by database editors such as navicat, it will be extremely tedious and time-consuming...
|
by: emmanuelkatto |
last post by:
Hi All, I am Emmanuel katto from Uganda. I want to ask what challenges you've faced while migrating a website to cloud.
Please let me know.
Thanks!
Emmanuel
|
by: nemocccc |
last post by:
hello, everyone, I want to develop a software for my android phone for daily needs, any suggestions?
|
by: Hystou |
last post by:
There are some requirements for setting up RAID:
1. The motherboard and BIOS support RAID configuration.
2. The motherboard has 2 or more available SATA protocol SSD/HDD slots (including MSATA, M.2...
| |
