Phwew!  I just moved yesterday (actually all weekend and yesterday and still more unpacking to go now!).  Man, all that moving is starting to wear, but we're very happy in the new place.  A lot more space to make room for number four! :)

On to the point.  Josh Smith has extended his Podder skinning competition.  For those who don't know, Podder is this nifty WPF-based podcasting client/player.  He designed it so that you can completely change the look and feel using skins.  I suggested a better term would be skeletoning, since you can change the structure in addition to the styling, but so far that hasn't caught on.  Be sure to tell him you think that's a better term!

A few buddies of mine, Phil Winstanley and Dave Sussman, have asked me to pass along that they're doing an upcoming DeveloperDeveloperDeveloper event in Galway, Ireland on 3 May.  So on the off chance I have some readers in that area, I figured I'd pass it along.

Enjoy!

For those of you that don't keep an eye on my work blog, my team at Infragistics just published a new Silverlight 2 sample application, faceOut, using prototypes of Infragistics' Silverlight controls.  If you're interested in Silverlight 2 and/or interested in what Infragistics is doing with Silverlight, you should check it out.

I've been getting friendly with Windows Live lately, and after getting terribly tired of having to switch to HTML view in Windows Live Writer in order to insert a note (could be a footnote or endnote depending on how you look at it), I decided to see if I could write a plug-in to make my life easier.

So was born the Blog Notes plug-in.  Unfortunately, there is no extensibility for just marking up existing text (e.g., adding a superscript button to the markup toolbar), so I had to go with the option to insert some HTML using the  interface.  I really was trying to keep it simple and lightweight (for my own sanity), so it is pretty basic.

The functionality is pretty straightforward.  Thanks to Mark James for the free icons.  Once the plug-in is installed, you should see an "Insert Blog Notes..." option in the Insert pane on the right side as shown below.

Clicking on it brings up the Blog Notes dialog:

Clicking "New Note" will insert a new superscript number (the next one in the sequence).

Clicking "Reference Note" will insert the selected number as superscript.  You can also just double-click the number to do that.

The "Notes Section" button will insert a notes section.¹

Lastly, "Write Note" simply adds the selected note plus a period and couple spaces.

As you can see, it's pretty basic, but it saves a few seconds for each note (assuming you bother to switch to HTML view, find the number, and put  tags around it like I do [did]).  You can also tweak one option/setting.  Go to Tools -> Options, and select the Plug-ins tab:

Clicking Options... on the Blog Notes plug-in brings up a tres simple dialog:

This one option will toggle whether or not the plug-in uses in-page anchor links for the notes so that the superscript numbers would link down to the corresponding note in the Notes section.  I originally added this feature without realizing the implications.  Because blog posts are often aggregated and otherwise viewed in unexpected places, using in-page anchors is iffy at best.  Community Server seems to strip them out, and dasBlog keeps them, but since it emits a <base /> tag to the site root, all of the anchor links are relative to the site homepage instead of the current post, which effectively renders them useless.  I looked at the dasBlog code where this happens, and it's in the core assembly.  I was concerned what side effects changing it to use the current URL would have, so I didn't do that.  But if you have blog software that will let you use this feature, by all means, enjoy!

Caveats

• Because of the way the plug-in framework works, I use a static/shared collection to keep track of the notes.  This means it acts a tad goofy if you close out of Live Writer or write multiple posts while it is open.  If you close and come back to a post, the notes count is reset.  To "fix" this, just re-add however many notes you had (if you want to bother).  If you write multiple posts, you just have to deal with it.  I don't know if there is post-local storage for plug-ins, but I didn't have time to dig into it.
• Your mileage may vary.  I wrote this mainly to save myself time and get familiar with the Live Writer extensibility model, so it ain't a finished product to be sure.

Get It!
Since there are numerous tutorials on the Web (that I learned from) to write Live Writer plug-ins, I won't go into those details here, but you're welcome to download my code and learn from it directly if you want.  I think I have comments and such in there.

