You can't do sufficient .NET development without going to the command line at some point.  Not every tool that you need can be found or worked from the IDE.  There are too many tools to mention (at least in this post) and they tend to change from Visual Studio release to Visual Studio release, but if you're interested, I would recommend starting with Mike Wood's series of posts on Visual Studio 2005 SDK tools: part 1, part 2, and part 3.

Most of the time when working with these utilities, you need to navigate to a particular directory and work on a particular file.  And, of course, it's not enough to open the vanilla command shell (cmd.exe), because the paths to the .NET utilities haven't been mapped in the vanilla shell.  You could open your Start Menu, navigate to the Visual Studio 200X folder and somewhere within that folder launch the shortcut to the Visual Studio 200X Command Shell; then, at that command prompt navigate to the folder and file you want to work...and 50 keyboard clicks later actually start doing your work. That's lame.

Well, some time ago, the effervescent Scott Hanselman offered up a neat little power toy for adding a Visual Studio 200X Command Prompt Here context menu option when you right-click any folder in Windows Explorer.

Scott offered solutions for Visual Studio 2003 and 2005; however, lately, I've been doing a fair amount of work in Visual Studio 2008.  Where is my power toy for that?  Having found no other offerings for such a power toy for 2008, I decided to make my own.  So, I took Scott's solution and carefully and meticulously replaced all the 5s with 8s.  Yes, sheer brilliance, I know.  Well, it was slightly more complicated than that: you do have to change the filepath to the place where vsvars32.bat lives within your Visual Studio 2008 install, but other than that, it was a pretty simple modification.

I don't know much about the INF extension, but I do like the fact that it registers the power toy in the Add/Remove Programs control panel.  That's nice, because should you mess up modifying the INF file, you can always remove it and start over.  I've attached my INF file to this post.

 

vsnet2008cmdhere.inf (1.49 kb)

I always forget this quick fix, so I just want to dump it out here before I forget again.

On occasion, I'll need to work on a solution authored by one of my co-workers.  Many times, even though I've installed the same third party dependencies as my teammates, the filepaths won't line up quite right and I'll have broken references in a given project.  I could check the CSPROJ file out and change the references to my liking, but then I'll break my teammate--and that wouldn't be nice.  Instead, I'll take advantage of the CSPROJ.USER file--a local file that Visual Studio will either create for me under certain conditions or one I can create myself.  

