Slashdot Mirror
Understanding .NET: A Tutorial and Analysis
Firstly, this book doesn't attempt to act as a programming tutorial, and as a result is thin on code examples. Instead, the book takes a highly summative approach to the main technologies of the framework, broadly dividing them into: web services, the CLR and languages, the class library, data access, ASP.net and .NET my services.
Having said this, the central theme through the book is that of XML and web services, accurately reflecting their importance in the .net framework. It frustrates me how web services are often described as revolutionary, when built on technologies such as UDDI and WDSL which in turn are based on relatively mature technologies such as XML and HTTP. This book falls into the same trap of pandering to the hype surrounding web services, without really managing to convince me of what is so revolutionary about them.
The author dedicates a chapter to a summary of the main .NET languages, Visual Basic .NET, C#, and the managed extensions of C++. The author concludes that "Managed C++ adds even more complexity to an already complex language." Some may have reservations with this statement; garbage collection, interfaces, attributes and the managed types are only likely to result in less work for the developer even after a relatively short learning curve. The author appears to come out in favour of C# over the "more complex" Visual Basic. I would like to have seen some discussion on other .NET languages under development.
The chapter on the class libraries makes a relatively good job of summarising the massive .NET libraries. It's a fleeting overview of the most useful and interesting parts of the libraries. Remoting (remote method calls), reflection and the ubiquitous GUI libraries are just a few examples. This is one of the stronger sections of the book in my opinion, though this is coming from a developer's perspective.
There is a concise chapter on ADO .NET. The author acknowledges the fact that this is the latest in a long line of Microsoft data access libraries but fails to indicate why this one is better. The controversial .NET My Services is also detailed. The book doesn't really ponder the politics surrounding My Services, which is surprising as this element was always likely to be its downfall.
In parts, this book is overwhelmingly pro-Microsoft. In a particularly gushing moment, the author implies that COM was successful in its goals of interoperable component software, only failing to reach critical mass due to a failure by other vendors to support it. OMG's corba on the other hand was based on an incomplete standard, destined to failure due to Microsoft's decision not to support this 'doomed' standard. I would whole-heartedly disagree with this. Firstly, the distributed object technologies of CORBA are applicable to a different range of problems. Even overlooking the validity of this comparison, CORBA has seen massive support and is generally considered to be more successful than COM.
On a more positive note however, this book does provide isolated moments of insight. Some of the sidebars, for instance, tend to delve a little deeper, providing a little bit of the insight I was hoping to gain by reading this book. A brief look at the differences between MSIL and Java's VMs for instance led me to research further. Apparently future versions of SQL server are set to host a version of the .NET CLR natively, similarly to how Oracle 9i can run its own Java VM. For me, these insights go beyond the information which I could have picked up on any number of white-papers out there on the net.
In hindsight this book is perhaps too shallow, falling into the trap of using a barrage of acronyms and buzzwords without delving deep enough into any one topic. There is no mention of cross-language interoperability, and more importantly no mention of cross platform interoperability efforts -- which do exist. Also, even with a book so Microsoft oriented, I would expect to see either a distinct section, or at least more comments, on the pitfalls and barriers to takeup of the framework. A more critical and less Microsoft-centric text would for me have made this book more authoritative.
Table Of Contents
Preface
1. An Overview of .NET.
2. Web Services.
3. The Common Language Runtime.
4. .NET Languages.
5. The .NET Framework Class Library.
6. Accessing Data- ADO.NET.
7. Building Web Applications- ASP.NET.
8. .NET My Services.
Conclusion
You can purchase Understanding .NET: A Tutorial and Analysis from bn.com. Slashdot welcomes readers' book reviews -- to see your own review here, read the book review guidelines, then visit the submission page.
I might buy this book, except my managers won't touch .net with a ten foot pole, as once your in, you apparently can't get out.
"I only speak the truth"
Karma: null(Mostly affected by an unassigned variable)
"less-Microsoft oriented.."
.NET implementation, this book is about .NET...
Hrm. MS invented the technology, there's no complete "alternative"
I'm just not sure how this couldn't help but be "Microsoft" oriented.
If you were me, you'd be good lookin'. - six string samurai
The publisher appears to be Pearson Education, and not Microsoft Press, who really isn't trustable anymore in my opinion. I'm kind of surprised that they're reviewing a book that is a year old now, as far as Microsoft-oriented books go, this is almost an antique.
IBM had PL/1, with syntax worse than JOSS,
And everywhere the language went, it was a total loss...
Except for the minor problem that web services are not a central theme of the .NET framework. They are there, and they are well supported, but the majority of the framework would work unchanged if they didn't exist or are not used.
Slashdot quality declines as the number of hot grits posts decreases. - Provolt's Law, Apr-09-2005
Ha, What's even funnier is that the .NET version of bytecode (ala Java) can be easily reverse-engineered. So in a sense, all .NET applications are "Open Source".
A language replacing an operating system? I don't think .NET will replace anything. Its like when C++ came out. It didn't stop people from using C. .NET is useful and easy, but it has more overhead than a lot of stuff out there.
Microsoft's core DLLs were most likely written in C/C++ and will remain that way for many, many years.
When boasting the greatness of .NET, you should consider this: What language was used to compile the framework?
Yet another signature that refers to itself. The irony and humor is dead.
Once I got "in" .net, I began doing everything in my power to keep from ever having to use VB6, VBScript, and/or "ASP Classic" ever again. The improvements are too great for me to go backwards unless I absolutely have to. Luckily, most of my clients are worried about the results more than the technologies used so I get to make that call.
The truth doesn't care what I think.
You're on the mark. Many vendors have, in the past, claimed, for marketing reasons, to have systems language-neutral.
.NET. As time goes on, they'll strategically shift the sands and the preferred .NET languages will change according to marketing strategy and the current competitive situation.
But anyone who's ever tried seriously to program under VMS in anything but FORTRAN... or under UNIX in anything but C... knows that there is always a STRONG orientation to one preferred language. All the others are left sucking hind tit. A few key API's will be missing because the data structures don't match, there will be bugs that don't get high priority because "most of our customers" are using some other language, and so forth and so on.
A vendor can either be upfront about what the preferred languages are, or can hide this. Particularly in the early stages of adoption, vendors will claim neutrality.
Remember how Windows NT was supposed to be processor-independent and was supposed to run on about six different processor architectures? That's because, at the time, they wanted to deprive decision-makers of any reason not to adopt NT. Once it was established, the implementations for all non-Intel platforms evaporated fairly quickly (Alpha, MIPS) or somehow never quite got done (Power PC).
Microsoft claims language neutrality and is vague about what the preferred languages are because they want to counter any language-specific objection to
Microsoft wants you to learn their current flavor-of-the-month. And Microsoft wants to keep you busy "running to stay in the same place," so that all your learning bandwidth is absorbed by keeping up to speed on Microsoft technology, leaving none to investigate alternatives.
.NET is language independent, platform centric.
Java is language centric, platform independent.
"There is nothing more portable than being able to run a binary (sort of) on a host of different machines" Which is just what you can't do with .net - or can you send me a binary I can run on my Mac, Linux box and Win2K box?
"My happiness with .net goes up with the implementation of mono. .net is standardized, and open source is built on portability. "
From what I've heard its almost impossible to write anything in .net without using the Windows API as well.
So you'll end up with Windows .net Apps that are no more portable than at present, and Open Source Mono apps that run well on all platforms with a recompile (just like most current Open Source Apps).
Languages are differnt. So they both compile into an IL? Big deal. Yes, it's nice that all languages on the .NET framework have access to the powerful class library, and all run on the CLR so that you can use a VB.NET DLL with a C# DLL (because in the end they're really just IL DLL's). However, the IL that VB.NET generally create's is a mess - especially if "option strict" is off, making it a loosely typed language.
Of course, you have the minor language features (not used most of the time) like "safe" pointers that makes C# nice to have as well.
So allthough the languages are a lot closer than ever, they still are different languages, and the differences do go beyong curly braces and verbose declarations.
There is no longer anything that can be done with computers that is nontrivial and clearly legal. -- Paul Phillips
Access to source code results in insecurity as the viewer may find holes in your application that they can exploit
Not having access to Microsoft's source code sure prevented the script kiddies from finding all the holes they've found so far in MS products...
I pledge allegiance to the flag...
of the Corporate States of America...
That's a negative, Roger.
ILDASM is the tool to use to disassemble an assembly, and the result is MSIL in readable form. Nothing i386 to it.
It's as much disassembling as any non-MSIL binary would produce. Has nothing to do with security.
Dave
It's a shame so many people are taking this "oh god don't lock us in" stance. To me, and people will disagree with this, .NET is the Sun/Java 'write once, run anywhere' concept done right because it's:
I've been in this industry too many years (over 20) to ever believe that there will happen to be a true cross-platform write once run anywhere application platform. The closest thing we've ever seen, and will ever see is *nix... and that's just the OS, not the apps. Everything else is just a kludge, and as long as there exist multiple platforms manufactured by different business competitors, there will *never* exist such an animal as true cross-platform runability for one single app. Of course our friends up northwest are certainly doing everything they can to eliminate that nasty problem of the existance of multiple business competitors.
Why use .NET? I am happy with my Mac OS X running Apache and FileMaker for the web. A little Perl, a few Java applets, what more do I need? If there is a reason for me to move my site to .NET please let me know. Is it worth the learning curve?
Becasue (historically speaking) Apple never, ever has ever been a business operating system. Sure you could hook up Mac's over the ages to the network and the internet, but the security of the Mac's resembled swiss cheese. Full of holes.
Starting with Apple ][e, can you imagine what Apple would have been like today if Jobs hadn't been such a brat about not letting 3rd companies have access to the OS source code for developing various technologies? This is probably the biggest mistake that Jobs made over the course of Apple's history.
This may be a bitter pill to swallow and will probably be flame bait for Appleheads, but it's the truth. Why do they consistently advertise digital movie making packages on their web site?
Last time I checked, you were allowed to use Microsoft products AND read Slashdot....
It's comments like these that frighten average people away from Linux. The 'RTFM' and 'Bomb Redmond' attitudes have got to go, or Linux will rot. Linux-nazis are probably more harmful to the promotion of Linux than any of it's technical deficiencies. Don't get me wrong, I love the idea of Linux, and it's come a long way, but the aggressive power trip of some linux zealots makes being a linux newbie really suck.