• Download the Plug-in Only - If you just want to use this plug-in, this is what you want.  Drop the DLL into your plug-ins directory and go (typically C:\Program Files\Windows Live\Writer\Plugins).
• Download the Source Code - This is a VS 2008 solution for those who want to learn, enhance, extend, whatever.  The license is more or less the MIT license.  You'll need Live Writer installed to reference its API.

Notes
1. This is the "Notes Section."  The button adds the "Notes" header and writes out any existing note numbers.

Far be it from me to put words in Phil's mouth, but I hope that folks recognize that his post about favoring composition over inheritance is not specifically about that one best practice (the comments seem to indicate this is being missed).  It's pretty clear to me that the thrust of that post is around a philosophical approach that he thinks the ALT.NET community should make.

Two things stand out from Phil's post in this respect: 1) don't appeal to authority, and 2) don't organize yourself around a set of technical principles (best practices), but rather organize yourself around the non-technical values of independent thinking and desire to improve.  I hope that everyone can agree that these latter two values are good ones that should indeed be encouraged.

That said, should a community like ALT.NET eschew forming a more formal consensus on technical best practices?  I tend to think not.  While independent, critical thinking is valuable, it is not the summit of perfection.  The summit of perfection, in the realm of ideas at least, is conformance with truth (what actually is versus what I think is), and independent thinking at odds with what is true is not only not valuable in itself, it can be downright detrimental. 

For instance, what if you independently and critically think that security and privacy are not important aspects of the online banking application you are tasked with building?  Is that kind of independent, critical thinking valuable in itself?  Or will it potentially lead to great harm?  Independent, critical thinking is valuable only in as much as it deepens one's understanding of and conformance to truth.

So I think that there is value in a community such as ALT.NET expending the effort to define principles through critical thinking and argumentation that it will hold up as ideals, i.e., things that seemed to be most in accord with the truth as we know it.  This is where things like patterns and best practices come into play; it is the shared, accumulated wisdom of the technical community.

Now what about the broader idea of eschewing appealing to authority?  Far be it from me to claim to be an authority in logic, but it seems to me that all appeals to authority are not invalid (the wikipedia article Phil links to discusses this to some degree but does not go far enough, in my estimation).  The valid reasons for appealing to authority are discussed at the bottom of that article: 1) not enough time and 2) concern at one's ability to make the other understand the reasoning underlying the truth being expressed.

In terms of logic, it is not a fallacy to appeal to an authority on a topic that is accepted by all those involved in an argument.  We're talking about presuppositions here, and without them, we'd never get anywhere in our search for truth.  If you always have to argue from first principles (if you even acknowledge those), you simply get stuck in a quagmire.  In terms of the topic at hand, if folks accept (as they generally do) that the GoF et al are authorities on the subject of OOD, then it is valid, logically speaking, to appeal to their authority to establish the principle that you should favor composition over inheritance.

The thing to watch out for in appeals to authority is 1) thinking that the authority is incapable of being wrong and 2) ensuring that the parties involved accept the authority.  With the latter, you simply cannot argue (or at least the argument won't carry weight) from authority if the authority is not accepted.  With the former, unless it is a presupposition shared by those involved that the authority is indeed infallible, you should keep in mind that even if you buy into the authority's credentials, it is still possible that the authority can be wrong.

So I would nuance what Phil says and say that if the ALT.NET community agrees that GoF is an authority, it is valid to appeal to them, while remaining open to criticism of the concepts involved (even those backed by an authority).  The authority adds logical weight; it does not impose absolute authority.

We just don't have time to argue everything from first principles.  Others who are generally acknowledged to be qualified have already taken the time to research, think about, and propose some good patterns and practices, and unless there is good reason to object, there is no need to rehash those.  Instead, I'd suggest that the community focus on spreading knowledge of these patterns and practices all the while refining them, functioning essentially as a group in the way that Phil recommends individuals function--thinking critically and always working to improve.  Doing this will help ensure that the community does not fall into a quagmire of unnecessary argumentation, and it will ensure that the patterns and practices that they agree upon can be continuously refined and enhanced as new technologies emerge and greater wisdom is gained over time. 

Further, it gives the group a purpose that has meaning.  After all, if the group's message is only "think for yourself and be all that you can be," there isn't much of substance to say after that.  On the other hand, because it is a technical community that espouses that philosophy, it should take that philosophy on itself (as a group, not just the individuals in it).  I would suggest this includes establishing greater consensus on best practices and patterns and then spreading the word about them to others.  Be better together. :)

