Slashdot Mirror
Essential .NET, Volume I
After chapter one's history of the evolution from COM to the CLR, the book takes a bottom-up approach to the CLR, starting with a deep and detailed six chapter look into the core elements of the platform. Chapter two begins with assemblies, the programmatic units in the CLR, and the implications of their construction. We learn how they are versioned, loaded and built, and why therefore they may be written in as many .NET languages as required. There's real depth to the material here -- you really do touch the bottom of the abyss, so to speak -- but it's countered with occasional levity that keeps this a readable book instead of a dense reference manual. The same is true of all the text. To wit, there's even some irony; "To allow old dogs to avoid learning new tricks, there is finalization," he declares in the next section on the Common Type System.
It's here that we discover how different types and interfaces are distinguished from themselves and from one another, and how their variations and relationships are kept separate by the CLR. It's refreshing to note that the proverbial big picture is never very far away from the commentary. After taking time to explore the avenues for types and interfaces, Box notes that types themselves aren't very interesting until you start working with instances of those types, and we're off again working through another thirty pages on how object instances preserve a sense of identity, how they are cast into other types and how they incorporate themselves into the concepts of reflection and metadata. Only then do we look at the actual lifecycle of an object, its creation, modification and disposal. The attention to detail is great, and there's little ambiguity in the text, but with that comes a slowness to this section that may leave readers frustrated.
One recurring theme of the book is the idea that while there is a very proper way and set of rules for doing things, there will always be circumstances in application development which call for exceptions to be made to those rules and made possible by .NET. This is true at a small scale and, as chapters six and seven prove, at a large one too, covering as they do how the CLR calls and runs methods first on a single machine and then over a wire. How does the runtime treat methods called explicitly, implicitly through a delegate, asynchronously, or as a combination of the three? How do remote calls and types bridge whatever gaps they must cross and activate the remote objects and methods they're targeting? The answers are here.
Essential .NET reflects Box's pride in .NET and also his slight dissatisfaction with it. You can sense that while he knows .NET version 1 is an improvement over COM, it's not as good as it could be and things are still be done in v2 and beyond. Chapter eight's look at AppDomains and in particular its discourse on threading within and through AppDomains is a good example of this. Meanwhile, we finally come full circle in our investigation of the CLR, seeing how the assemblies we built in Chapter 2 are resolved and executed within AppDomains. Exceptions to rules being included, we also see how objects references are marshaled across AppDomains for inter-application communication if this is required.
The last two chapters look at wider topics around the CLR in as much detail as they can for topics which have entire books dedicated to just them. Chapter nine covers code-access security and chapter ten topics which are not of the CLR but which be can be addressed from within a .NET application: explicit memory management, using p/invoke to import COM methods from DLLs and so on. Both are concisely written and to the point, but unsurprisingly leave you feeling like there's more to these topics than is covered here. Chapter nine is a great and clear introduction to code-level security, for example, but you'll get a lot more out of Michael Howard's book, Writing Secure Code if you want to know more.
Essential .NET isn't an easy read but everyone should try to read it at least once. Focusing on the CLR itself and how it deals with the components of an application means that it truly is aimed at the community of .NET developers as a whole (including those building and using alternate implementations of the CLR). The provided code examples are expressed in C#, but this is incidental, really, and won't stop VB.NET, J# or any other developers getting a great deal out of this book.
This is a dense, complex volume that requires a fair amount of effort to understand and use, and to some extent this may put people off. On the other hand, it is so packed with great nuggets of information that they may be inspired to keep reading. Of course, there is the question of whether this book will actually improve your .NET development skills, but in riposte, you can honestly say that no volume details the CLR and its potential so well, and that this alone is worth the book's cover price.
You can purchase Essential .NET, Volume One from bn.com. Slashdot welcomes readers' book reviews -- to see your own review here, read the book review guidelines, then visit the submission page.
nobody on Slashdot gives a RATS FUCKING ASS about fucking Winbloze shit!
.NET is slowly growing, for good or bad. If you want your family to starve to serve the OSS cause, go ahead. But, I wanna eat, dude. the 90's are gone. It is grovel time.
I don't like many aspects of the Microsoft Way either, but MS projects pay the bills better than OSS projects for some reason for me. If I was well-to-do, I might subsidize my slide over to OSS. But the tech economy is a wreck right now and I take what I can get. The demand for
Table-ized A.I.
I'm surprised that someone so focused on the evils of proprietary systems would be decrying C#. After all, C# is a ratified standard, while Java was pulled from standardization so Sun could maintain control of the language.
Before everyone starts scoffing at how much Micro$oft sucks, I just want to say that .NET is really the best product that MS has produced in a very long time. And when I say .NET I am referring to both the object library and the .NET server. /. when I say that I would rather be on a UNIX based platform, but like many of you due to my job I am forced to deal with a Windows Server environment if I like it or not, and as much as I have tried to hate it, I have actually been quite impressed with what you can do with Visual Studio and .NET .NET web application you use the same code (meaning VB.NET, C# etc, as opposed to ASP, or VB Script) that you would use when writing a desktop app, and the fist time the page is accessed, the web server compiles all the code into dll's on the fly. Converting my existing ASP apps into .NET has tripled the performance using the same hardware. This method is very very fast. Fast to develop and fast to benchmark. It would take me months to write a C/C++ cgi app to do the same thing that I can pump out in an afternoon with VB.NET. And more intuitive I might add.
I'm with the rest of
When you write a
Go ahead and flame me now.
Sigs are out of style, so I'm not going to use one...oh wait..
Jeez, as a technical community can't slashdotters resist making dumb jokes that have been made millions of times before and actually pay attention to the content of something that could be relevant to many of us? I want to see a first post that's not an easy and bad joke for once.
You know, the "registries" and "assemblies" are getting so complex that I would rather they be stored and managed in a relational database. The rules and tools for relational databases are better understood and apply to many areas, reducing one's learning curve and let's them use existing tools to analyze data and structures. I can look at the schemas and data dictionaries (schemas with extra info, such as field descriptions), and fairly quickly get a feel for how the different entities work and relate to each other.
A proprietary structure just ends up reinventing a lot of database wheels like concurrency, backups, change logging, etc., and has unfamiliar access protocols, often mirroring the "navigational databases" of the 1960's.
I know, some of you say that I have an "if all you have is a hammer, then everything is a nail" view about RDBMS (relational databases), but when structures become non-trivial, then nothing beats a RDBMS in most cases. If it walks like a database and quacks like a database, then perhaps it is time to use a database.
Table-ized A.I.
There's been a lot of talk about this in the Slashdot community of late. The serious questions - .NET or J2EE, Perl or Python, are issues that just won't go away. Sort of like whether a programming project or sex with a mare is better. You have to make up your own mind about it.
I generally dislike Microsoft products and work in a Unix shop. At the same time I can also see the blatent, mindless stupidity that permeates this site. This continual fanboy platform mentality is just one of the many things wrong with this site. Childish bashing is no way to engage in a discussion which is what this site is supposed to be all about.
You should always write web application using a platform that allows you to use the same infra-structure you use for desktop application. Besides the learning curve problem, it also helps when you wnat to mix them both ("weblize" a destop app, for instance).
That said, ASP and VB.NET are not the answer. Using non-portable languages to write web apps is a very bad idea.
It would take me months to write a C/C++ cgi app
Where are you from, 1994? If you really need unmantainable spagetthi like ASP, you can use PHP (portable across all known platforms), but you have Java (Tomcat) and Python (Zope) that allow you to use very high-level structures with a higher productivity (in my experience) than any Windows-only solution. No one writes C cgis anymore...
I'll take umbrage with the kneejerk "Java has been doing this for years" comments. Must every idea be so mind-bendingly unique to be deemed useful? Should we all start buying Ford Model-A cars instead of Durangos (or whatever) because Henry Ford "was doing that 100 years ago!"? Are the CLR-based language features a lot like Java? Yes. Should every derivative product be denounced as coming to the table too late? I think not. Once more, .NET ( the bits for developers anyway) brings some better things to the table as well (as evidenced by Sun getting into the leapfrog game with Java v.Next features - Metadata (Attributes), etc).
...that some companies still have 'Windows 5.0' on their sheets as lists of systems with operating experience, I don't see how this is relavent.
Right now 'Java' is the en vogue thing to ask for on a resume. C# hasn't reached that level yet. It's still a buzzword to the HR types.
As a rock-in-roll Physicist once said, No matter where you go, there you are.
They're running out of common terms to steal and obfuscate, aren't they?
C# and the CLI (ECMA standards 334 and 335) have no patent fees attached to it, it is completely patent free.
;-)
The ironic thing is that *today* the fastest fully open source Java VM that can run Eclipse is Mono plus IKVM.NET (the open source Java VM that generates CIL code on the flight
Miguel.
Everything you write in Java has to be written in Java. I know there are Java purists out there who may think that rocks, but it could be beneficial to be able to pick and choose languages for the task at hand. The multi-language innovation is really neat to me. Some languages make string processing a snap, some don't.
.Net, Java, manually coded Perl, whatever. It seems to me MS studied Java's strengths, copied those, added new things Java didn't think of (other language support), and avoided some of Java's pitfalls (C# is a standard, as is .Net), and that including web services is really a separate thing aside from their incorporation in Visual Studio.NET.
Web services don't have to be anything other than classes interacting through XML - isn't that enough? That's a significant advance in code re-use that I see, much more important than object oriented programming I think. So often code that has been written doesn't work for a new language version, a new business process requires significant changes and everything gets rewritten, or other incompatibilities crop up. Since the cardinal rule MS wrote for COM objects was 'the interface is sacred' (I know, do as I say, not as I do, and I agree there) that always bugged me. So now you write a web service. Can be used by all your other apps, you can port your other apps to different language/OS/etc and still take advantage of it. I don't care what technology is behind a web service, just that web services themselves are future-friendly and seem to lead to the semantic web quite nicely. MS's contribution here isn't revolutionary, but it will get more people using it. The main benefit of web services is that I don't care whether you're serving it up from
Well lets look at a few stats shall we? In 2001 according to vnunet, code red and nimda knocked out over 150,000 websites running on over 80,000 servers running IIS. The next month (according to netcraft.com statistics) approx 380,000 machines switched to Apache. Granted the vast majority of these could have just decided to run Apache on windows though this is extremely unlikely.
In January of 2003, SQL Slammer took out over 30,000 machines running SQL (alot of them unknowingly thanks to Microsoft). Even Microsoft itself was taken offline due to the worm. Since then, Microsoft has lost 1% of it's server market to Apache. Again, everyone could be using Apache on Windows, though again, highly unlikely.
I actually think I lowballed my stats by saying that 30% switched and obviously from the statictics, one can easily assume a much higher number but it is hard to take into consideration which are 'switchers' and which are new servers.
Either way, the stats speak for themselves fairly well.
This is my sig. There are many like it but this one is mine.
I'm talking transactions that do more than just insert a new order into a database. Something that actually has to coordinate a transaction across several remote systems and insure the transaction follows well defined process. Can .NET do these types of transactions? Sure, but it will require a lot of hard work and dedication to reach 1K transactions per second. If you want to reach fault tolerant transactions across a cluster of servers, you're best option today is to use Java. Microsoft officially doesn't have any plans to build a stateful application server that provides object persistence management.