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.
You're off the mark. You pick your language, the primary candidates being VB and C#. VB isn't really reccommended, it's more of a migration path for old VB users. If you're starting fresh, stick with C#.
.NET is a framework that is not tied to any specific language. ANY language could be made into a .NET language. C++, C#, ASP, VB -- these are the primary languages Microsoft has chosen to use with .NET, but any language could be used. Other vendors are already releasing .NET versions of various development tools, although off the top of my head I don't remember which ones are already out or in the works, but essentially you could have PHP.NET, Delphi.NET, Java.NET (hey, it could happen), even PowerBuilder.NET (it's in the works).
"You cannot simultaneously prevent and prepare for war." -- Albert Einstein
Yes you're off the mark.
.NET framework is just that - a framework around which you can create an application. The language you use is totally up to you. VB.net, C#, C++ are all choices you may make - you do not have to learn all of them.
.NET framework and provides a method of writing web applications that are almost the same as a standalone version.
.NET you learn the ins and outs of the framework and the syntax and grammer of the language you choose - if you decide to migrate to a different language you have the same framework.
The
ASP.net is almost a container to these languages - it highlights a few different classes of the
With
With Perl you learn Perl's syntax and grammer and learn your way around CPAN, with Python you learn Python's syntax and grammer and learn it's framework. Same with other sets of libraries and frameworks.
Matt Thompson - Actuality - Insert product here.
Well, as a developer, I think .net is pretty good. My happiness with .net goes up with the implementation of mono. .net is standardized, and open source is built on portability.
There is nothing more portable than being able to run a binary (sort of) on a host of different machines. C# is pretty good all around, it got right a lot of the things java got wrong, and choosing .net for your (windows) database app is never a bad decision, even if it may not be the best one. In a way its a lot like xml: there's a lot of hype, but the overall philosophy is good. Very unmicrosoftian in implementation.
When they get generics I will probably write all my own personal stuff in C#.
ASP.NET is not a language as much as a set of classes to use when programming for a .NET enabled web server. You can use VB.NET or C# (or any of the other implementations) to program "Web Forms", which are rendered as HTML. Thus ASP.NET is more analagous to a SDK than a language.
.NET is the framework, which provides a logical way to program for pretty much all of the functionality of todays computers and OSes. Stuff like threading, data access, graphics, etc. are rolled into convenient classes that implement "best-practices" with minimal coding required. It's a big, smart toolbox. =)
The reason there can be more than one language is that each language is compiled to a "Common Language Runtime". Really, there's just that one language, and I suppose if you were insane you could program straight tokenized CLR. But, since each language uses the same framework, it is usually fairly easy to translate between them, if you know the basic syntax.
The benefit of
Microsoft Press publishes one of the most useful books I've ever seen - "Writing Secure Code", by a MS engineer. No, stop laughing, I'm serious. It's a great book. It even goes into great detail on how important it is to force secure coding practices onto the rest of the project team, and how you have to resist the temptation to add features or push up the release date at the expense of code review and good coding practices. It's usefullness is only enhanced by the delicious sense of irony you get when reading it.
For a similar, but maybe more technical overview, see .Net Framework Essentials from O'Reilly. It's a nice short book with a good number of simple code examples. I'm about half-way through it, and I've learned a lot.
Security at Microsoft? Secure programs are secure whether you see the source code or not.
There's a growing sense that even if The Future comes,
most of us won't be able to afford it.
-- Lemmy
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.
.NET, either.
Did you read the author's bio--even the short one on bn.com?
David Chappell is Principal of Chappell & Associates and the best-selling author of Understanding ActiveX and OLE (Microsoft Press, 1996) and Understanding Microsoft Windows 2000 Distributed Services (Microsoft Press, 2000). Through his keynotes, seminars, writing, and consulting, David helps IT professionals around the world understand, use, market, and make better decisions about enterprise software technologies.
He's been published by Microsoft, fer chrissakes. He makes a living as a consultant on MS technologies. You can't possibly expect him to be coolly objective about anything coming from Redmond.
Reading the author bio will often give you a clue about his or her technology bias, although it's no guarantee that the book will provide an objective perspective. I wouldn't expect Richard Stallman to write a wholly bias-free book about
Acronyms, acronyms... For the unitiated:
WDSL Wireless Digital Subscriber Line
WSDL Web Services Description Language
UDDI Universal Description, Discovery and Integration (not Description and Discovery Interface)
ASP Active Server Page
CLR Common Language Runtime
CORBA Common Object Request Broker Architecture
OMG Object Management Group
XML eXtensible Markup Language
MSIL Micro$oft Intermediate Language
ADO ActiveX* Data Object
.NET ?
* The correct spelling is a skull-and-crossbones character in place of the X but slashdot filters out Unicode 9760
Beyond the less proprietary nature of .NET (ECMA standards, minmal tie to Win32), it's also possible to any investment of .NET with any future technology through some form of XML (SOAP, etc.)
There is no longer anything that can be done with computers that is nontrivial and clearly legal. -- Paul Phillips
While it is true that any language can be made into a .NET language, the end result could be a mess. C++, when converted into a .NET language, lacks much of the flexibility of C++. And functional languages? They are a huge pain in the ass to convert. The .NET model is lousy for languages that differ substantially from C#. That's not particularly a condemnation of .NET, mind.
Oceania has always been at war with Eastasia.
Frankly .NET is all about making it easier for the developer. The .NET Framework is there to make tedious tasks easier. Of course this is all made easier by the use of M$ tools Visual Studio.NET. Without that GUI .NET is a little harder to work with.
.NET but I found Professional ASP.NET a usefull book in teaching me about the framework and ASP.NET. I am planning on porting over my site MediaGab as soon as my hosting company supports it.
ASP.NET makes it easier on developers as well. Traditional ASP, otherwise known as "Spagetti code" was all intermixed with HTML. Now you can write your scripts in a separate file and have your controls reference the code. Also there is a whole ASP.NET community, kind of like open source, which develops controls that you plug into your VS.NET and then are able to take advantage of this new functionality by dragging the control onto your page and setting some properties.
I am still in the "learning curve" of
That's true, a lot of languages do not map well, but remember MSIL and the CLI are constantly evolving. Version 2 might bring along some more enhancements, Version 3 more so. .NET is designed with this versioning in mind, so the system can handle having multiple runtimes installed, and code can be flagged to work with specific runtimes. Similar problem with Java (people tying their code to, say, JRE 1.3.2 but not 1.3.1 or 1.3.3) Only difference is a lot of this stuff can coexist in .NET.
So the Ada code converted into java bytecode that some of my programs use is not really there?? .NET bytecode, but then again .NET forces languages to change to be compatible.
Sorry but Java is actually language and platform independent, however it is not as language independent as the
ANY language could be made into a .NET language. C++, C#, ASP, VB -- these are the primary languages Microsoft has chosen to use with .NET
.NET languages. For instance, one of the things that ASP provides is Session management. Whether you are writing in VB or C# or Managed C++, ASP will provide you with a "Session" object that it can use to store session state. This object behaves exactly the same way in all languages. It was probably written in C# (I think that's what MS uses for internal .net development) but that doesn't matter because all languages get compiled to MSIL (which is kinda equivalent to java bytecode).
.NET. The default language for ASP used to be VB... some people used JScript and there were probably a few other choices. Now, you can use any .NET language in your ASP.NET pages.
ASP is NOT a language. ASP is a framework for writing web applications. You can write ASP pages in any of the
ASP has never been a language... even before
--
"What do you want me to do? Whack a guy? Off a guy? Whack off a guy? Cause I'm married."
- The Common Language Runtime (CLR) is a virtual machine that runs intermediate code. Thus, you can write a program in Visual Basic, C#, or several other languages and compile them to the same intermediate code. The virtual machine throws in a bunch of java-inspired features, like garbage collection, absence of pointers, and a giant class library that exposes much of the harder-to-get-to aspects of Windows. Since the class library is available from any
.NET programming language, the choice between using C#, VB, or something else is mostly just a matter of whether you like semi-colons or not.
- The Visual Studio
.NET IDE provides lots of tools to "simplify" programming and debugging. For instance, if you want to make a [Microsoft] standards-compliant web service, you can go through a wizard which generates the deployment descriptors and several pages of source code, including a big comment telling you were to put your logic. Similary, if your app manipulates a database, a wizard helps you make the SQL query or create a stored procedure. Of course, these wizards create lowest-common-denominator, bloated code that is nearly impossible to modify by hand without breaking it.
- ASP.NET is a language and server for creating dynamic web pages. In theory, you can write an ASP.NET application and pretend you're just writing an ordinary client-side GUI, attaching event handlers to buttons and drop-down lists without thinking about the mechanics of HTTP Posting. In reality, this leads to constant round trips and page refreshes that are only practical on the developer's machine.
I'm sure there are several other technologies lumped in withAs far as why you should care about XML, .NET, etc., the goal (regardless of whether you think Microsoft helped move towards this goal) is to have programs that can interact with each other. Sure, XML is verbose, but it just might save me some time and heartache when I'm trying to parse through your data that's in a flat text file, or worse yet, locked up as a binary file inside your proprietary database.
The book is a good survey of the very large .net world. It is not an in-depth view of any particular part, but gave me a very good overview of just what the parts *are*, so I could build a conceptual framework on which I could hang the detailed knowledge I got from other books. It was a quick read, too. .net is a bunch of different things, including languages, language-independent libraries, a virtual machine, and standards for interoperability. The book covers all of that, walking the line between "too high-level to be useful" and "too detailed to grasp easily". It is trying to cover several different audiences, and succeeds pretty well, I think.
.net system and how it all fits together, and have a good base for the rest of the knowledge you need to collect.
The book has "executive overview" summary sentences beside each paragraph, which are obviously aimed at, well, executives. But at the same time, the paragraphs themselves have good solid information about how the CLR works, how the libraries are structured, how VB.NET and C# are similar and where they differ, including actual code examples. It makes you aware of what pieces are out there, so when you need an encryption algorithm (for example), you know there are some standard library routines you can check out before coding one from scratch.
Don't get the book if all you want is a C# reference (get the O'Reilly book for that). As a matter of fact, don't get the book if you want a really in-depth discussion of any particular part.
*DO* get the book (or borrow it from the library, like I did) if you want to know more about the whole
"NET is the Sun/Java 'write once, run anywhere' concept done right because it's:"
.Net web applications against broken, obfiscated J2EE implementations though. They tend to suggest that you can use 10x the LOC and still only be 2x slower. Sounds to me like Java cat run 5x more code per clock. I don't doubt the UI will be faster for .Net when you write a GUI. No faster than SWT, but faster than Swing by some ammount. .Net programs will start faster because it will be loaded at boot time like explorer(22M). Java will have this capability, and shared VM capability soon though, and most of my Java programs, with the VM, only use 11-14M of RAM.
--Oh really?
"- Language Independant (although I would agree that C# seems best suited to it for me)"
There are even LISP compilers for Java. If you haven't found what you are looking for, you just haven't looked hard enough.
"- Potentially Platform Independant (not yet, maybe not soon, but possible - well done to the Mono team)"
No it's not. Not as much as Java. Looking at the way MS treated Java (changing the core java.* libraries) I doubt it ever will be. You'll have to excuse me for looking at MS's track record to gauge their future conduct instead of fairy-tale hype told to managers to try to persuade them to buy.
"- Generally runs faster than Java on Windows ('big surprise' you say - but see how Mono goes)"
No it doesn't. As far as I can tell, MS really doesn't want to benchmark this at all. There have been no C# vs anything benchmarks. Not even the falsified for the public kind. There have been benchmarks of 2.5 Tier
Karma Clown
Which just shows how little you understand of Microsoft's SOAP framework. The .Net Framework supports SOAP encoding, but it is done in a very general pluggable encoder class hierarchy.
.Net (SOAP) framework.
Microsoft provides a SOAP formatter, and a high-density binary RPC-like encoding. Even if this RPC encoding is not the same as the SOAP RPC encoding, it will only take Microsoft a single service release to update it, and bring it into conformance with any SOAP/RPC specification -- if Microsoft chooses to do so.
You can even write your own encoders, and slot those into Microsoft's existing framework! For example, the SOAP encoder is a class called SoapFormatter. The binary RPC formatter is called (surprisingly) BinaryFormatter. But they both implement IFormatter and IRemotingFormatter -- and that interface is publicly documented. Anyone can write a class that implements IFormatter, and slot their class right into the ASP
You should really try to understand things more before you just attack them. And I don't see at all how this is "biting" Microsoft, given their very flexible, extensible platform.
Main J# page
J# download page (free!)
J# is a free download because it is an add-on to Visual Studio .Net (which isn't).
Mono does alot more than just ASP.NET it also does Windows Forms.NET and all the other essential class libraries. So .NET already has good coverage on the Linux platform.
Development of support for .NET on OS X is already underway so there's a likilhood .NET will soon offer cross platform solutions for Windows, Linux and Mac which is pretty much the entire desktop market.