You see, it is not about setting down an infallible manifesto and excluding those who disagree, which is I think more than anything what Phil is concerned about.  However, it also isn't about best practices just being true for you but not for me (best practices relativism?).  Put another way, I suggest ALT.NET should favor thoughtful adherence to best patterns and practices, not blind adherence.

As I sit here on my deck, enjoying the cool autumn breeze¹, I thought, what better thing to write about than Web services!  Well, no, actually I am just recalling some stuff that's happened lately.  On the MSDN Architecture forums and in some coding and design discussions we had this week, both of which involve the question of best practices for Web services.

Before we talk about Web services best practices, it seems to me that we need to distinguish between two kinds of application services.  First, there are the services that everyone has been talking about for the last several years--those that pertain to service-oriented architecture (SOA).  These are the services that fall into the application integration camp, so I like to call them inter-application services. 

Second, there are services that are in place to make a complete application, such as logging, exception handling, data access and persistence, etc.--pretty much anything that makes an application go and is not a behavior of a particular domain object.  Maybe thinking of them as domain object services would work, but I fear I may already be losing some, so let's get back to it.  The main concern within this post are those services using within an application, so I call them intra-application services.

It seems like these latter services, the intra-application ones, are being often confused with the former--the inter-application services.  It's certainly understandable because there has been so much hype around SOA in recent years that the term "service" has been taken over and has lost its more generic meaning.  What's worse is that there has been a lot of confusion around the interaction of the terms Web service and just plain service (in the context of SOA).  The result is that you have folks thinking that all Web services are SO services and sometimes that SO services are always Web services.

My hope here is to make some clarification as to the way I think we should be thinking about all this.  First off, Web services are, in my book at least, simply a way of saying HTTP-protocol-based services, usually involving XML as the message format.  There is no, nor should there be, any implicit connection between the term Web service and service-oriented service.  So when you think Web service, don't assume anything more than that you're dealing with a software service that uses HTTP and XML. 

The more important distinction comes in the intent of the service--the purpose the service is designed for.  Before you even start worrying about whether a service is a Web service or not, you need to figure out what the purpose of the service is.  This is where I get pragmatic (and those who know me know that I tend to be an idealist at heart).  You simply need to determine if the service in question will be consumed by a client that you do not control. 

The reason this question is important is that it dramatically affects how you design the service.  If the answer is yes, you automatically take on the burden of treating the service as an integration (inter-application) service, and you must concern yourself with following best practices for those kinds of services.  The core guideline is that you cannot assume anything about the way your service will be used.  These services are the SO-type services that are much harder to design correctly, and there is tons of guidance available on how to do them².  I won't go in further depth on those here.

I do think, though, that the other kind of services--intra-application services--have been broadly overlooked or just lost amidst all the discussion of the other kind.  Intra-application services do not have the external burdens that inter-application services have.  They can and should be designed to serve the needs of your application or, in the case of cross-cutting services (concerns) to serve the needs of the applications within your enterprise.  The wonderful thing about this is that you do have influence over your consumers, so you can safely make assumptions about them to enable you to make compromises in favor of other architectural concerns like performance, ease of use, maintainability, etc.

