|
"I was gonna write some C++, but then I got high
I was gonna skip all that .NET stuff, but then I got high,
Now I'm stuck with non-deterministic finalization, and I know why.
Because I got high, because I got high, because I got high."
Concerning buying .NET:
Well VC++ 6 works quite well (i havent found any serious bug from SP5, well IDE crashes from time to time, but w2k crashes from time to time too  ) and
i am not prepared to switch to new buggy platform so soon! I have enough work
with my own bugs so i will stick to 6.0 untill .NET SP3 will be out. Good
luck to optimists who thinks that .NET would be "usefull" from the start, but hey, someone have to be "microsoft-calls-it-.NET-but-i-am-sure-it-is-just-.BUG" tester so i could get relatively bug free version in a year or two
If you want to buy .NET, take paper (notepad) and try to write down 10 reasons why you want to buy it. While you will trying to figure it out, .NET SP3 will be out!
|
|
|
|
|
if i got this right, even a program written in a powerful language like C/C++ is turned into an executable containing .il script language for JIT compiler, which effectively turns all your C programs to a sort of VB crap.
there are people who like to program JAVA or VB, but nobody likes to run programs written in them, not for serious tasks.
also, there are hundreds of programs that copy system dlls to the program directory on setup. this is also crap, but you wont need .CRAP to do that.
why use it?????
|
|
|
|
|
You can choose to have your C++ code generate standard Win32 code the way it always has, or if you would like to use C++ to write code targeted for the CLR, you can do that too. The fact that C++ is supported as a first class .Net language isn't a negative thing, it is provided to allow you to painlessly move to the runtime if you wish.
David
http://www.dundas.com
|
|
|
|
|
I don't care about the .NET part of it, or managed code, or ASP or any of that stuff, I just want the new visual c++.
Looking forward to using a compiler that isn't 4 years old.
Now if I could just get the Visual Assist beta for it. (I'm soooo lost without it, don't remember how to type a whole variable name anymore :P)
Jim Wuerch
www.miwasoft.com
Quote from my readme files:
"This is BETA software, and as such may completely destroy your computer, change the alignment of the planets and invert the structure of the universe."
|
|
|
|
|
Microsoft's most successful (and arguably) best products are the ones that sort of hang around without new versions constantly being released. NT4.0, VC6, etc. It's when Microsoft has a product which goes through 400 revisions a year that you get nervous. Call me old fashioned... but hey, love is a stable revision.
|
|
|
|
|
Well, that's certainly a giant plus for MFC, it's pretty mature, and hasn't changed much in a while.
The compiler, on the other hand, was getting a bit long in the tooth. Processor architectures have changed a LOT in the past 4 years, so it's nice to have a more modern compiler out of the box (yeah, I know, intel has a compiler that is a plugin for visual studio)
Jim Wuerch
www.miwasoft.com
Quote from my readme files:
"This is BETA software, and as such may completely destroy your computer, change the alignment of the planets and invert the structure of the universe."
|
|
|
|
|
Sorry for my ignorance of .NET (both my boss and I haven't found any reason to spend money on it, yet).
One good thing I heard is that .NET fixes the "Dll Hell" problem. According to the training class (it's free from Microsoft, so I took the advantage) I attended, the solution is copying various versions of dlls to each application's own directory so that they won't interfere with each other. Excuse me, but isn't this solution going to create another problem, a "spaghetti hell"? It seems to defeat one of the main purposes of dlls: sharing code among different programs.
I think the "Dll Hell" cannot be fixed. You just can't have it both ways: sharing code and then modifying the shared code without risk.
What's your opinion? Please educate me.
|
|
|
|
|
I think you're a bit wrong here -
Nowadays disk space and RAM aren't as expensive as they used to be, and it is indeed POSSIBLE for every program to keep a copy of the DLLs that it uses.
You claim that this approach defeats the "sharing code" idea of the DLL, but it's not true. How would you suggest that a third-party will share its components and code with others?
And besides, DLLs have other advantages, such as dynamic loading of the required parts of the application.
Oz
|
|
|
|
|
I can't agree more.
Michael
|
|
|
|
|
Oz wrote:
"Nowadays disk space and RAM aren't as expensive as they used to be, and it is indeed POSSIBLE for every program to keep a copy of the DLLs that it uses."
Ok, does that help to explain the 2 gb size of .NET? 
Oz wrote:
"You claim that this approach defeats the "sharing code" idea of the DLL, but it's not true. How would you suggest that a third-party will share its components and code with others?"
You can always create new dlls or new interfaces to satisfy new requirements, which is not perfect, but as I said, you can't have it both ways.
Oz wrote:
"And besides, DLLs have other advantages, such as dynamic loading of the required parts of the application."
No argument here.
|
|
|
|
|
A C++ programmer wrote:
Ok, does that help to explain the 2 gb size of .NET?
If you think it's big now, wait 'til they start adding security stuff to it.
A C++ programmer wrote:
You can always create new dlls or new interfaces to satisfy new requirements, which is not perfect, but as I said, you can't have it both ways.
So, you're saying that we're in hell, and we'll never escape?
A C++ programmer wrote:
And besides, DLLs have other advantages, such as dynamic loading of the required parts of the application
Hmmm, code sharing (on a limited basis, and can be accomplished in other ways, depending on the other program's programming language), and just-in-time dynamic loading (only useful under certain circumstances). What are the "other advantages"?
DLL's (and especially COM) are often over-used (in the wrong circumstances) and have their own (sometimes dramatically) high cost of implementation.
"...the staggering layers of obscenity in your statement make it a work of art on so many levels." - Jason Jystad, 10/26/2001
|
|
|
|
|
John wrote:
"If you think it's big now, wait 'til they start adding security stuff to it."
No, I don't think it's big, I just think my hard-drive is too small. 
John wrote:
"So, you're saying that we're in hell, and we'll never escape?"
So, what's your point here? Do you think:
(a) .NET solved the (dll hell) problem without creating a new one?
(b) You know or believe there is another solution that leads us out of the hell?
(c) You are just agreeing with me: we can't have it both ways (sharing code and modifying the shared code without risk)?
John wrote:
"What are the other advantages"?
For example, you can change the internal implementation of a dll without changing all the code that uses it.
|
|
|
|
|
A C++ programmer wrote:
So, what's your point here?
My point is that we're in DLL hell, and we're never going to NOT be there.
A C++ programmer wrote:
For example, you can change the internal implementation of a dll without changing all the code that uses it.
That's a terrible example. You can also change an EXE with the code in it without compiling anything else.
.NET doesn't solve anything for the programmer or the end-user, just like COM didn't solve the old version of DLL hell - it just provided us with a new and improved version of hell.
"...the staggering layers of obscenity in your statement make it a work of art on so many levels." - Jason Jystad, 10/26/2001
|
|
|
|
|
DLL Hell (in terms of versioning) has been addressed in .NET by allowing multiple versions of the same Assembly (DLL) to coexist in peace on a machine. In fact a single executable can load 2 versions of the same DLL during execution.
The Global Assembly Cache (GAC) addresses the problem of shared DLLs being removed or overwritten. The system keeps a copy (including version info) that apps then use.
cheers,
Chris Maunder
|
|
|
|
|
Chris said:
"DLL Hell (in terms of versioning) has been addressed in .NET by allowing multiple versions of the same Assembly (DLL) to coexist in peace on a machine. In fact a single executable can load 2 versions of the same DLL during execution."
If you want to use multiple versions of the same dll, you might as well give them different names or guids, which will be less confusing. Why would a single executable load 2 versions of the same dll during execution, unless trying to confuse people including the developer himself? 
Chris said:
"The Global Assembly Cache (GAC) addresses the problem of shared DLLs being removed or overwritten. The system keeps a copy (including version info) that apps then use."
That is cool, I agree. The solution without .NET is, rename the old version of the dll and then copy the new one to the same directory, worked for me at least (most of the times) 
|
|
|
|
|
A C++ programmer wrote:
If you want to use multiple versions of the same dll, you might as well give them different names or guids, which will be less confusing. Why would a single executable load 2 versions of the same dll during execution, unless trying to confuse people including the developer himself?
Well, think of two third-party COMponentes, that need different versions of a third component.
Especially the Common Controls dll is a really good candidate for this. It evolves quite fast and there is always something that is only "nearly" backward compatible in newer versions.
--
Daniel Lohmann
http://www.losoft.de
|
|
|
|
|
"Well, think of two third-party COMponentes, that need different versions of a third component.
Especially the Common Controls dll is a really good candidate for this. It evolves quite fast and there is always something that is only "nearly" backward compatible in newer versions. "
This is indeed a very good example of loading two versions of the same dll into an executable. But, don't you think it is worse than the "dll hell"?
Speaking of common controls dll, I agree with you: you cannot win, no way. If Microsfot wants to screw you, it can do a lot more.
|
|
|
|
|
One of the major tasks that has emerged in the IT world is the careful regression testing of software systems, and in large corporations, the onerous task of having new software, or new versions of existing software approved for distribution and use.
As approving client side software has become an increasingly complex and costly task, major corporations have concluded that it's much, much cheaper for these applications to be written as web apps and run through a client side browser.
Microsoft has a strong economic case for continuing to ensure that Windows is a viable, and hard to replace productivity platform. And so it's very much in their interest (and that of their customers) to attack the issues that make maintaining windows systems expensive. One of the most major issues is software that conflicts, and this is mainly caused by one application’s DLLs tromping on another’s, or even on the Windows DLLs themselves.
I think Microsoft decided that stable system operation and a definitive end to code conflicts outweighed the benefits of memory and disk conservation using DLLs, and I think they're right.
I think what they've done makes much more sense if you look at in the context of the problem they're trying to solve.
David
http://www.dundas.com
|
|
|
|
|
"I think Microsoft decided that stable system operation and a definitive end to code conflicts outweighed the benefits of memory and disk conservation using DLLs, and I think they're right."
I just can't agree with the above. Memory and disk conservation is not the main issue here. If you purposely allow multiple-versions of the same dll (or component) to be used on the same machine or even within the same application, it will probably create more serious problems. Besides that, it will definitely make debugging and testing harder.
|
|
|
|
|
ASP.NET
nuff said 
regards,
Paul Watson
Bluegrass
Cape Town, South Africa
"The greatest thing you will ever learn is to love, and be loved in return" - Moulin Rouge
Martin Marvinski wrote:
Unfortunatly Deep Throat isn't my cup of tea
Do you Sonork? I do! 100.9903 Stormfront
|
|
|
|
|
How soon before you'd risk using it for a paying customer?
Michael
|
|
|
|
|
Michael P Butler wrote:
How soon before you'd risk using it for a paying customer?
We already have two projects in analysis and design phase which will be developed in ASP.NET
The clients insisted even though we gave the usual "new technology blah blah" warning. One is actually a "Microsoft Preferred .NET Provider" company, and they got us to do the development... lol!
While I understand everyones warning that .NET is still new, I am still going to have a blast with these projects. Plus we have to actually do some projects before we can call .NET a failure or success.
regards,
Paul Watson
Bluegrass
Cape Town, South Africa
"The greatest thing you will ever learn is to love, and be loved in return" - Moulin Rouge
Martin Marvinski wrote:
Unfortunatly Deep Throat isn't my cup of tea
Do you Sonork? I do! 100.9903 Stormfront
|
|
|
|
|
Hi Paul,
Got My MSDN subscription, but have been too busy to have a look at it yet, since Beta 1. Whats so good about ASP.NET? I work on a load of server side stuff, and as such like my C++. In a way I like the sound of .NET. I know when I'm doing client side stuff and I produce and install, I get the answer from users "I have not got admin rights to install this - need to call the help desk".
Go on why is it so good. I'm sure it must be, but I fear current projects will tunr me into a dinosaur in the next 6 months. Need help. I can see your the man to put me straight.
Giles
|
|
|
|
|
The beauty of ASP .NET (for me) is that no longer do I have to program in VBScript or JScript. I'm writing all my stuff in C#, and as soon as MS adds ASP .NET support to C++ I'll write my pages in that as well. All ASP .NET pages and components are precompiled. You get type safety, extensive debugging support (tracing, stepping etc), actual OOP, simple configuration of IIS via the config.web (eg security on directories, auto-restart if memory or hit counts get high), ecapsulation of visual elements via User controls, easy component reuse, access to the .NET class library, a more integrated working environment and a neat separation of visual design and backend logic (they can be worked on separately without your designers screwing up the code, or your coders screwing up the design). Plus server side event handling, automatic viewstate, cookieless session handling, improved and additional intrinsic objects (Application, Session, Cache etc). Plus you can run ASP and ASP .NET side by side.
(gasps for air)
...and you get a handy speed increase to boot.
In terms of pure server side stuff ASP makes writing ASP .NET components transparently easy. Write the component, stick the assembly in the /bin directory and viola! All the COM stuff is taken care of. You can also rite HttpHandlers (ISAPI filters) to handle special case files really easily, and when you want to install new server side components you just copy them in. ASP .NET no longer locks components, so when it sees a new one it bleeds off users from the old one, reloads the new one and continues on. No more restart hassles.
Can you tell that I am kinda keen to say good riddance to ASP 3.0 forever?
cheers,
Chris Maunder
|
|
|
|
|
All sounds rather good, maybe I'll get around to writing that web-based bug-tracking system now.
So when does CodeProject.NET go live then?
Sometime soon I hope,
Michael
|
|
|
|
|
General 
News 
Suggestion 
Question 
Bug 
Answer 
Joke 
Praise 
Rant 
Admin 
Submit an article or tip