Generally speaking, each project under a given solution can have one .USER file.  The file should remain local to your machine (don't check it in to source control), but Visual Studio will use it as a compliment to the CSPROJ file it helps describe.  In this instance, I will use it to help resolve some reference paths:

So, here's my problem: 

To fix this, I created a .USER file next to my CSPROJ file.  If my CSPROJ file were named Bunnies.csproj, I would create a blank text file called Bunnies.csproj.user.  To fix my references, I added this xml (MSBuild markup) to my .USER file:

Notice that you can add multiple paths so long as they're delimited by a semi-colon.  This is helpful if your broken references are lying all around your hard drive.  Also notice the I've ended each path with a final back slash.  I've found that reference paths only work when you include this last character at the end of each path.  And, tada, my broken references have been magically fixed:

Session: Making Security Testing Part of Everyday Development
Wednesday began with a bang!  If I had my doubts about dubious presentations on the first day of TechEd, this Wednesday morning presentation removed them.

Tom Gallagher of Microsoft presented on security testing using real-life examples (including security vulnerabilities found in that darn Clipy).  Tom constructed his presentation around five tips.

Tip 1: Think maliciously
For this tip, Tom talked about an old Microsoft service called Free/Busy.  Part of the service allowed users to send email invitations from a Microsoft web page.  Thinking maliciously, Tom showed how you could easily insert HTML into the body of the message that could execute malicious actions on client desktops.  He also showed how that feature could be exploited for phishing attacks.  After all, the sender does say microsoft.com.  

Tip 2: Identify entry points
I don't remember Tom's example for this one, but here's a list of tools he brought up to help you identify entry points to an application:

• netstat (the -anb argument will show all active connections)
• Microsoft's network monitor v3.0
• ViewPlgs (identifies protocol handlers)
• File Extensions association - this tool shows file extensions and the application to which they are mapped.  Also, certain extensions can be marked as "automatic download," meaning that when you click on a file with such an extension in your browser, it will automatically start to download.  This could be potentially dangerous.
• Process monitor

Tip 3: Understand related attacks
For this one, Tom mentioned the phrase, "same bug, different app."  So, this tip seemed to be about recognizing security flaws common across many applications: your application could be just as susceptible as its peers.  In his example, Tom used the name value Bill O'Henry.  O'Henry should be valid last name; however, your application should be careful to ensure that the single quote value is not a setup for a SQL injection attack.

Tip 4: Deeply understand/test the application
For this tip, I wrote down the quote, "always assume people have your code."  We know that .NET code is generally easy to disassemble with tools like .NET Reflector, so, it seems reasonable to make such an assumption.  I wrote down two tools--LogView and Web Proxy Editor--next to this tip in my notes, but I don't recall what value they added to the tip.

Tip 5: Leverage existing tools
To me, this is always one of the more interesting discussions in the security testing space--what tools, particularly free tools, are available to aid you in testing your applications for security vulnerabilities.  Tom began by talking about fuzzers and fuzz testing.  Then he dove into a long list of tools.  Sorry, but I have no links or definitions of these tools--I list these here as a placeholder for later research:

• Debugger
• SQL Profiler
• XSS Detect
• MITM TCP Proxy
• Looking Glass
• Peach (a type of fuzzer)
• WinDbg

So much to learn, so little time.

Session: Pragmatic Architecture: Presentation
I wanted to make sure to catch a Ted Neward presentation: I've found some of his opinions interesting after hearing him on .NET Rocks and reading his blog.  So, I caught his session on Pragmatic Presentation Architecture.  It was another presentation held in one of those frightful theaters--I made sure I got there in plenty of time to get a seat which was a good thing since the session was soon packed to capacity.

Of the few conferences I've attended, I usually go with the hope of picking up new approaches in code and other technical details that I can later apply to my problems at work.  Thus, when I wind up sitting through a presentation that discusses higher level challenges than just the technical details, I get a little crestfallen.  Certainly, there's a time and place for discussing and embracing these "softer skills" and I probably should develop a better attitude toward such studies.  However, there are only so many hours in a day (and conference) and I'd prefer to spend the majority of that time in the bits and bytes.  

Anyway, Ted's presentation was one of these higher-level type discussions.  What are the important facets to consider when architecting a presentation layer of a solution?  Ted postulates at least five points of consideration:

1. Style - should we seek a graphical solution or simply a command line interface?
2. Implementation - how will the presentation layer be implemented: through code, markup, something else?
3. Perspective - UI requirements might change based on the role of the user.  This can be an important consideration in the architecture.  Reporting can also be a factor here.
4. Cardinality - a UI can be composed of a number of unique elements that interact with each other at some level.  The term "mash-up" fits in this space.
5. Locality - are UI resources remote (server-side code, web services), local (desktop, client-side code), or some hybrid in between?

That's all I have to say about that.

Session: ACE Performance Testing and Tuning Methodology Using Microsoft Visual Studio Team System 2008 and the Latest Microsoft Tools
The Assessment Consulting & Engineering (ACE) team is one of the consulting wings of Microsoft.  Edmund Wong of the ACE team conducted the presentation (I couldn't find any blog by Edmund, but here's the ACE team blog).  

Performance testing and tuning is certainly one the less sexy topics in software development, but it's understanding how to squeeze more performance out of your application can be an incredibly powerful skill.  Edmund began by identify three main objectives of the ACE team regarding performance tuning:

1. Resolve single user problems.
2. Remove stress related problems.
3. Perform capacity testing and planning.

As is typical of most of these kinds of presentations, Edmund used Microsoft tools in his demonstrations: namely, Visual Studio 2008 Team Edition Tester and the Web and Load test tools therein.  Some day, I'd like to see someone duplicate many of these TechEd sessions but add the subtitle, "On the Cheap."  Thus, the question would be, how could I perform similar performance testing and tuning not withTeam Edition Tester, but, rather, with any available open source tools?

Anyway, Edmund walked through the different reports and graphs produced by Team Edition Tester and highlighted some of the metrics he considers important including performance counters, SQL trace information, and IIS log information.  He did mention some free tools he's used including SQL Performance Dashboard (I think this is it) and wcfTrace (or maybe he meant WCF Load Test since I couldn't find a tool called WCF Trace).  He also pointed out the team's Performance Testing Guide.

The one thing I really wanted was an Excel spreadsheet he kept referring to that had recommended thresholds for certain performance metrics (eg. a well tuned application running on a single web server of X specification should be able to serve Y requests per second).  I've searched long and hard for such pronouncements from any relatively respectable organization and always came up empty.  Here, in front of me, was the very document I've been looking for.  Of course, Edmund assured everyone that the spreadsheet would be available along side the Powerpoint presentation in the TechEd website, but I've looked several times and have only found the Powerpoint.  Maybe I'll hold my breath until the DVDs come out...or maybe Edmund was just yanking my chain.

Session: Jumpstart Data Driven Web Applications with ASP.NET 3.5 (Part 1 of 2)
Well, I had to get in at least one Scott Hanselman session, so this was it.  Scott suggested a possibly better title for this session could have been, "Stuff with Data isn't as hard as before."  
Scott began the discussion by identifying where we are today: with lots of data access code based on strings and "loose binding" that can't be checked at compile time (nor do we get any intellisense).  He called this paradigm "tunneling".  For example:

He then showed how you could achieve better results--compile-time checking, strong typing, etc.--with LinqToSql.  For example:

The next topic that sparked my interest was his discussion of the new ListView control in ASP.NET 3.5.  he ran through some pretty sweet examples on how to change the look and feel of this control (more examples here).  Another new control he covered was the LinqDataSource control: used to bind LinqToSql queries to data controls.

Overall, though, the topic that really blew me away was his discussion of the new ASP.NET Dynamic Data.  ASP.NET Dynamic Data is Microsoft's adoption of the concepts of scaffolding and templating that I've seen in Grails and, from what I've heard, is a component of Ruby on Rails although I've spent almost no time in that technology (sorry Ruby folks, but there are only so many hours in the day).  The framework will roll out with .NET Framework 3.5 SP1 which is still in beta.  Don't know if I can wait for the RTM, so I might have to work on spinning up a throw-away VM in which I won't feel uneasy about installing a beta service pack.

On a side note, Scott and many other presenters (myself included), take an approach where they like to spend the majority of their presentation time in the IDE writing code.  This is a fantastic way to spend the presentation time because presenters are forced to prove the veracity of their claims and because the attendees get to see real implementations--not just abstractions on a Powerpoint slide.  The downside of this is that, unless you take meticulous notes (or the presenter supplies the code he wrote), when you review the presentation deck days or weeks or months later, you're going to forget virtually all the concepts discussed.  You'll simply have a deck with several slides saying, "demo here".  Personally, the way I try to combat this problem when I do a presentation is to make sure I take snapshots of key portions of the demo code and paste them on slides in the deck--many times annotating those images with circles, lines, and other notes pointing out the key pieces (I also try to provide my sample code along with the slide deck).  That way, someone reviewing the presentation later on can get most of the concepts by simply thumbing through the slides.

Unfortunately, Scott's deck was riddled with "demo here" slides and no code was available for download from the TechEd site (maybe it will be available when the DVDs come out).  That, plus my sparse notes means that I don't have as much content to share on this session as I'd like.

Session: Microsoft Visual C# Compiler Tricks
Scott Cate did this presentation.  Last year, Scott did a great presentation at the Cincinnati .NET User Group on Model-View-Presenter.  

When I saw the title of this presentation (and like every other presentation, failed to read the abstract), I thought Scott would walk us through interesting approaches to compiling your .NET code from the command line with csc.exe.  Perhaps we'd even get into an interesting Domain Specific Language discussion which requires you to do some interesting compiler tricks to get the compiler to understand your made-up language (for example, this).

Scott immediately dismissed these theories: on the contrary, we would be working entirely in the IDE in .NET 2.0 and perform tricks to retro-fit some of the new features of .NET 3.5 back into a purely .NET 2.0 application.  Hmm.  Sounds interesting.  Not sure that I would want to do that in my business applications, but I'll bite.