Now let's bring this back to the concrete question of best practices for intra-application Web services.  For those who are using object-oriented design, designing a strong domain model, you may run into quite a bit of trouble when you need to distribute your application across physical (or at least process) tiers.  Often this is the case for smart client applications--you have a rich front end client that uses Web services to communicate (usually for data access and persistence).  The problem is that when you cross process boundaries, you end up needing to serialize, and with Web services, you usually serialize to XML.  That in itself can pose some challenges, mainly around identity of objects, but with .NET, you also have to deal with the quirks of the serialization mechanisms.

For example, the default XML serialization is such that you have to have properties be public and  read-write, and you must have a default constructor.  These can break encapsulation and make it harder to design an object model that you can count on to act the way you expect it to.  WCF makes this better by letting you use attributes to have better control over serialization.  The other commonly faced challenge is on the client.  By default, if you use the VS Add Web Reference, it takes care of the trouble of generating your service proxies, but it introduces a separate set of proxy objects that are of different types than your domain objects.

So you're left with the option of either using the proxy as-is and doing a conversion routine to convert the proxy objects to your domain objects, or you can modify the proxy to use your actual domain objects.  The first solution introduces both a performance (creating more objects and transferring more data) and a complexity (having conversion routines to maintain) hit; the second solution introduces just a complexity hit (you have to modify the generated proxy a bit).  Neither solution is perfectly elegant--we'd need the framework to change to support this scenario elegantly; as it is now, the Web services stuff is designed more with inter-application services in mind (hence the dumb proxies that encourage an anemic domain model) than the intra-application scenario we have where we intend to use the domain model itself on the client side.

If you take nothing else away from this discussion, I'd suggest the key take away is that when designing Web services, it is perfectly valid to do so within the scope of your application (or enterprise framework).  There is a class of services for which it is safe to make assumptions about the clients, and you shouldn't let all of the high-falutin talk about SOA, WS-*, interoperability, etc. concern you if your scenario does not involve integration with other systems that are out of your control.  If you find the need for such integration at a later point, you can design services (in a service layer) then to meet those needs, and you won't be shooting yourself in the foot trying to design one-size-fits-all services now that make so many compromises so as to make the app either impossible to use or very poorly performing.

My own preference that I'd recommend is to use the command-line tools that will generate proxies for you (you can even include a batch file in your project to do this) but then modify them to work with your domain model--you don't even need your clients to use the service proxies directly.  If you use a provider model (plugin pattern) for these services, you can design a set of providers that use the Web services and a set that talk directly to your database.  This enables you to use your domain model easily in both scenarios (both in a Web application that talks directly to the db as well as a smart client that uses Web services). 

It requires a little extra effort, but it means you can design and use a real domain model and make it easier easier to use by hiding the complexity of dealing with these framework deficiencies for consumers of the domain model.  This is especially helpful in situations where you have different sets of developers working on different layers of the application, but it is also ideal for use and reuse by future developers as well.

One of these days, I'll write some sample code to exemplify this approach, maybe as part of a future exemplar.

Notes
1. The weatherthing says it's 65 degrees Fahrenheit right now--at 1pm!
2. My observation is that it is safe to assume that when other people talk about services and Web services, these are the kind they're thinking of, even if they don't make the distinction I do in this post. 

I wasn't going to post about it, but after reading Don's post, I realized that I should so that I can thank those involved in presenting me with this honor.  I was surprised when I was contacted about being nominated to be an INETA speaker, and I was even more surprised when I heard that I'd been voted in.  Looking over the folks on the list, I feel hardly qualified to be named among them.

So without further ado, let me thank David Walker (who's an all around great guy and VP of the Speakers Bureau), Nancy Mesquita (who I've not had the pleasure to meet personally but has been very helpful in her role as Administrative Director), as well as everyone else involved on the Speaker Committee and others (whom I know not of specifically) in welcoming me into the INETA speaker fold.  It's a great honor--thank you. 

Now, I have to get back to work!  My group, UXG, just released Tangerine, the first of our exemplars, and now we're on to the next great thing!

Are you passionate about software development?  Do you love to share your knowledge with others?  Do you like working in a vibrant, fun culture working on the latest and greatest technologies with other smart and passionate people?  If so, I think I may have your dream job right here.

We're looking for another guidisan to help craft guidance using best practices for .NET development.  The word guidisan ('gId-&-z&n) comes from a blending of "guidance" and "artisan," which really speaks to the heart of the matter.  We're looking for software artisans who have the experience, know-how, and gumption to explore strange new technologies, to seek out new applications and new user scenarios, to boldly go where other developers only dream of going in order to provide deep, technical guidance for their colleagues and peers.

What do guidisans do? 

• Help gather, specify, and document application vision, scope, and requirements.
• Take application requirements and create an application design that meets the requirements and follows best known practices for both Microsoft .NET and Infragistics products.
• Implement applications following requirements, best practices, and design specifications.
• Create supplemental content such as articles, white papers, screencasts, podcasts, etc. that help elucidate example code and applications.
• Research emerging technologies and create prototypes based on emerging technologies.
• Contribute to joint design sessions as well as coding and design discussions.

What do I need to qualify?

• Bachelor’s Degree.
• 4+ years of full-time, professional experience designing and developing business applications.
• 2+ years designing and developing.NET applications (UI development in particular).
• Be able to create vision, scope, and requirements documents based on usage scenarios.
• Demonstrated experience with object-oriented design; familiarity with behavior-driven design, domain-driven design, and test-driven development a plus.
• Demonstrated knowledge of best practices for .NET application development.
• Accept and provide constructive criticism in group situations.
• Follow design and coding guidelines.
• Clearly communicate technical concepts in writing and speaking.

If you think this is your dream job, contact me.  Tell me why it's your dream job and why you think you'd be the next great guidisan.

Thanks to all who came to my "suave sessions" session yesterday at Tampa Code Camp.  Now you're all "it getters," and you get some free code, too.

Download the Session Management Code

Enjoy!

 Essential Windows Presentation Foundation is precisely what the title says it is.  What more can you ask for in a book?  There are already several books on the RTM of WPF, and there are bound to be more.  The unique value this one has is that it is written by Chris Anderson, who as most know, was an instrumental architect in designing WPF, and this (along with his direct connection to the others who worked on it) gives him insight that you just otherwise can't get. 

In particular, I like that he often provides the thinking that went into particular design decisions.  He readily admits in several places that the design of this or that was hotly debated, and one can only imagine that they would be.  Having worked at a few commercial software vendors myself, I know how difficult it can be to know the best way to design a thing, and it can only be more challenging as your audience widens. 

After this, the main thing that makes the book valuable is that it is deeply conceptual.  The point of the book is not to be a reference, a recipie book, or a smattering of tutorials.  Rather, the book provides, in a coherent form, the key principles underlying the different aspects of WPF.  And by elaborating these principles, Chris establishes a strong sense that the Foundation was designed in a similarly coherent manner.

My favorite chapters were the one on Data, the one on Actions, and the Appendix.  For a solutions architect and developer, these I think provide the most interesting meat.  Of course, these types will likely want to delve into the first three chapters as well.  In fact, the only one that I'd suggest you can probably get away with skipping is the one on Visuals; I found this one pretty dry and hard to push through.  Designers and those more interested in graphics per se will likely enjoy these.

The chapter on Styles took me by surprise, but then, that's because the concept of styles in WPF is a tad surprising.  Being the language-oriented person that I am, I am a bit bothered by the choice of Style to encompass everything that you can do with styles in WPF.  Needless to say, it's not just UI goodness--devs will need to be pretty familiar with this stuff.

Other than that, my only contention is with the assertion that apps today are all about data.  This won't come as a surprise to those who've read my articles or talked to me about architecture much, but despite my philosophical objection, when it comes to UI, I'll admit that LOB apps are in fact largely about the data, i.e., largely about displaying and manipulating data since thus far, we seem to have mainly used computers to help with data storage and retrieval.  In any case, it is certainly important to have good data binding mechanisms in the UI, and I have to say, WPF nails this better than any UI tech I've bumped into thus far.

But I digress.  The book is good; I recommend it as a starting point or to complement other WPF learning resources.  It is the essentials with which you can start effectively creating WPF applications.  You'll need the docs and/or other more comprehensive books to really figure it all out, but you should read this one regardless.

Don't forget!  This Saturday is NYC Code Camp III!  Unfortunately, I won't be able to make it as I'm helping to prepare for our upcoming 2007 Volume 1 launch next week.  We've got some great stuff in the works from the User Experience Group, so keep an eye out for it. :)

It's that time again.  Time for the SYS-CON Readers' Choice Awards voting.  Actually, it's been that time for a little while now; I'm just slow.

Infragistics has been nominated for several categories in several publications, so if you like Infragistics or even if you're looking for a way to kill a few minutes at the airport, go vote for us.

Here's your friendly voter's guide to make your life easier (note that if you don't know or prefer any choice in a particular category, you can just click Continue to move on):

http://java.sys-con.com/general/readerschoice.htm

#11 - NetAdvantage for JSF

#12 - NetAdvantage for JSF

#20 - JSuite

#24 - NetAdvantage for JSF

#28 - NetAdvantage for JSF

http://soa.sys-con.com/general/readerschoice.htm

#4 – NetAdvantage for .NET

#14 – NetAdvantage for .NET

http://webddj.sys-con.com/general/readerschoice.htm

#3 – NetAdvantage for ASP.NET

#6 – Infragistics Training and Consulting

#7 – Infragistics Training and Consulting

#8 – NetAdvantage for ASP.NET

http://dotnet.sys-con.com/general/readerschoice.htm

#3 – NetAdvantage AppStylist

#4 – Infragistics Training and Consulting

#5 – Infragistics NetAdvantage for .NET

#10 – TestAdvantage for Windows Forms

I was just reminded by our local Dev Evangelist, Peter Laudati, that we've got our third NJ CodeCamp coming up this weekend.  Code camps are a fun way to get to know other local devs, learn some cool stuff, and generally get at least a free lunch!  So you should go!

So Infragistics had a pretty cool release today, if I do say so myself.  We've released a beta patch for our NetAdvantage for ASP.NET product that supports Microsoft's ASP.NET AJAX Beta 1 and Beta 2. 

Support Details

• Our controls will register themselves with the UpdatePanel to ensure proper operation within it.
• Our Javascript Client-Side Object Model (CSOM) continues to work alongside the Microsoft AJAX Library.
• Infragistics controls will not interfere with the Microsoft AJAX Library.
• Infragistics controls can be embedded in and work with ASP.NET AJAX Control Toolkit controls.

I'm pretty pumped about ASP.NET AJAX, especially the Microsoft AJAX Library.  It should make client-side development across browsers much easier, and with the AJAX Extensions, it helps make adding AJAX to your apps in ASP.NET considerably easier, and the UpdatePanel is an indisputable help in that respect.

Infragistics is committed to the ASP.NET AJAX platform.  We'll be supporting it throughout the beta, the release, and beyond.  We've been adding AJAX-powered features since 2004, and it is only going to get better for us and everyone else thanks to the new platform and tool enhancements that are coming down the line.

Today we launched our new web site.  It was not just a simple update; we revamped the whole deal and made it Web 2.0 compliant <grin>.  If you remember our old site, I trust you'll immediately see the improvement.  Please take a minute to check it out and let me know what you think.  Also, if you run into any problems with it, please feel free to let us know.

I just spent an hour or more that I DON'T HAVE debugging a mysterious caching issue.  I suppose in some cases it might be obvious, but in this one, it was not.  To sum up, we're using an XmlDataSource control generically and setting its Data property programmatically (and using an XSL--don't know if that matters). 

Anyways, apparently the dang control defaults to "cache indefinitely" and won't refresh until the file it depends on changes.  I guess the thing is that it doesn't look for changes when you set the Data property, so it caches indefinitely to be sure.  Set EnableCaching to false, and voila, the problem is solved.

This just highlights a rule that all general APIs should follow--don't do any automatic caching.  You can't account for all the ways your customers will use your stuff, so just don't do it.  It's not hard to make them flip a bit to turn it on. 

Argh!

And overall I think it went quite well.  My Suave Sessions session was attended by a whopping ONE PERSON!  I seem to recall his name is Mark, and he runs the Ft. Worth DNUG, so kudos to him for picking a great session!  I know it wasn't sexy, but good session handling is something we should all be concerned about, certainly more so than getting an intro to DNN by the great Shaun Walker (who was presenting at the same time and whom I blame for stealing all my potential attendees).  The good news is that it's recorded and Wrox will be hosting it on their web site, so all of you folks who made the unfortunate decision not to attend can still get the session.  :)

Download the dotNetTemplar Session Management Module (for the Suave Sessions Session) - Even if you didn't see the session, you can start adding good session handling to your pages right away.  There's demo web project there to show how to use it.  If you want the demos from the presentation, let me know.

The EntLib session didn't go quite so well.  Apparently, I should really check to ensure my old demos work before the day of when I give a repeat session, he thought, embarrassed.  So I apologize again to all the troopers who toughed out the session with no running demos.  Thankfully, the core concepts could still be expressed; it just wasn't as fun as it could be.

Download the ELMAH EntLib Exception Handler/Logger - This can be used to both specify ELMAH as a custom EntLib exception handler and use EntLib for your db access in ELMAH.

To use it, configure ELMAH as usual.  If you want to use the EntLib logger, use GotDotNet.Elmah.EntLibErrorLog as the error log type instead of the standard SQL one. 

To use the custom exception handler in EntLib, you just need to choose it in the EntLib GUI by loading the ELMAH DLL and picking the GotDotNet.Elmah.ElmahEntLibExceptionHandler as the handler type.  It should look something like this in the standard config:

<add type="System.Exception, mscorlib, Version=2.0.0.0, Culture=neutral, PublicKeyToken=b77a5c561934e089"
  postHandlingAction="None" name="Exception">
  <exceptionHandlers>
    <add type="GotDotNet.Elmah.ElmahEntLibExceptionHandler, GotDotNet.Elmah, Version=2.0.50727.42, Culture=neutral, PublicKeyToken=58d6fbf09c89f721" name="Elmah EntLib Exception Handler" />
  </exceptionHandlers>
</add>

The public key token will differ, though.  I just reconditioned this for public use real quick like, so let me know if you have any issues.

Download the Slides From Both Presentations - In case you didn't get the DVD.

Other than that, I have to give some big kudos to David Walker and his team for putting the conference together.  I've spoken at a number of code camp activities, and this was definitely one of the best organized and professionally done.  I can't help but think that their not shunning sponsors (like Infragistics) helped in making it better.  While I appreciate the academic ideal of trying to keep the code camp focused on devs sharing with devs, I think it is perhaps not in the best interests of anyone to shun sponsorship.  The vendors who sponsor conferences like that have tools that are supposed to make devs lives better, so in my opinion, it only makes sense to welcome them in as long as it is done tastefully.

And no, I didn't just start thinking this now that I'm working for a vendor; you can ask Joe Healy--I was pushing for sponsors when I was helping organize the Tampa code camp.  After all, it's not like Microsoft's stuff is free, and if the conference is about using Microsoft's technologies, why limit the vendor sponsors and topics to Microsoft?  Microsoft does a lot to make software development better, and we all welcome that.  I'm just suggesting the same thinking be extended to other companies who do the same thing.

Anyways, I didn't intend to rant about that really; I mainly wanted to say that David et al did a great job.  It was good to visit my hometown again, and while I didn't make it out to Ron's Chli & Hamburgers Too for that sausage chili cheeseburger I've been missing, I still thoroughly enjoyed the visit.  Tulsa certainly has been growing its dev community, and I hope they continue to do so.

That's it.  Hope everyone's having a great day!  Sorry bout the delay in getting this up.

A while back, I decided I needed to add browser-specific capabilities to my web application.  While there are those who advocate using capability testing rather than browser sniffing, there is at least one good reason to prefer sniffing.  That is that you want to be sure your site works as well as possible in all browsers but you want to take advantage of capabilities only available in some. 

In itself, this is not a reason to prefer sniffing; the key, however, is that you "want to be sure," which means testing; otherwise, your stuff may or may not work, which isn't very reassuring.  If you don't have the resources to do testing in all target browsers or the time to develop Javascript workarounds based strictly on specific capability detection, then sniffing is a good alternative because it allows you to only use "advanced" functionality in the browsers that you have tested and fall back to standard functionality for the rest.  This of course assumes you have architected your stuff in such a way as to make downgrading possible and still offer fairly equivalent services in a less rich presentation.  That in itself can be challenging and is far too involved and a bit off topic for this post.

So let's just assume you can fall back.  The next question is where you do the downgrading.  You can do it in Javascript, which if you only want to alter some functionality on the client side is fine, but if you want to, say, avoid Javascript altogether or emit significantly different script based on browser, the choice is to detect on the server and act appropriately.

Thankfully, most web server technologies support browser sniffing, and ASP.NET has expanded on and improved on this with their control adapters in 2.0.  But you can still use the old browser capabilities approach.  To do this in 2.0, you simply add the special App_Browsers folder to your web site or project (if you're using WAP).  In there you just add a file with the .browser extension, and you can put in your own custom browser capabilities there.  Here's an example:

That's it, if all you want to do is extend the existing browser definitions.  If you want to define new ones or to find out more about the browser schema, you can consult the MSDN docs.  Using refID just lets you reference an existing definition and extend it.  You can view existing definitions that ship with .NET in the Framework CONFIG\Browsers directory (e.g., C:\WINDOWS\Microsoft.NET\Framework\v2.0.50727\CONFIG\Browsers), but be sure not to modify those directly to avoid your customizations being overwritten with later patches.

Note: You might be tempted to set a default value using refID="Default" as the docs suggest, but I've confirmed that there is a bug that causes the default to actually overwrite the more specific settings.  Microsoft tells me that they have scheduled a fix for this bug and that it will be released with the next Service Pack, but if you need it sooner, you can create a support incident and get a hotfix.  So the workaround is to not use Default and have your code check against null to determine default.  It's not the nicest approach, especially when you're using a Boolean value that would be better to just parse to bool, but it's not a travesty either.

You can then test for the capability in your code like so:

and do your downgrading if need be.  Of course, if you have some serious alternative rendering that needs to occur, you should consider using control adapters (especially the PageAdapter) to avoid complicating code with lots of conditional statements.

Hi all, I just wanted to spread the word about the Tulsa TechFest next month.  As some of you know, I originally hail from Tulsa, OK, and I'm glad to be going back to my home town for this conference.  I'll be doing one session on EntLib for ASP.NET (modified version of my TechEd talk) and one on professional session handling (talking about things like HTTP modules, handlers, custom controls, etc. to gracefully handle sessions in ASP.NET). 

Of course, I'm just one of many speakers who'll be presenting on a large variety of topics, not just .NET.  They'll also have vendors with lots of goodies--I know Infragistics has some neat giveaways planned.  So if you're in the region, you should definitely check it out.  It looks like it'll be the best tech event that the heartland has seen.  Kudos to David Walker and the other organizers.

I just want to spread the word about a little utiltiy on gotdotnet that generates a strongly-typed profile for WAPs.  It's not the easiest thing to come across: