I haven't taken much of a look a the .NET Roadmap so I have a naive request: If I, now, don't have to declare the type when declaring the variable name when using var (C#) or Option Infer (VB.NET), it would be nice to also have return type assumed to be void (C#) or Sub (VB.NET) unless I specify otherwise.

Original Syntax
C#

VB.NET

Proposed New Syntax
C#

VB.NET

There are a load of countries that will be having access to the new 3G iPhone come July 11th. As I understand it, Rogers is the exclusive carrier in Canada and have announced their price plans. Prices for the device are speculated to be CAD$199 for the 8GB and CAD$299 for the 16GB, with signing up for a 3 year contract. Since a friend of mine showed me his iPhone I have been drooling over getting myself one. The wait is nearly over!

I've only started using VB.NET in the past year and a half on client projects. Prior to that it was always C#. I now consider myself fluently bi-lingual in either language as I make VB.NET syntax errors in my C# code as well as still making C# syntax errors in my VB.NET code.

Since using VB.NET I've noticed that, though VB.NET is supposedly a "first order" language in the Microsoft stable, there are a few things that make that facade seem fairly thin:

• Create a new project (File > New > Project) in Visual Studio (full installation) and you'll notice that Visual C# is a root node element in the Project types tree where Visual Basic is buried under the "Other Languages" node.
• MSDN documentation for tasks as routine as sending an email will include sample code for C#, C++, and even J# while noticeably omitting a VB.NET sample.
• New language features of C# often take at least one point release of the framework to become available within VB.NET. Case in point: InternalsVisibleTo (now available).

I am sure the list is endless. These are just the top ones that stick in my mind at the moment.

It's struck me, since I have been working in VB.NET, that certain language semantics aren't translated properly across the different CLR languages.

e.g. Assert.IsNotNull (C#) should be Assert.IsNotNothing (VB.NET).

I am not certain how many of these semantics there are. Maybe it's something the languages teams could add into a future version of VS (please make it automagic with the option of setting an attribute).

Today I was asked why choose a validation framework over good ol' object.Validate(..) and given permission to publish the response.

     object.Validate is just fine except that the behavior doesn't serialize across the wire (it "will" if you re-instantiate the object on the other side if you are using a shared assembly, but won't if you are using object generated from the proxy in things like JSON, AJAX, or other client types what build their types from a WSDL or other schema. Often you will want the ability to do some validation on a client prior to firing it across the wire. Or... should the previous sentence read "firing it across to a long-running process"? More on this...

    One thing I have been thinking about, when it comes to object validation, was spawned by reading up on using enterprise service bus'. NServiceBus creator, Udi Dahan makes the distinction between "stateless services" like the classic calculator service and "statefull services", termed "sagas", which (and I hope I am close on this) can involve multiple domain objects but, more importantly, require state to complete their work. These 'sagas' are typically longer running, durable, transactionally processed messages that encapsulate business logic.

    My paraphrased definition for a statefull service likely does not do justice to the depth that is intended, but tie that binds the discussion of service purposing and validation is that there is often a struggle with how to do object validation in a re-usable (both sides of the wire) fashion. Validating that a type is not null or that it's value is a member of a natural number set is not something that requires state. Making a call to a value object validation service may be able to provide that point of re-use. It can be called from a client prior to calling one of those long-running sagas and your statefull service when doing its initial cleansing of the data it's receiving. Though that still incurs the cost of an additional network call (two if you consider that your statefull service will be calling the service as well), it frees those saga services from being bogged down with duplicated validation logic. This also enables you to use clients that can't share your assembly (JSON, JAVA, etc.) to utilize the stateless validation service.

    So,  combining object validation frameworks with stateless services/services (SOA or otherwise)... there's my thoughts for today. *signing off*

Coincidentally, I was going to blog about this very topic later on today as I was doing the same thing when working on validation stuff as I wanted to leave the assembly 2.0 compatible. Derik Whittaker beat me to it and did a more extensive job than I was planning. Check it out!!

I've updated a sample used for decorating types for validation (a la Nullable) that I produced a while back. I upgraded the project for VS 2K8, added type conversion operators to the Validatable decorator, changed the default behavior of the validation method, and ReSharper-ed the code to clean it up some more. The code and files for can be found here.

I have used StructureMap as the IoC container within ASP.NET MVC (MS marketing leaves the caps lock on I guess ) on a previous project. This time around, I decided to give Unity a try. The one advantage I liked with Unity is that I don't have to maintain the mapping files like I do in StructureMap.

Be sure to check out David Hayden's Unity IoC - Dependency Injection in ASP.NET MVC Framework Screencast as well as his article, "ASP.NET MVC Framework and Unity Dependency Injection Container" (Part I and Part II) to get started. Thank you, David, for the excellent resources!

The advantages of using a baked library are obvious. Sometimes, when you have to manage the dependencies, it can quickly become a nightmare. Thankfully, with .NET, the IDE generally takes care of making sure you have your references set. This is not so with javascript. The order in which they appear on the page matters. When you are using technologies like Master Pages, things can get even more hairy. Enter YUI Loader. YUI is a javascript library from your good friends at Microsoft (whoops... that sale hasn't go through... yet)... I mean Yahoo. There are a tonne (metric AND imperial) of controls and each comes with its own set of dependencies contained within the library. Adding 2 or 3 controls to your pages can quickly get your <script type="text/javascript"> references to be quite a lengthy as well as unruly list.

Thankfully, Yahoo provides a tool they call YUI Loader that has the smarts baked into it regarding what dependent javascript files are needed. You simply provide it with a name and it loads it up. If you have multiple, simply put them all into the list and, voila, it also makes sure the dependencies are also loaded up properly for those as well. I highly recommend using this tool, if you're using other or multiple javascript libraries and even if you're not using YUI for anything else... yeahp it handles javascript other than just the YUI stuff too.

Many thanks to Michael Goldobin for his post on Fixing Continuous Integration build for a .NET 3.5 project. We started receiving the error after finally implementing some mocked out services. Just as suggested, we installed Windows SDK for Windows Server 2008 and .NET Framework 3.5 (warning: 1330.0 MB in size) on the build machine and all was well.

Okay, this is quite off topic for this blog, but it so struck me that I just had to write about it.

I tuned into The Score this evening to catch some professional sports highlights of the game between the Washington Nationals vs. the Milwaukee Brewers. I know I am no athlete, but watching Prince Fielder (1st base for the Brewers) and Dmitri Young (1st base for the Nationals) made me reconsider my stance on whether playing video games should be considered a sport.

Oh, yeah, and by the way, the final score was 4-3 for the Brewers. <- statistics inserted for... ah... who cares.

A little bit late but....

The presentation by Tom Opgenorth on Monorail was fantastic. It gave me ideas as to how to use Microsoft's MVC in the current project I am working on, and gave me ideas as to some of the pain points of MVC and IoC frameworks.

The number one thing that has always bugged me about MVC and IoC is that everything resides in an xml/config file. The concept of being able to plug and play is fine with me; you can change things out without recompiling. A simple flip of a switch and *shazam* it's all hooked up and running.

The problem is in the details.

First (two-part-er)
a) Post-deployment troubleshooting:
When stuff inevitably breaks (I know I am the only one who has ever written code that has broken... but please bear with me), it is often difficult to resolve where the break happened or how to fix it. I know you can write applications more robustly but, when the story or use case has been coded... we're forced to move on. The business value of writing an application that can heal itself or give meaningful feedback when "stuff" happens is, far too often, lost on product owners or business analysts. The functionality delivered to the end user is so high on the list (and, rightfully) that these sorts of details are neglected.

b) Post-deployment maintenance:
A side issue is that, in many of the larger organizations I have worked at, developers are expected to hand off the application to a deployment/maintenance team to manage. Far too often there are so many other applications on their plates that this type of application complexity puts me squarely back in the seat of managing the application when it breaks. Having configuration files for non-developers to be able to touch and muck with increases the fragility of a deployed application. Just reminds me of installing any number of crazy combination dependencies to get some Linux applications working properly on older versions of Linux (that didn't have aids to help manage dependencies). This puts me squarely back into the saddle of maintaining this application or into documentation hell and introduces a dependency of the client on my services. Great for job security... if that's the type you are looking for.

Second
Lack of Testing around the "And then magic happens":
Separating out dependency instantiation from class implementation is a good idea. It helps set up an environment where people can work on/test parts of the system independently. But... with most IoC Containers I have seen (though this is only through demonstrations), the wiring up of the configuration of what class to instantiate the dependency is often lacking testing. This can result in an exception being thrown at run-time (arguably the worst time to throw unhandled exceptions) if no dependency is actually wired up. Maybe this is a call for a profiling application to check class dependencies and ensure that they are all wired up within the IoC framework and included as part of the release criteria for the application?!?!

Anyway, watching Tom's presentation was very thought provoking. He did a good job of getting through a lot of material. Thank you to the Edmonton .NET User Group for facilitating a great evening.

I was contacted by Patrick Smacchia and extended the opportunity to try nDepend. I took this as an opportunity to learn more about the metrics beyond my more familiar test coverage (nCover, nCoverExplorer), code style compliance (FxCop and Code Style Enforcer), and the like.

My first impression was that I was confused by the interface. It looks confusing. When I click on different parts of the UI, other things change and flip around. I didn't understand the metrics being measured and how they were being displayed.

Okay... the first 5 minutes were up and the curiosity bug hit me. I wanted to know what all this information was about and how to better use this tool. I went to the web site and found the online demos on the Getting Started page. There are (currently) 8 separate demos available. After only the first two (6 minutes) the light bulb started to turn on. There is a LOT of information to digest. This tools reports 83 different metrics at different levels of analysis. The investment in online tutorials and web site opened a huge door. To be sure, there's a lot more for me to sink my teeth into in this tool.

One of the coolest features I discovered was that, when you click on the bubbly report in the metrics window, the toolbar presents a drop-down where you can select which metric you want reported in the metrics window. The nice part about that is that you select the metric to report on, the report generates, and all you have to do is look at where the biggest squares are (left to right) to find out what the biggest culprits are to take a look at. Pretty slick!

When companies advertise for developers to come in to write a maintainable application for them they (solely from a business perspective) are often looking for an application to be developed that does what it's supposed to and comes with little to no maintenance after the fact (for the agilistas out there... "As an application owner I want to deploy an application that does what it is supposed to and doesn't have high cost of ownership after delivery by requiring full time monitoring/bug fixing staff"). From a development perspective, we often only think of a maintainable system as code that's sufficiently tested to help avoid having changes to a system have cascading effects. I believe that there is a gap in what defines a "maintainable" system and leads to "Maintainability Mismatch Impedance". Certainly the two are related but, certainly, they don't fully address each others' needs.

It is generally considered poor form to have to have Visual Studio installed on your build machine as you should be able to build your product without a dependency on the IDE. I was informed that the Visual Studio Setup and Deployment Projects (used to create the msi files) can not yet be compiled and linked without the use of Visual Studio. With this understanding, we used wix to perform the automated build of the windows installers. After downloading the binaries and reading the help and getting started tutorial we had a completely automated  build and deployment process. This took less than 3 hours to get up and running. Definitely a delight.

I was sent messages on two occasions this week via the Live Spaces send so-and-so a message feature. If you want me to respond, you have to enable responses in your communication settings (Options > Communication preferences > Send messages to your Spaces inbox), otherwise I have no way to respond to your request as it doesn't include an email address.

Go to the MSDN web site and register to get partial versions of Introducing Microsoft Silverlight 1.0, Introducing Microsoft Linq, Introducing Microsoft ASP.NET AJAX. Better than a kick in the pants.

I was having difficulty getting a WCF service that I had built on my Windows XP machine up and running on my Windows Vista machine. Thanks to Jaime Rodriguez for his post on Running a Windows Communication Foundation (WCF/Indigo) service in Windows Vista. It saved me a bucket-load of time.

From the Visual Basic Programming Guide on Extension Methods (applicable to C# as well), an important blurb on extension method precedence: