follow nigelwatson at http://twitter.com
Welcome to MSDN Blogs Sign in | Join | Help

shlock (1) - Nigels Retrospective

Nigel Watson, an Architect Advisor at Microsoft, based in Melbourne Australia.
Back to the blog...

I attended a session on blogging at Microsoft Melbourne today, conducted by none other than my good friend and colleague Dave L.  Made me feel guilty about not having made any entries here lately.  So here you go.  Actually I'm _really_ in the mood to write a bit more, especially now that PDC is around the corner and I can start talking about some of the new technologies we'll be announcing this week.  I've been itching to discuss some of these and look forward to blogging about them in more detail soon.  No hints yet though... :)

In the meantime, I've been thinking a lot about Enterprise Library V2.0, especially after presenting on EntLib V1.1 at TechEd with my friend (and community rocket scientist) Martin Granell of Readify.  One of the things that's become really clear to me is the role Enterprise Libary fills in the developer ecosystem.  In particular, EntLib is - for all intents and purposes - technospack.  What are the gaps that need spacking, I hear you ask?  The gaps are the spaces between what we'd like the .NET framework to do natively, and what it can do right now.  Take .NET fx 1.1, for instance.  We'd like it to provide a nice framework for auto-updating app binaries in the wild.  It didn't, so we got the application updater block, which has now become ClickOnce in Fx2.0.  How about nice, polite management of configuration files?  Nix on Fx1.1, so we get the Config Block in EntLib 1.1.  And, interestingly enough, most of that functionality is now embodied in System.Configuration in Fx2.0.  Same for Logging and Instrumentation (similar functionality now exists in System.Diagnostics in 2.0) and the Security Block - most functionality now being provided in the ASP.NET 2.0 security provider model.

I dunno if I'm being paranoid, but I see a pattern here.  EntLib addresses gaps between the native framework and what we need in the real-world.  EntLib revs more quickly than the underlying framework, but then the framework eventually catches up.  What becomes of EntLib then?  Interesting question.  I think the answer to that is 'move the ladder up a notch and spack the next layer of gaps'.

Posted: Monday, September 12, 2005 11:17 PM by shlock
Filed under:

Comments

No Comments

New Comments to this post are disabled
Page view tracker