Scott then went on an interesting tour of ways you can force the .NET 2.0 compiler to allow you to use certain .NET 3.5 syntax.  One of these is the Extension method.  Scott referenced this blog post from Daniel Moth and walked through the example.  One cool thing Scott did was to make sure his compiled DLLs would appear in Solution Explorer of Visual Studio and associate the DLLs to .NET Reflector so that you could easily see the IL code generated by the compiler.

Scott continued to talk about some other features of .NET 3.5 that you could refactor back into your .NET 2.0 code, but that's where my notes start to go fuzzy.  I wrote down Lambda expressions and Linq to SQL and Linq to XML, but now I'm not really sure what I meant to say about those topics.  Fortunately, Scott has been kind enough to post his slide deck and his example code.  (Scott Cate, like Scott Hanselman, is one of these guys who likes to live in the IDE for most of his presentation time, usually beginning with a blank page and coding until his can successfully convey his message.  Thankfully, Scott Cate has pushed up his demo code to the inter-tubes.)

Session: Beer and Mexican Food
I was fortunate enough to find out the Friday before TechEd that my pals Jay and Art would be attending the conference, too.  I've worked with both Jay and Art to a limited degree at my company.  Both live and work in different states.  I met Jay once but never met Art face-to-face, so I was looking forward to hanging around with the two during our week in Orlando.  The TechEd sessions kept the three of us very busy, but we found a bit of a break Wednesday evening (before the Birds of a Feather sessions) to catch dinner at a local Mexican restaurant and catch up on our different activities in our work and personal lives.

Birds of a Feather Session: Microsoft .NET Framework-Based Application Hardening
Art, Jay, and I spent too much time chowing down tacos and we ended up missing the first session of the BOFs.  Frankly, few of the sessions in that first hour seemed very appealing, anyway.  I probably would have taken in either Design for Testability or Dynamic Language and the DLR, but wasn't really upset that I missed either.  In contrast, the next set of BOFs had me at a six-way tie for which session I would attend (if only human cloning were a viable option).  Would the lucky winner be:

1. ASP.NET vs. MVC.  What's your take?
2. Top Considerations for Ensuring Microsoft .NET Framework Based Application Manageability
3. Making Sense of All: Heterogeneous Data Access on the Microsoft .NET Framework 3.5
4. Patterns and Practices in the Real World
5. Code Style and Standards
6. Microsoft .NET Framework Based Application Hardening

Hmm.  Hard decision.  Since, in many ways, my team at work is kind of like a mini Patterns and Practices team, let's try that one.  Well, as I said, we had been busy chowing down tacos and, as a consequence, were about 10 minutes late to the second set of BOFs.  When we tried to enter the Patterns and Practices in the Real World session, we were turned away at the door by the TechEd staff: "this session is already full."  Ok.  Now I'm down to a five way tie.  Well, security is an oft overlooked topic at my company (at least from the development perspective), so let's attend that one.  So, Art and I went to the Microsoft .NET Framework Based Application Hardening; Jay proceeded to a different session.

For a while, I have been keenly interested in the concept of .NET application hardening.  Usually when I hear the term hardening, it's used in a kind of CISSP where security professionals spend time analyzing and locking down network peripherals and server operating systems.  In the .NET space, we hear about ways to prevent SQL injection and cross-site scripting attacks, but there seems to be a large gap between a hardened OS and application code written to avoid certain kinds of attacks.  I'm thinking mainly of what can be done at the machine.config and web.config levels to harden a .NET application.  

It seems to me, the largest consideration in this space is Trust Mode, but I'm sure there are other considerations, too (machine validation key?  code access security?).  Microsoft generally recommends that web servers hosting Internet-facing applications or serving as a shared hosting environment for different applications run in Medium Trust mode (see Stefan Schackow's book, Professional ASP.NET 2.0 Security, Membership, and Role Management, for a good reference on Trust Mode and other ASP.NET 2.0 security considerations).  I do know that Microsoft does have their Security Development Lifecycle (SDL) guidance, but I have not found the time to work through those tools--maybe this BOF would cover that guidance, too.

So, my hope for this BOF was to discuss all the various hardening options that lie between the operating system and your C# code and, as pertains to Trust Mode, are there relatively easy ways to test your application under Partial Trust?  I would hope that the answer is not--install your app on a development server running in Medium Trust and do your testing there.  Rather, I would hope that by now there are ingenuitive ways to test your application in Medium Trust right on your development workstation.  Could NUnit do this or would  you have to do this as part of your integration tests and make sure to set your trust level to Medium in your web.config before running your tests?  It would be nice if there were some button you could flip to suddenly run debug code in Medium Trust, but that may be asking too much.

Anyway, the first thing I noticed as I walked into the room was that there were only six people in attendance--two of which were the moderators and one who was merely an INETA representative.  As soon as Art and I sat down, one of the moderators turned to us and asked us our thoughts on .NET application hardening.  Not blinking, I launched into my diatribe of thoughts on the topic (some of which I've listed above).  Shortly after I began my monologue, two of the attendees left the room.  I'd like to think they were just leaving so that they could get a fresh start on the next days activities, but we all probably know the real reason.

When I finally came up for air, the moderators introduced themselves and their particular angle on the topic.  They were two guys from PreEmptive Solutions: the makers of Dotfuscator.  Their angle on application hardening was to ensure that your IL is sufficiently scrambled so that a malicious person cannot reverse engineer your code.  Hmm.  Hadn't really considered obfuscation in my list of hardening concerns.  It seems to me that if a malicious person made it through to the point where your IL was in danger of being reverse engineered, you were already too screwed to care about that.  Never the less, I guess you could call obfuscation another consideration in application hardening--certainly if you make a commercial desktop application.  

The moderators also talked about the rigor with which their product has been developed.  Since a light version of .NET Obfuscator is distributed with Visual Studio, Microsoft demands that the development effort for .NET Obfuscator adhere to a littany of standards set by the SDL; so, yes, we did talk a little about the SDL, but only in terms of certifying products with the Microsoft seal of approval.  Of course, I don't see the applications I write as requiring Microsoft's security seal of approval, but who knows?  Maybe when that million dollar idea finally surfaces in my brain, I will need the SDL seal of approval.  So, now it's just a matter of waiting on my brain.  Brain?  Hello, you there?

Session: Taking Advantage of Microsoft Enterprise Library for Visual Studio
This session was held in one of the conference theaters: a section in the middle of the large conference area floor cordoned by 10' high cubicle walls with seating for about 50 people.  Last year, I found these venues frustrating because of all the noise around the theaters: the main conference area floor played host to not only the theaters, but to tens of booths manned by Microsoft employees on hand to answer questions about specific technologies, the lunch area, the vendor section, and a number of other noise-inducing distractions.  This year, while much of the environment remained the same, I did notice that the theaters seemed better constructed to muffle the outside noise--at least, I could hear the speakers much better this time around.  I'm sure the fact that Microsoft split the conference up into separate Developer and IT editions--reducing the attendance by about half--helped reduce the ambient noise, as well.

One problem solved.  The next problem, though, was seating.  The theaters played host to a number of interesting topics and, as a result, a number of people would show up to these sessions.  If you wanted to get a seat, you had to be at least 20-25 minutes early.  If you wanted to get some room on the carpet, you usually had to be at least 15 minutes early.  Once seat and carpet were full, forget it: you could stare through the glass wall at the back of the make-shift room, but could hear no sound.

As to my thoughts on the session on Enterprise Library?  Well, I arrived at the theater at about 5 minutes before the start of the session.  Better luck next time, I guess.

Session: Messaging, Identity, and Workflow in the Cloud
Since I couldn't attend the session on Enterprise Library, Plan B was to check out this session on Messaging, Identity, and Workflow.  I had no idea what this session was about exactly, but I've been struggling with messaging (.NET to JMS, specifically) and identity (web service authentication, to be exact) at work, so surely this session would offer some value to me in those areas.

Well, this session was all about a new offering from Microsoft: Biztalk Services.  Biztalk Services (not to be confused with Biztalk Server) is an experimental offering to foster better connectivity between service endpoints.  It includes some pretty interesting security and entitlement features to help you secure your services.  I don't see much business value here (for one, this service is an unsupported experiment), but it seems like something that might be fun to play around with.  Presenter Justin Smith played a very entertaining video involving Biztalk Services and robots--that alone made for great session material!

Session: Architect or Developer: Tips and Tricks for Guiding and Supporting Innovation
Boy, it sure would be nice to have a culture of innovation at work.  Sounds like this session is poised to offer me great advice on promoting such concepts at my company.  Unfortunately, the timing of this session gave me only 15 minutes to traverse the conference floor from my previous session, wade through the lunch line, wolf down lunch, and high-tail it to this session.  Oh, and yes, it was being hosted in one of those dreaded theaters.  Guess I'll pass on this one, too, and enjoy my pastry dessert.

Session: Writing Administration Tools for your Applications
This session was presented by Brian Randell in one of those dreaded theaters, again.  I attended one of Brian's presentations last year--don't remember the title.  However, I do remember him making an intriguing statement: something to the effect of, "since we now have Powershell, is there a need anymore to write .NET console applications?"  This statement motivated me to look harder at Powershell as an alternative hosting "UI" for my .NET binaries.  For instance, there has been a revival over the last two or three years in the separation of concerns paradigm in ASP.NET development.  Specifically, we've seen multiple, robust implementations of the MVP and MVC patterns appear recently.  One argument in favor of adopting these patterns is the code-reuse argument: that, if we properly separate the business operations of an application away from its UI, that code base can be reused elsewhere.  So, I should be able to take the code base of an ASP.NET application and front it with a Winform or WPF UI to suddenly turn the application into a desktop app.  Could I not then also take that same code base and front it with a Powershell script and turn the application into a command line driven application or even a batch-based application that I can schedule to run nightly across thousands of records?  But I digress.

Brian began his talk by quoting from the TechEd mini conference guide regarding the nature of sessions that are suppose to occur in these "interactive" theaters:

• Small and informal (so explain why there was no room for me at the previous theaters I wanted to attend)
• Interactive and discussion based
• Chalk talk and white board formats
• 30-75 minutes in length

Interactive and discussion based.  In other words, "I have no thorough presentation for you based on my research and experience.  Rather, I want to hear what you, the attendees to this session, think should be the solution."  Great.  I was really hoping Brian would share some examples of administrative tools he's written in the past, particularly with Powershell (in reference to his last year's comment).  Instead, he presented a list of important points he felt an administrative tool should address.  When I say administrative tool, I mean a tool you write to administrate your actual solution.  In my mind, this could be a tool to alter configuration settings--perhaps turn on, turn off, or somehow change diagnostic settings, change connection strings, and so on--a tool to view log information, etc.  Even though I was expecting a standard presentation on this topic, Brian still conveyed some interesting information.

He noted that the Visual Studio 2008 IDE could be deployed as a shell--without all the code editors and other tools and plug-ins you normally get with your license, I guess.  This makes sense because that's how the Team Foundation "fat client" deploys.  Normally, you access TFS from a TFS plug-in in Visual Studio; however, if you want to access TFS from a machine in which Visual Studio is not installed, you can install the TFS fat client, which is just the Visual Studio shell plus the TFS plug-ins.  Brian mentioned that admin tool option could be writing a Visual Studio plug-in and then deploying your plug-in with the Visual Studio shell.

He mentioned that tool developers should consider the different UI options: command line, Winform, Web and even devices.  Specific technologies could include Powershell, WPF, and even the Microsoft Management Console (MMC).  On MMC, he said that for older versions, writing your snap-in was difficult.  Typically, you'd have to write your snap-in in C++ or VB6.  However, the new version of MMC, version 3.0, apparently allows for greater extensibility options.  Brian mentioned that the February 2007 Windows SDK (and greater, presumably) includes support for MMC 3.0 snap-ins and samples.  MMC 3.0 will only work on Windows XP SP2 and Vista.  Will it work on Windows 2003?  Don't know.

Other considerations could include support for COM so that admins would have the option of scripting the tool from within VBScript or JScript.  My thought: forget that.  Isn't this another reason we now have Powershell?  Someone in the crowd mentioned that Powershell templates in Visual Studio made it easier to write Powershell scripts.  I wonder if he was referring to this? 

Finally, I noted some of Brian's thoughts around leveraging WMI for administrative management.  He mentioned that Visual Studio 2008 makes it easier than ever to take a look at the types of data published to WMI.  In the Server Tool, there's a node labeled as Management Classes and another labeled Management Events.  These nodes let you take a peek at the WMI world on your machine.  Right-clicking either node gives you more options.

Session: Decoupling Contract from Implementation: Microsoft .NET Interface-Based Programming End-to-End
Juval Lowy is a man on a mission: hide your implementations behind interfaces always and all the time!  And what's this crap about Microsoft's increasing use of abstract base classes?  Abstract base classes are too lenient in that deriving classes are not required to provide implementations for every method and so on.  Interfaces are the way to go.  Juval covered some very interesting tricks you can leverage for explicit implementations of interfaces and casting.  I'm definitely going to have to pull down and go over this presentation again when the TechEd media comes out. 

Session: From Zero to N-Tier in 75 Minutes
Paul Sheriff presented this session.  Paul's a fairly prolific writer in a few of the technology journals out there.  I do remember seeing his name on particular articles from time to time.

So, what is a Tier and what is a N-Tier architecture?  In most circles, technologists will tell you that a Tier is associated with a physical layer of an application.  For instance, you could host business processing components on an application server.  You would probably call that the Application Tier.  An application's database is usually hosted on a physically separated server called the Database server.  This would be known as the Data Tier. 

Tier is contrasted with Layer: most technologists will tell you that a layer is a logical separation of certain components.  For instance, good development practice would insist on separating all business processing code away from the user interface.  The user interface components--ASPX pages and such--would live in a UI layer while the separate business processing code would live in a Business layer.  The Business layer itself would be further broken down such that code used to access data repositories would be separated out to yet another layer traditionally called a Data or Infrastructure layer.

So, with this kind of understanding, I was eager to see what Paul would come up with:  would he advocate an SOA approach to N-Tier architecture by demanding that all business processes live behind WCF services in an application farm?  If so, what kind of bindings would he recommend?  What kind of security would he recommend and would he discuss caching of security credentials to improve performance?  If not WCF, would he recommend .NET remoting?  I've done very little with remoting, so it would be very interesting to hear what arguments he might have for .NET remoting in a WCF world.  Aside from WCF and .NET remoting, what other considerations should we take into account when architecting a .NET, N-Tier solution?  Would Biztalk Server fit somewhere in here?

Unfortunately, Paul didn't present a discussion on an N-Tier solution.  Rather, he presented an N-Layer solution discussion.  Interestingly, he acknowledged that he knew the differences between the two terms in one of his first slides, yet his entire presentation was about taking a flat .NET solution and refactoring it into multiple logical layers. 

I found this pretty frustrating: there are hundreds of posts on the internet on how to construct an N-Layer solution.  What is not so widely discussed are the pros and cons of an N-Tier solution and recommendations for how to proceed with such an endeavor.  Here's Rocky Lhotka's thoughts on the topic (and David Hayden's).  I probably should have left and looked for another presentation--perhaps that one on multi-core development or that one on WPF data templates.  I guess I stayed hoping that he would, at some point, jump into the N-Tier discussion.  Alas, he did not.  What's more, his refactoring efforts included no discussion of interfaces, MVP, or MVC, nor did he discuss other separation concepts like ORM.  Moral of the story: don't just rely on the session title to tell you what concepts will be discussed.

Overall, I found TechEd 2008 (Developer edition) a very worthwhile conference.  It introduced me to new ways of solving various software problems, confirmed many of my own
conclusions of different aspects of software development, and even enticed me to learn more about certain technologies I've been deliberately avoiding (I'm thinking of you, WPF
and Silverlight 2.0 beta).  It was also nice to get away from work for a short time.

When I attend conferences, I find I'm an old-school note taker: carrying around a paper notepad (even though my 100 pound laptop is nestled nicely in my backpack).  So, now I
face the daunting of transcribing my chicken scratches to digital.  My plan is to post up my notes as I get them transcribed.

One of the side benefits of conferences is the swag: t-shirts, pens, notebooks, and other more useless paraphernalia that you can get from Microsoft and other vendors.  Some vendors have drawings to give away cool prizes like X-boxes (last year, one vendor gave away a motorcycle).  Sometimes to enter these contests, you have to submit a business card.  As my company provides me no business cards, I was forced to make up my own: