Microsoft just released .NET 3.5 SP1 and Visual Studio 2008 SP1.  While scrolling through the Overview section to see what's new in each service pack, I saw this:

VSTA 2.0 SDK

Huh?  Now, I've heard of Visual Studio Tools for Office (VSTO) before and I attended a DevCares.com event not long ago on VSTO, but I've never heard of VSTA.  Did Microsoft do another name change?

Apparently not.  According to this article:

"The same team that created Visual Studio Tools for Applications also developed Visual Studio Tools for Office and the two technologies share a common architecture. However, Visual Studio Tools for Office is designed for developers who want to include Microsoft Office in custom solutions, while Visual Studio Tools for Applications is designed for end users of any application that includes it. For example, an accountant could add a new capability to accounting software by writing a function, without having to involve the company's development department. End users add new functionality by creating add-ins."

So there you have it.  With these new tools coming out for much easier development on the Office platform, it's probably time to take a new look at making Office a front-end for some of our solutions.  You could make the same argument for SharePoint, but I think I'll leave that one alone for now.

I took a look at Andy Erickson's blog the other day and noticed his Now Reading section.  I thought that was pretty cool and started looking around to see how I could add such a widget to my BlogEngine.NET implementation.  

There doesn't appear to be a BlogEngine.NET widget for a bookshelf, but I did see in some of the CodePlex comments that folks were recommending Shelfari.com.  So, I hopped over there and gave it a try.  Previously, I had played around with LibraryThing.com, but there seemed to be some limitations with the free account--plus, do they have a widget you can drop on your site?  

At any rate, Shelfari seems to have the features I'm interested in, so I'm now pleased to present...Brad's Bookshelf!

For easy access, I've added a link to my bookshelf page on the top menu bar.  I've not added many books quite yet, nor made any comments or recommendations, but more of that should come in time.  I look forward to hearing your recommendations as well!

Service tracing in WCF reminds me of the continuum transfunctioner--its a very mysterious and powerful device and it's mystery is exceeded only by it's power.

I had some WCF problems recently and ended up having to open up a ticket with Microsoft to resolve.  The first thing the tech did was send me an email with the following configuration:

    <system.diagnostics>
<sources>
<source name="System.ServiceModel" switchValue="Warning, ActivityTracing" >
<listeners>
<add name="xml" />
</listeners>
</source>
<source name="System.ServiceModel.MessageLogging" switchValue="Warning">
<listeners>
<add name="xml" />
</listeners>
</source>
</sources>
<sharedListeners>
<add name="xml" type="System.Diagnostics.XmlWriterTraceListener" initializeData="Server.svclog" />
</sharedListeners>
<trace autoflush="true" />
</system.diagnostics>

and...

    <diagnostics>
<messageLogging maxMessagesToLog="30000"
logEntireMessage="true"
logMessagesAtServiceLevel="false"
logMalformedMessages="true"
logMessagesAtTransportLevel="true">
<filters>
<clear/>
</filters>
</messageLogging>
</diagnostics>

The first thing to note is, "wait a minute: there's two sets of configuration just to get trace logging going?" Why, yes, Timmy, that's right! The node system.diagnostics lives directly under the configuration document element while the node diagnostics lives under system.serviceModel. The second thing to note is, "hey, this looks like a much simpler diagnostics configuration than I'm used to!" Prior to my exchange with this Microsoft tech, I would just go in to the WCF Service Configuration Editor tool and just start click on different links in the Diagnostics page. I'd usually produce a configuration like this:

    <system.diagnostics>
<sources>
<source name="System.ServiceModel.MessageLogging" switchValue="Warning, ActivityTracing">
<listeners>
<add type="System.Diagnostics.DefaultTraceListener" name="Default">
<filter type="" />
</add>
<add name="ServiceModelMessageLoggingListener">
<filter type="" />
</add>
</listeners>
</source>
<source name="System.ServiceModel" switchValue="Warning,ActivityTracing"
propagateActivity="false">
<listeners>
<add type="System.Diagnostics.DefaultTraceListener" name="Default">
<filter type="" />
</add>
<add name="ServiceModelTraceListener">
<filter type="" />
</add>
</listeners>
</source>
</sources>
<sharedListeners>
<add initializeData="d:\somedir\tests\dummywcftests\wcfservice1\web_messages.svclog"
type="System.Diagnostics.XmlWriterTraceListener, System, Version=2.0.0.0, Culture=neutral, PublicKeyToken=b77a5c561934e089"
name="ServiceModelMessageLoggingListener" traceOutputOptions="Timestamp">
<filter type="" />
</add>
<add initializeData="d:\somedir\tests\dummywcftests\wcfservice1\web_tracelog.svclog"
type="System.Diagnostics.XmlWriterTraceListener, System, Version=2.0.0.0, Culture=neutral, PublicKeyToken=b77a5c561934e089"
name="ServiceModelTraceListener" traceOutputOptions="Timestamp">
<filter type="" />
</add>
</sharedListeners>
</system.diagnostics>

and...

    <diagnostics>
<messageLogging logMalformedMessages="true" logMessagesAtTransportLevel="true" />
</diagnostics>

The log file produced wasn't much help, either. As soon as I loaded this new configuration (sent to me by the tech), recreated my problem, and looked at the log in the Service Trace Viewer tool, I knew immediately what my problem was (it was even bolded and in red)! Fortunately (or maybe unfortunately), I had other problems with my service so I still made good use of the technical support.

One thing I really like about this new configuration is that all traces are dumped to the same XML listener. As far as I can tell, there's no way to route different trace sources to the same listener in the configuration tool. You'd have to drop out of the tool and edit the XML directly. The tools Microsoft provides are great: but you'll likely still need to edit the generated code/configuration at some point.

Previously, I posted about my problem getting the WCF Test Client tool to work.  Well, it works now on my new machine.  The solution is, as I noted in the update to that post, that I need the 6.0a SDK (the one that comes with Visual Studio 2008), not the 6.1 SDK.  Go figure.

Anyway, here are my notes on getting it all to work...

Step 1: go to the command line and execute wcftestclient.exe passing the URL to the WCF service you want to test (Note: if your service will be running under the ASP.NET Development Server, make sure that's running first before you try to run the test tool):

Step 2: after a few minutes, WCF Test Client will use svcutil.exe to generate a client proxy and display a UI that lets you test the various methods of your service:

Limitations I've noted:

• I'm doing a lot of work with custom bindings and, on occasion, custom binding and behavior extensions.  Svcutil does not appear to generate a complete client config file under some of these circumstances.  I've written my own test clients, used svcutil to generate my proxy and config file, and still had to go in and copy/paste configuration settings from my service to my client to get the client to work successfully.  In these situations, I would say forget WCF Test Client and write your own.  I've not tried WCF Test Client with custom extensions, but I would imagine that, assuming svcutil can generate a correct config file to begin with, you'd have to copy your custom assemblies next to wcftestclient.exe so that it could use those extensions.
• Can you edit the client config generated by WCF Test Client?  Interestingly, the tool lets you see the config right in the UI and will easily give you the file path to where it saved out the config, but I haven't been able to edit it and see that the tool discovers those changes.  So, no copy/pasting xml from your service config to your client config to make up for the misses on the part of svcutil.  (Not that I mean to disparage svcutil or anything--it's a great tool and one that I would certainly miss if it were to suddenly disappear.)
• I've also had situations where I've had to go in and modify the proxy class that svcutil generated for me.  Specifically, I've had a situation where my requirement was to provide a signed, but cleartext, response message.  By default, WCF will transmit a signed and encrypted message body.  To change this behavior, you have to go into your proxy class and set the ProtectionLevel attribute accordingly.  Unfortunately, there appears to be no way to edit the proxy class used by the WCF Test Client for these kinds of situations--so, back to rolling your own test client.  For most mainstream scenarios, though, the test client seems to do the job.

Session: Best Practices with the Microsoft Visual C# 3.0 Language Features
Originally, I had planned to attend the session Providing Load Balancing, Application-Level Failover, and Centralized Configuration Management with Windows Communication Foundation Services and Microsoft .NET Applications (say that five times fast).  However, Jay had really recommended Mads Torgersen as a knowledgeable presenter.  So, I decided to check the session out.

Like others before, Mads was a stay-in-the-IDE kind of presenter: he started with a blank class file and began coding away his examples, at least for most of his presentation.

Mads summarized C# 3.0 as:

1. A move from imperative to declarative programming
2. A paradigm shift from "how" thinking to "what" thinking
3. and...LINQ

One of the first features Mads talked about is Auto-Implement properties.  This is just a time saving convention.  Traditionally, when we have coded properties, we've always had to code a private member to store the value of the property: a "backing field" as he called it.  With C# 3.0, all you need to do is:

public string X {get; set;}

One gotcha Mads mentioned was that you must have both a getter and setter.

Another feature he mentioned was implicitly typed locals.  Where once we coded this:

List<x> y = new List<x>();

Now, we can do this:

var y = new List<x>();

Next was object and collection initializers.  This feature lets you reduce lines of code by setting properties of an object inline with the object initialization.  Thus, where once we had to do this:

Customer x = new Customer();
x.ID = "SomeId";

Now, we can do this:

Customer x = new Customer{ ID="SomeId" };

C# 3.0 also brings us Extension Methods.  Extension methods are a way of tacking on you own methods to a pre-existing object.  Here's an example of an extension method I wrote:

    public static class SomeExtensions
{
public static string ReverseMe(this string reverse)
{
char[] rev = reverse.ToCharArray();
Array.Reverse(rev);
return (new string(rev));
}
}

To use this method, then, all you have to do is call the ReverseMe method: MyString.ReverseMe().  The reverse of MyString will be returned.

Lambda expressions is the next evolution of the delegate story.  Where once we did something like this:

delegate (Customer c) { return c.City == "London"; }

Now, we can shorten that syntax to this:

( c => c.City == "London" )

LINQ is obviously one of the most popular features of C# 3.0, so Mads spent some time talking about how LINQ helps integrate our queries in with the rest of our code.  The last item I have jotted down in my notes is Expression Trees.  Expression trees are something like lambda expressions that make use of the new Expression<T> type.

Session: N-Tier Development with Microsoft Visual Studio 2008 and Windows Communication Foundation
Here was another session I attended presented by Rocky Lhotka.  This time, unlike the "N-Tier" session I attended on the first day, Rocky really did work toward the goal of physically separating out the layers of an application.

He started with the good 'ol DataSet.  Did you know you can actually separate the DataSet and its adapter into separate assemblies?  Rocky showed us how.  Who knew we could actually achieve some level of separation of concerns with the dataset?

Next up was Windows Communication Foundation (WCF).  Rocky proceeded to walk through an example of passing strongly typed datasets via WCF.  These types must be installed on both the client and server.

Rocky then dove into a discussion of the DataContract.  He contrasted the DataContract attribute with the Serializable attribute: the DataContract attribute adopts an "opt-in" approach while the Serializable attribute adopts an "opt-out" approach.  The "opt-in" approach requires that you explicitly decorate all the members of your class that you want to serialize over the wire.  You do this with the DataMember attribute.  The danger here is that if you have a large domain object, you may miss a member.  On the other hand, the "opt-out" approach of the Serializable attribute assumes that all members of your domain object should be serialized unless you explicitly state not to serialize a particular member.  This approach could be deemed safer--at least from the absent-minded developer.

The last topic Rocky covered was the serialization engines of WCF.  The Data Contract Serializer (DCS), "does not preserve the graph shape."  I can't remember exactly what Rocky meant by that, but it sounds bad--I vaguely recall that this reality could play havoc with deserialization efforts on the part of the client or server.  Apparently, the DCS includes a constructor overload where you can force the serializer to preserve the object graph shape, but that can apparently get sticky.

He then moved on to the Net Data Contract Serializer (NDCS).  The NDCS has the ability to serialize more complicated domain objects, but, if I recall correctly, it comes at the sacrifice of interoperability.

Session: Windows Presentation Foundation-Based UI: What We've Learned So Far and What's Still to Come
The session was presented by Dr. Gil Hupert-Graff of Beyond UX.  This was another one of those touchy-feely type presentations--or maybe my design skills are so poor that I don't know a good design presentation when I see one.  At any rate, the good doctor walked through a few demos of applications his company built for clients--applications with a UI/WPF/wiz-bang emphasis.  He then went into his company's experimentation with the intersection of design and development--where the scope of the designer ends and the developer's begin.

Expression Blend makes this intersection even more interesting because it can be both a design and a development tool at the same time (of course, it also serves as a tool equally hated by most designers and developers).  Gil discussed how his team has used story boards to layout a UI and then used a combination of Photoshop and Blend to make the story board a reality.  He also laid out some interesting workflows of when and where the designer does work and when and where the developer picks up the remaining tasks.

Session: Jump in the Car and Race to the Airport
Well, I had to cut out a little early to make my flight.  Overall, the TechEd experience was a good one and going back over all my notes was a good refresher--a tough task, to be sure, but a useful one.  I'm looking forward to getting the DVDs and, hopefully, all the demo code.  I'm also looking forward to finishing building out my new machine (inspired by this and this), so I can really start digging into WPF and Silverlight2, among other technologies.

As a sidebar to my post on fully-qualified assembly names, I wanted to post the steps I use to sign an assembly.  These steps have changed from what I used to do in .NET 1.1, where I used an assembly annotation in AssemblyInfo.cs to point to the key file.  That attribute has been deprecated in .NET 2.0.

I sign an assembly by creating an SNK file with the SN.exe utility.

1. At the command line, execute sn -k BradTestKey.snk
2. Import the key pair into the machine container by executing, sn -i BradTestKey BradTestKey.snk
3. Open the CSPROJ file in Notepad
4. Under the first <PropertyGroup> node, add <KeyContainerName>BradTestKey</KeyContainerName>

Now, your assembly is signed. 

But wait a minute, what if I only want to sign my Release builds, not my Debug builds.  Can I do that?  Why yes, you can.  A default CSPROJ file will contain MSBuild PropertyGroup nodes that execute either under the Debug or Release configuration mode.  So, here's what you do:

1. Open your CSPROJ file in Notepad
2. Find the <PropertyGroup> that looks like this: <PropertyGroup Condition=" '$(Configuration)|$(Platform)' == 'Release|AnyCPU' ">
3. Under that node, add <KeyContainerName>BradTestKey</KeyContainerName>

Now, only your Release binaries will be signed.

Remember that the BradTestKey.snk and the BradTestKey machine container name are my conventions and you should use your own. 

Proof that is worked (test code is also attached to this post):

ConfigFullDNTests.zip (25.66 kb)

This happens to me frequently: many of the assemblies I write require configuration in the configuration file.  So, I'll write a portion of my unit tests to deserialize an assembly and assert that it received the designated settings from the config.  I also generally deploy signed assemblies (so that they can go into the GAC, etc); most of the time, if I sign an assembly and then run my unit tests, the portion of the unit tests testing my assembly loads from the config fail.  Why?  Because I'm using no longer using a valid fully-qualified assembly name in my test config.  Typically, my test configs will look something like this:

<configuration>

  <configSections>

    <section name="MySection" type="Brad.Tests.ConfigSections.MySection, Brad.Tests.ConfigSections, Version=1.0.0.0, PublicKeyToken=null"/>

  </configSections>

  <MySection someSetting="hello cleveland" />

</configuration>

However, when I sign the Brad.Tests.ConfigSections assembly, the PublicKeyToken value will no longer be null and my test will fail with a configuration exception.

So, why am I bringing all of this up?  Well, the other day, I ran a bunch of tests written by another developer against an assembly I knew was signed.  I figured some of the tests would fail--I just wanted to see which ones.  Interestingly, all passed including the ones written to work with the config file.  So, either the tests were written to work only with a signed assembly (probably not the best approach for a unit test) or something else was afoot.  When I looked at the test config, I saw something like this:

<configuration>

  <configSections>

    <section name="MySection" type="Brad.Tests.ConfigSections.MySection, Brad.Tests.ConfigSections, Version=1.0.0.0"/>

  </configSections>

  <MySection someSetting="hello cleveland" />

</configuration>

Hmm.  The developer used a truncated version of the assembly name.  I didn't know you could do that.  So, let's try some experiments:

Configuration used: "Brad.Tests.ConfigSections.MySection, Brad.Tests.ConfigSections"
Unsigned assembly: works
Signed assembly: works

Configuration used: "Brad.Tests.ConfigSections.MySection, Brad.Tests.ConfigSections, Version=1.0.0.0"
Unsigned assembly: works
Signed assembly: works

Configuration used: "Brad.Tests.ConfigSections.MySection, Brad.Tests.ConfigSections, Version=1.0.0.0, PublicKeyToken=null"
Unsigned assembly: works
Signed assembly: fails

Configuration used: "Brad.Tests.ConfigSections.MySection, Brad.Tests.ConfigSections, Version=1.0.0.0, PublicKeyToken=f479d21bc132bee6"
Unsigned assembly: fails
Signed assembly: works

Let's try something a little different.  Keeping my version at 1.0.0.0, let's this configuration and see what happens:
Configuration used: "Brad.Tests.ConfigSections.MySection, Brad.Tests.ConfigSections, Version=2.0.0.0"
Unsigned assembly: works
Signed assembly: fails

Hmm.  That was interesting: when an assembly is unsigned, the version seems superfluous.  However, when an assembly is signed, the version designation becomes important.

How about this: bump my assembly's version up to 2.0.0.0 and try this configuration:
Configuration used: "Brad.Tests.ConfigSections.MySection, Brad.Tests.ConfigSections, Version=1.0.0.0"
Unsigned assembly: works (guess we still don't care about version number)
Signed assembly: fails

Sidebar on signing assemblies

You know what they say...you never forget your first.  Well, today, I bent my first nail!  A Grip Rite, hot dipped galvanized, 6" 60d nail from Home Depot--also known as a 60 penny nail.  It wasn't pretty, not like this guy, but I did it none the less.  

I've lifted weights off and on for about 20 years now.  I used to set goals for myself: one of my first was the 100% Club.  The athletic department at my high school had created it (as I'm sure every other high school, too): the membership requirement was that you benchpress your body weight 10 times in a row (1 set, 10 reps).  My personal goal was to meet that metric by the end of high school and I achieved it literally on the last day.

I've set other training goals for myself, too, but lately I've just been going through the motions.  Getting one or two workouts in a week was a good week.  Getting a run or two in was even better.  About two months ago, I picked up John Brookfield's book The Grip Master's Manual.  Wow, what a book!  John walks through a whole litany of exercises to turn your grip into a potent weapon.  I found the workout regimen he describes very inspiring and decided to adopt it for myself (at least, most of the less insane exercises--where am I going to find a big boulder to pick up over my head, anyway?).  

So, about two months later, I achieved my first goal.  This has been a big confidence booster for me.  Naturally, I'm now going to work hard to clean up my technique and probably try different variations (I did this bend with a double overhand grip), but I'm also eager to look forward to the next goal.  Maybe it's time to invest in IronMind.com's Bag of Nails?  I don't know--I still can't see spending $65 on nails when my 5lbs box of 60 penny nails cost $12.  Guess I'll have to think about it some more.

 

Session: Making your test lab obsolete with Test Test and Virtualization
Mike Azocar (here , too) conducted this presentation.  As the title suggested, Mike spoke from a completely Microsoft tools-oriented perspective (so, if you have a couple grand more for Team Edition Tester and some of Microsoft's virtualization products, have at it); never the less, I hoped to get a few nuggets of wisdom out of this talk.

Mike discussed Microsoft Hyper-V--near as I can figure, the console for managing your virtual machines in Windows Server 2008--and System Center Virtual Machine Manager (VMM), yet another tool from Microsoft for managing virtual environments.  What's the relationship between these two technologies?  My guess is that Hyper-V is the new and improved VMM for Server 2008, but that's just my guess.

So, Mike talked about authoring tests in Visual Studio Team Edition Tester and then using TeamBuild and VMM for launching virtual machines within which you can test your product.  Mike's presentation seemed to stop at the point of firing up the VM, implying that you then deploy your application to a given VM and begin manually testing in said VM.  I say phooey on that: I want to automate as much as possible.  If I spent money on Team Edition Tester and spent time writing integration tests in the tool, I'd want to leverage that automation in the VM, too.  Fortunately, you can do this.  Mike said that you simply change the URLs used by the integration (web) tests to that of your deployment in the given VM.  Again, is this a manual change or can this alteration be automated, too?  I assume that the Team Tester integration tests store the URLs being tested in some sort of config file, so I suspect that with a little bit of work, one could author some MSBuild/TeamBuild script to alter the web test URLs to point to the deployment in the VM.

The biggest gem I got out of this presentation was a quick five minute aside by Mike describing how VMM spins up a new VM: apparently, it uses Powershell to do this.  Sweet.  Mike quickly flashed one of these scripts and I scribbled down two cmdlets:

• get-VM
• get-dvddrive

Hmm.  I wonder where I can get these cmdlets?  Mike wasn't sure, but he said that there are a few communities out there on CodePlex and the rest of the inter-tubes where I would likely be able to find them (I suspect, though, that they're really part of the VMM installation).  I also caught a brief glimpse of the MSBuild/TeamBuild script Mike was using to power the build and test deploy of his demo app.  It included this line:

<exec command="xcopy..."/>

So, in a post build event, Mike is shelling out to xcopy to deploy his solution to the VM.  No magic there.

As I've said before, some day I'd love to see some innovative presenter(s) take many of these TechEd presentations and add the subtitle, "On the Cheap."  Thus, how would one approach "Making your test lab obsolete with XX and Virtualization...On the Cheap"?  I would think you would author your integration tests with something like WatiN, WatiR, and/or Selenium.  For the virtualization piece, you're like not going to get away from the expense of VMM or VMWare--but, what are you gonna do?  For the glue in-between, Mike's given me some clues for constructing an MSBuild script for deployment (no TeamBuild 'cause TFS costs money and, anyway, my company thinks ClearCase solves everything from source control to world hunger) and for constructing a Powershell script for spinning up a VM to host my test deployment.  Good enough for now.

Session: Data Access Layer: Architectural Concerns for Object/Relational Mappers (O/R-M) with Examples in NHibernate
Last year, I attended BOF moderated by Jeff Palermo, but not a session.  I didn't know what I missed until I attended this one.  Man, Jeff's a really dynamic speaker.  That really helps, too, when you've hit midmorning and you're coming down from your early morning coffee binge.

On a side note, he filled the pre-session dead air with a music montages including the fantastic Code Monkey.  If he were accepting requests, I would have suggested Web 2.0 Bubble or the non-musical but still entertaining New Media Douchebag.

So, the general point of Jeff's presentation was about making separation of concern decisions in your architecture so as to abstract away your Data Access code for better testability, maintenance, and upgrade (switching to newer, better, or alternative technologies).  This session was vaguely reminiscent of Paul Sheriff's From Zero to N-Tier presentation that I discussed previously, but Jeff had lots of great examples around loose couple (dependency injection) and unit testing.  One thing I found interesting was his terminology for the different layers of an application.  I noticed this terminology used by other presenters at the conference, too.  Maybe it's time I update my lingo:

Jeff's Terminology	Mine
User Interface (UI)	UI
Core	Business Layer (BAL)
Infrastructure	Data Layer (DAL)

Jeff strongly suggested reading the book Domain Driven Design by Eric Evans.

Jeff is another one of these types--like Scott Hanselman and Scott Cate as previously noted--who likes to code for most of his presentation.  Actually, come to think of it, his demo was largely completed prior to the presentation--he just navigated around his demo the majority of the time (which was still much better than just staring at Powerpoint slides).  And, like Scott Cate, he was kind enough to share his demo code (and code from other presentations) on his Google Code page.

Another aspect that attracted me to Jeff's presentation was his use of NHibernate in his presentation.  Finally, a presentation that doesn't toe the full Microsoft line (or maybe I should just be thankful that Entity Framework hasn't shipped yet).  He made some pretty good use of NHibernate, too, particularly in his unit tests.  Another novel convention was his use of StructureMap in his demo code--now that's pretty audacious of Jeff, considering that Unity Framework has been RTMed.  What's going to happen next--use NUnit instead of MSTest?  Perish the thought!

Session: Building Data Visualization Applications with the Windows Presentation Foundation
Up till now, I've been rather successful at avoiding these new user interface technologies--I've always considered myself more of a coder than designer, anyway (or at least I acknowledge that I stink at UI design).  However, there's seems no escaping the UI borg, so I thought I'd at least let Tim Huckaby assimilate me.  Besides, I've always enjoyed his conversations on .NET Rocks.

Tim just powered through his presentation with example after example.  He kicked things off with a demo of his famous Cancer application.  The Cancer application was a WPF application on top of a Sharepoint platform.  It was pretty awesome.  The WPF UI would display molecules in 3D and allow the user to rotate them around, do annotations, and more.  The .NET Rocks guys interviewed Tim on the application last year and Tim said that other developers have adapted the application for other purposes, like CAD work.  Tim showed those adaptations off a little, too.

Next, Tim went through a series of demos of different third party controls designed for use with WPF.  Very cool stuff, but, of course, they ain't free.

For one of his final demos, Tim brought up two guys from...uh...er...well, the name of the company escapes me and I didn't write it down.  Not important anyway.  The company writes software for casinos; Tim had them demo one of their latest solutions--a really cool application that acted like it's own mini desktop.  It had this cool, animated wallpaper in a frame with different icons on it representing different applications.  They launched one of these icons to reveal an application that collected and analyzed data from the different games and slot machines on the casino floor.  What I found most interesting about the application--aside from its already innovative use of WPF--was a button labeled 3D.  The developers said they had one requirement that they just could seem to accommodate with WPF--their client wanted a feature in which a user could walk through the casino floor virtually in 3D.  According to the developers, WPF couldn't deliver on this, so they went to Plan B: XNA.  They somehow rigged up their WPF application so that it could shell out to an XNA application representing a 3D model of the casino floor.  Really cool.

Tim wrapped up with a few reading recommendations--well, one that I wrote down, anyway.  WPF Unleashed by Adam Nathan.  He also posted up links to most of his presentation on his blog.

Session: Separation of Concerns: New Practices for Decreasing Coupling and Raising Cohesion
The presenter for this session was French Canadian Mario Cardinal.  Although he had an outrageous accent, his presentation was a good, all-purpose push for separation of concerns via Dependency Injection, the use of interfaces to better decouple implementation details, etc.  Overall, my biggest take away from this presentation was the fact that Mario was basically echoing the same story line that Jeff Palermo delivered earlier today and that I heard from Juval Lowy two days before: separating your logical layers by interface is a good design approach.  It's good to hear this message coming from multiple, independent sources.

Mario talked about two ways of transferring object "instantiation to an external party": a pull approach via indirection and a push approach via inversion of control.  Indirection is characterized by factories, registry, and a construct commonly called the Service Locator.  These helper constructs commonly use reflection to load up the proper implementation instance, but one thing to note about this approach is that the "service locator must be visible [to] every object."  I guess that means that every object served up by a Service Locator must reference this helper construct?  I can see how that would be bad if you decide to later swap out your current Service Locator with another.  Inversion of Control/Dependency Injection apparently has a better decoupling story but introduces more complexity (as evidenced by this increasingly ambiguous blog post).  Mario seemed to fall on the IoC/DI side of the fence for the most part, showed some examples, and then talked briefly about some of the available DI frameworks (and stressed that you shouldn't write your own):

• NInject
• StructureMap (also, Jeremy Miller's primer on IoC)
• Castle MicroKernel (Windsor)
• Spring.Net
• Unity

Pulling back slightly, Mario talked about the logical layers in general and identified these four basic layers:

• Presentation - contains the views
• Application Model - contains the controllers
• Domain Logic - contains the work of the business domain
• Infrastructure - provides services to communicate with external infrastructure (configuration, persistence, logging, caching, security)

The terms sound vaguely similar to the terminology Jeff Palermo was using in his presentation earlier in the day.  Mario also mentioned how the thoughtful construction of namespaces can help promote better decoupling and how tools like NDepend can be used to determine architectural violations.

Session: Architects: How are they made?
I generally try to avoid touchy-feely, non-technical discussions, opting for sessions with real technical meat.  To me, I'd rather know all my technical options to solving a problem--I feel like I'm pretty good at figuring out how to piece together all the different bits into something coherent and effective.  Never the less, this session was put on by Rocky Lhotka--someone who's opinion is well respected and someone who takes a very practical approach to technology and architecture.  So, I thought I'd give it a go.

Actually, the session made for a good end-of-day talk: not too many details to focus on; just a conversation around the dynamics of software architecture and design.  Rocky started by giving us a bit of his resume, so as to give us some context as to how he has developed his opinions regarding software architecture.  Boy, does he have a lot of experience.  Sometimes, it might be nice to hear other speakers outline their career path and their usage of whatever it is they're presenting on so that we can put their statements in a better context (I would say the same for the idiot talking heads on the nightly news, but that's a post for a different blog).

Rocky identified three main categories of architects:

• Application Architect
• Enterprise Architect
• Systems Architect

Interestingly, these types map roughly to what we've talked about in the Architecture Special Interest Group at the Cincinnati .NET User Group.  Rocky went on to outline several personality types of architects.  These include:

• The Rock Star
• The Artist
• The Daredevil
• The Carpenter
• The Strategist
• The Guard

Each type brings unique opportunities and baggage.  Some, like the Rock Star and the Daredevil, bring an improved speed-to-market ratio, but tend to introduce a certain level of instability in the solution, development team, or both.  Others, like the Carpenter or Strategist, bring a lot of thought and planning to the to the architecture process, but can sometimes sit and ponder for too long.  I feel like I'm too much of a Strategist when it comes to solving many problems, including my .NET to JMS problem--do I continue with a monolithic wrapper around the Tibco API?  Do I jump on an open source offering like Spring.NET or NMS?  Do I write my own adapter for WCF (like IBM did for MQ Series--which begs the question, where is Tibco on this one)?  What do I do...what do I do?  Let me sit and strategize some more.

Session: Party at Universal Studios
After another long day of learning more cool technologies--don't you just feel sorry for us?--Microsoft rewarded us conference attendees with a night a Universal Studios.  Art, Jay, and I enjoyed a good night of food, beer, and rides.  Probably the highlight of the evening was the Simpsons ride, where I think I spent half the time laughing at Art's chortles.  The Men In Black ride was fun, too--I still don't know how Jay got double my score, though.

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)