Devlicio.us - Just the Tasty Bits

A Follow-up to my Azure Panic Attack

Rob Eisenberg — Sun, 08 Nov 2009 21:25:00 GMT

In this post, I panicked a bit about an email I received from The Azure Team ;) In short, the email said that my storage account was going to be deleted on November 3rd if I didn’t migrate it to the new servers. I received the email around 6pm on November 2nd. Yikes! I feared that we might lose all of Silver Arcade’s assets. After a bit of research, I discovered that I should have received a similar email warning me about this change several months ago. Something went wrong somewhere, somehow. In any case, I managed to get all of our data backed up using Cloud Storage Studio which Bill Reiss had recommended to me. While I was doing this, I was frantically trying to get into contact with someone from the Azure team. I emailed Steve Marx. He responded quickly and had a plan of action. We had a short email exchange and within a couple hours I was in contact with the right people. The Azure Team to the rescue! Once the team was made aware of my situation, they offered to migrate my data for me. Awesome! While I started out the evening in a bit of a panic, the Azure team restored my confidence. They treated me well and met my needs with excellence. Thanks for being committed to your customers!

Iowa Code Camp November 2009 Slides Up

Scott Seely — Sun, 08 Nov 2009 00:39:00 GMT

I want to send out a big thank you to the team who put together the Iowa Code Camp. You people did an awesome job!!! I had a great time giving my talks and really enjoyed hanging out with the crowd in Iowa.

For those of you who attended my talks, or just want to see the materials, I’ve posted things.

WCF Diagnostics Talk and Materials

WinDBG Talk and Materials

See you next year…

ReSharper Rename Namespace Grayed Out

Michael Nichols — Fri, 06 Nov 2009 15:53:55 GMT

I renamed a folder in my project and opened up the solution.

When I tried to fix namespacing in the project using Resharper (ClassView, Ctl+Shft+R, Rename), it would not let me.

I had not rebuilt the solution after having done the rename, so once I did my Rename function was back.

It takes real balls to do it right

Derik Whittaker — Fri, 06 Nov 2009 10:57:19 GMT

It does not take a genius to realize that I (and most others on this blog) are fans of JetBrains. But what it may take a genius to realize is it takes balls to do what JetBrains does with their products.

You may be asking what exactly I am talking about or referring to? I am taking about the fact that they are willing to throw caution to the wind and provide very early (and in many cases mostly stable) release of their products to the wild. What makes this even more crazy/impressive is that they build products for software developers and we all know that software developers are the most vocal and opinionated group of people out there.

The fact that JetBrains releases software early and often simply makes sense and ALL companies that release software (regardless of the type) and not be afraid of what may happen. Because putting your product (in this case software) in front of customers early and often will allow you to:

Find and resolve more bugs
Find and resolve any weak area in usage or workflow
Find areas of the application that are still lacking

Now the trick to releasing pre-alpha, alpha or even beta software is you MUST listen users feedback and attempt to incorporate or fix any areas of concern (of course only make adjustments if they make sense for the product).

So, what is the point of this post? Well 2 things. 1 to give kudos to JetBrains for again releasing early copies of their software and 2 tell all software companies that releasing early and often will result in a better product.

Till next time,

LG BD390 Blu-ray player and D-Link DIR 655 Router: not friends

sergiopereira — Thu, 05 Nov 2009 00:33:00 GMT

A month or so ago I bought a Blu-ray player. I waited a bit to buy one of those because, frankly speaking, the improved image quality and any bonus features in the discs weren't attractive enough for me to replace the DVD player.

I also wanted a networked player that could stream movies from my Netflix queue. To make matters worse, running a CAT-5 cable from my basement (where my wireless router lives) to the bedroom (the BR player's final destination) wasn't really something I was looking forward to.

That's when I did some shopping around and came across the LG BD390 Wi-Fi-enabled Blu-ray player. It supports wireless 802.11n and access to a few online services like YouTube, Netflix and VUDU. It can also find media in my home network.

Note: I know there's always someone that will come suggest taking a look at the PS3 or XBOX can do some or all of that. I'm not a gamer so I didn't want to have a gaming console in my bedroom and deal with issues related to the not being a simple player aspects of the device (like maybe having to buy extra adapters/connectors, remote control, and what-have-you). It's probably a no-brainer if you're into video games. Did I say I do not buy Sony?

Welcome LG BD390

So I went and bought the LG BD390 and installed it where it was supposed to be. I was a little worried about not having the 802.11n router setup yet (it was still on its way) but I decided to give it a shot even on my 5-year old 802.11g router. I thought maybe I wouldn't get HD streaming or choppy video, but at least I would get a feeling about the device's capabilities while I waited for the new router to arrive.

Works great on wireless-G

To my surprise, the LG BD390 worked great over wireless-G. Setup is incredibly easy (the only hard part was really entering the long WPA password using the on-screen keyboard.) It boots up fast. Within 5 minutes from its first power-on it had already found and updated its firmware, I had activated my Netflix streaming and The Office was streaming in HD on my TV.

Best gadget purchase in years. This device will definitely change the way I watch movies and TV series, and listen to music (BTW, since it's easy to upgrade the firmware and other LG products offer Pandora, here's to hoping the BD390 gets that too soon.)

But not so fast. Bad wireless-N surprise.

You'd think that by upgrading my network to wireless-N would only make the whole experience much better, right? Me too.

I upgraded my trusty wireless-G router with a shiny new D-Link DIR 655 wireless-N Gigabit model. It has some interesting features, USB port, decent firmware features (well, read on,) and seems rather popular anyway.

Once I configured it to the exact same network settings as the previous router, I checked the laptops were working fine with it and went straight to enjoy some more streaming on my Blur-ray player. I immediately noticed that the signal strength had dropped from 5 bars to 2, 1, and sometimes no bars at all. Even when a couple of bars were there, it wouldn't even browse my local network.

I even tried using a cheap-o router in repeater mode but it didn't play well with my D-Link router and even the laptops would lose connectivity at random when this thing was active — I ended up returning it.

A month later (and a few lost frustrating hours) later I came across this post on the Amazon reviews for the player. Basically, even though there was a new firmware available, the router insisted in telling me it had the latest one. And it just so happens that the firmware it had (v1.2) had some serious bugs. Short version, many times it would not work at all with the Blu-ray player.

I followed the suggested instructions and things are much better now. I still get a very weak signal but at least I'm able to consistently stream HD content. I hope the next version of the BD390 comes with an external antenna. I might try another router and see if they have a stronger signal — this seems to be a common complaint about this D-Link model.

So if you're in the market for a Blu-ray player I can recommend LG's BD390 but I'd suggest you search the web for any issues with your wireless-N router (unless you're planning to wire it up, in that case I recommended it 100%). If you're buying your router together with the BR player, buy it from a store that you can easily return it in case it doesn't work well with the BR player. On the other hand, if you're looking for a new router, I cannot recommend D-Link's DIR 655.

Speaking at Virtual ALT.NET Tonight

Billy McCafferty — Wed, 04 Nov 2009 17:07:00 GMT

If you're interested in...

Finding out what's new in S#arp Architecture Q3 2009,
Hearing about what the Contrib project has to offer,
Going into a couple of S#arp topics in detail, such as...
- Getting up and running quickly,
- Handling object associations,
- Using an Application Services layer and
- Practical implementation of Command/Query Separation (or "Domain/Reporting Separation" from my perspective).

Then join us tonight at Virtual ALT.NET, 9 - 11 PM Eastern time.

Billy McCafferty

Microsoft, what is the meaning of this?

Rob Eisenberg — Tue, 03 Nov 2009 00:01:21 GMT

I just received this email on November 2nd at 6pm. I hadn’t heard a word of this prior. Thanks for the warning…

Windows Azure CTP participant,

You are receiving this mail because you have an application or storage account in Windows Azure in the “USA - Northwest” region. Windows Azure production applications and storage will no longer be supported in the ‘USA-Northwest’ region. We will be deleting all Windows Azure applications and storage accounts in the “USA - Northwest” region on November 3rd.

To move your application/storage, first delete the project using the “Delete Service” button. Then recreate it, choosing the “USA - Southwest” region. (It may take a few minutes for your previous application and storage account names to become available again.)

Note that deleting your storage account will destroy all of the data stored in that account. Copy any data you wish to preserve first.

If you would like help migrating your project or have any other concerns, please reply to this mail.

- The Windows Azure Team

When NHibernate Won't Do What You Think It Should

Jak Charlton — Mon, 02 Nov 2009 13:57:00 GMT

There are times, when you just think something should work, and one way or another it just doesn't. I've been having one of those weeks with NHibernate. I have been using MS SQL Server 2008 spatial searching, along with SQL Server Full text search, and using NHibernate for almost all my data access.

The only problem is that NHibernate out of the box doesn't like to play nicely with Spatial or Fulltext. After head scratching, head bashing, and general teeth grinding I figured better to cut my losses and ask some people that actually knew what they were doing.

Firstly I fired a twitter off in the direction of Ayende to get a feel for whether I was doing something wrong - with CreateSqlQuery NHibernate didn't want me to use the Spatial stuff - NHibernate uses a colon : to identify parameters, but in SQL 2008 Microsoft decided to use a double colon :: in it's spatial bits, so for example to declare a point you would use:

geography::STGeomFromText('POINT(51.520223 -0.094693 )', 4326)

That promptly causes NH to stop you from carrying on with a missing parameter. Ayende did indeed confirm it's not right, and after a few helpful suggestions he ran out of quick wins and suggested I might want to take advantage of his commercial support for NHibernate. I'm not adverse to such a solution, but felt this one might get complex, and Ayende's payment structure didn't fit my needs - this is a small project for a small client, and I could work around NH's limitations by using stored procedures (yes, I know, heresy).

After a bit more head scratching I remebered that iMeta also provide NH commecial support now, and having taken a look at their pages, I figured it would work much better for my limited budget.

After a quick chat with Hadi Hariri, he directed me on to Steve Strong, the man who wrote a great deal of the Linq to NHibernate stuff, and a bit of an expert on the parser.

Steve ripped through my queries with lighning pace, and had me a viable solution that afternoon - now that's what I call customer service. Today Steve has continued to sort out niggles with the problem, and it looks like we may have identified a few bugs in NHibernate Spatial and possibly the parser, which Steve will now push back into the NH trunk for future geenrations to benefit from.

So, althought NHibernate is open source software, and in theory you can fix this stuff yourself, this is just a post to point out that sometimes the best use of your time and effort is in things you can deal with quickly, and sometimes it is worth paying some real specialists to help out - the cost saving could be immense. If you have problems with NHibernate, I encourage you to take a look at the offerings available, especially the iMeta one :)

Just because NHibernate is free - doesn't mean it isn't worth paying for!

Speaking at nPlus1 ArcSummit- Chicago

Scott Seely — Mon, 02 Nov 2009 13:18:00 GMT

On December 7, I’ll be speaking at the nPlus1 ArcSummit for the optional morning session. I’d love to see the place packed! Here are the details:

https://www.clicktoattend.com/invitation.aspx?code=142763

About nPlus1.org

nPlus1.org is a site dedicated to helping Architects, aspiring Architects and Lead Developers learn, connect and contribute. On this site you’ll have access to great first party content written by some of the most skilled and experienced Architects working today. You’ll also have access to, and be able to contribute to a nexus of content from around the Internet aimed at keeping Architects up to date on all the new developments in their fields of interest.

When

Monday December 7, 2009 – 10:00PM to 5:00PM

Where

Microsoft MTC - Aon Center

200 E. Randolph

Suite 200

Chicago, IL 60601

driving directions

Free Lunch Provided

Agenda

Morning Session (Optional): An Introduction to Object Oriented Programming

10:00 AM - 12:00 PM

Are you new to OOP? Do you want a refresher on the benefits of Interfaces and the differences between implements and extends? The morning session is a two hour introductory course of Object Oriented Programming. If you are new to OOP the lessons in this session will prepare you for the more advanced topics in the afternoon.

If you are already well versed in OOP then feel free to come have a refresher, or simply join us for lunch and the advanced sessions in the afternoon. The morning session is completely optional.

Afternoon sessions:

Session One: Software Patterns

Patterns are an important tool to use as architects and developers. They provide a common vocabulary for us to design with, as well as a common approach to a common problem. Come learn about useful patterns, and how to use them in your everyday code.

Session Two: How I Learned To Love Dependency Injection

Dependency Injection is one of those scary topics that most developers avoid. It sounds all ‘high-falootin’ and complex. It’s not. Really. We wouldn’t lie. It’s a great way to manage complexity in your system, and a great way to make your system so much more testable. And isn’t that what we all want?

Each session will be followed by open discussions periods.

A catered lunch will be provided starting at noon. This will divide the morning introductory sessions from the advanced sessions. Register once for all session and choose to attend the morning, the afternoon or both! Lunch is provided for attendees for any of the sessions.

Development Methodology "Renovation"

Jeff Perrin — Sun, 01 Nov 2009 00:18:00 GMT

I was watching Holmes on Homes today and got to thinking about parallels (or lack of them) between renovating and building a home vs developing a software application. Some of what I was thinking ties in with the "software development as craftsmanship" discussion that pops up every now and then, but mainly this is just a brain dump. First off, let's set this up. What I'm thinking is that a "software application" maps directly to a "home renovation project" or just actually building a new home. Here are some of the obvious parallels:

In a home building project you have a general contractor who oversees the entire operation, hiring other contractors or bringing in employees as needed. Software projects will generally have some sort of equivalent "lead/architect" role.
Both projects would have clients that most likely have no idea what's going on. They see the end result and have no way of knowing whether that result will last 2 months or 20 years. Generally, as long as the finished product looks pretty and seems to do what's required the developers/renovators will get paid.
Size matters in both professions. Anybody can hack their way through installing new countertops or building a simple CRUD web app, but the bigger and more complex the problem gets, the more professionalism and care is required. I'll take a calculated leap and say that many of the problem projects in both professions happen because somebody who can "install a new faucet" gets it in their heads that they can also "renovate the entire basement" using the same amount of knowledge and preparation.

I'm sure there's a few more parallels, but you get the idea. Now let's focus on some differences...

A general contractor doing a home renovation will bring in "specialists" to work on individual pieces of the project, whereas many software projects are made up of "generalists". As programmers, we are often tasked with developing business logic, writing html, security, usability, system administration, deployment, testing, etc. Just look at the range of what's required in the average job posting for a software developer. This is obviously not true in all cases, but in general this is what I think is happening out there.
The home building industry has these crazy things called "inspections" that are supposed to ensure the builders don't pull some crazy shit that could endanger the client. Imagine code inspections (by an honest inspector we hope) and how they could protect a client... An inspector could obviously not be expected to know if the application is running a calculation correctly, but that is the one thing that a client can confirm. An inspector could, however, check for signs of incompetence such as SQL injection vulnerabilities, obvious spaghetti code, code duplication, lack of tests, poorly designed databases, mangled HTML, obvious usability disasters and so on. Once notified of the issues, the client would be able to take action as they see fit.

My thinking is that, at least in my own experience, the best project I've worked on (in terms of happiness of the client and its likelihood of being maintainable for years to come) was the project that was most similar to a successful home reno project. We had a UI specialist, a bunch of developers focused mainly on the business logic, and testers. Other "specialists" were brought in as needed for database tuning and system admin type work. An "inspector" even came to the project at one stage. This inspector was Eric Evans, who showed up and observed the project for a week and delivered a report on what was good and what could be improved. This visit seemed to be largely positive (I showed up a few months after he came so I can't know for sure) in the sense that it gave the development team some reassurance and some focus on what could be improved. I'm not sure what the clients got out of it. I'm wondering if a working on a new project with the goal of running it consciously more like a home reno project could improve things. For example:

Think of hiring for "concerns" instead of technologies (ie; security & usability instead of Java & Struts).
Have a defined "general contractor" role that is in place to hire and fit all the pieces together.
Allow the specialists to come and go. There's no need to keep everyone around all the time. Call them in when there is a need.

Based on my own limited experience I think doing software development as a home renovation could really work, especially when it comes to focusing on roles and quality. Should any project be open to an SQL injection attack ever? Hell no, there's just no excuse for that kind of incompetence. But so many are... Inspections and specialists might be one way to mitigate this. In closing, I'd like to hear other people's thoughts on this. If it's already been said before (better hopefully), I'd like to read more about it.

NHProf and Caliburn Testability

Rob Eisenberg — Fri, 30 Oct 2009 19:07:00 GMT

I’ve heard some developers asking about UI testing lately. Specifically, there have been some questions about what we did with NHProf. So, I thought I would write a little bit about that here.

There are a variety of different types of tests you can do. In my experience some have a better ROI than others. For example, we don’t do any UI testing with automation APIs. Those are pretty painful, brittle tests to write and we haven’t worked in scenarios where they would really help us. The two main types of UI testing we tend to do are Unit Tests of the View Model and Binding Validation Tests against the Views.

View Model Tests

There are many advantages in taking a View Model approach to building your UI. When we build VMs we try and push as much of the UI state into our models as possible. By doing this we “virtualize” our entire UI, allowing us to simulate a large percentage of the UI behavior without ever opening a Window or showing anything on screen. This is great for testability. It means, we can use simple state based unit tests to verify the behavior of our UI. Here’s a simple example from NHProf:

public class StatementFilterTestFixture
{
    private readonly FilterServiceModel service;
    private readonly IList<IStatementSnapshot> statements;

    public StatementFilterTestFixture()
    {
        statements = new List<IStatementSnapshot>
                         {
                             create_a_statement(100, "hello"),
                             create_a_statement(200, "select * from something"),
                             create_a_statement(300, "select field1 from something"),
                             create_a_statement(400, "select monkey,ninja,pirate,robot from floating_island"),
                             create_a_statement(500, ""),
                         };

        service = new FilterServiceModel();
    }

    [Fact]
    public void Can_filter_by_both_duration_for_values_less_than_300_and_contains_text()
    {
        var filters = new ObservableCollection<IFilter>
                          {
                              new FilterByDuration
                              {
                                  Operator = ExpressionType.LessThan, 
                                Value = "300"
                              },
                              new FilterBySqlContains {Text = "something"}
                          };

        service.Filters = filters;

        Assert.Equal(1, statements.Where(x => service.FilterStatement(x)).Count());
    }
}

Binding Validation Tests

While the WPF/SL data binding mechanism opens the door to building rich View Models, it also introduces a new problem: potential binding expression errors. Because we didn’t want to give up the productivity benefits of databinding and View Models, we chose to take some time to build a binding validation framework. We then write simple tests to insure that there are no typos or silly mistakes in our binding expressions. Here’s an example test from NHProf:

public class StatisticsDetailsTestFixture : ViewTestFixtureBase
{
    private readonly ValidationResult<StatisticsModel> bindings;

    public StatisticsDetailsTestFixture()
    {
        bindings = Validator.For<StatisticDetailsView, StatisticsModel>()
            .Validate();
    }

    [Fact]
    public void BindingsDoNotHaveErrors()
    {
        Assert.False(bindings.HasErrors, bindings.ErrorSummary);
    }

    [Fact]
    public void NameIsBound()
    {
        Assert.True(bindings.WasBoundTo(x => x.DisplayName));
    }

    [Fact]
    public void StatisticsAreBound()
    {
        Assert.True(bindings.WasBoundTo(x => x.SortedStatistics));
    }
}

You can actually take this one step farther as José Romaniello has in testing his Chinook Media Manager. Take a look at this sweet piece of code.

Castle Dynamic Proxy tutorial part XV: Patterns and Antipatterns

Krzysztof Koźmic — Fri, 30 Oct 2009 10:32:00 GMT

We’ve covered almost all of Dynamic Proxy. If you followed along through this series, you now know 95% of Dynamic Proxy 2.1 features that get used 99,9% of the time. Now is the time to wrap up, and with that we’ll review some of the most common pitfalls that you may encounter when developing code on top of Dynamic Proxy.

Leaking this

Consider this simple interface/class pair

public interface IFoo
{
    IFoo Bar();
}
 
public class Foo : IFoo
{
    public IFoo Bar()
    {
        return this;
    }
}

Now, let’s say we create a proxy for IFoo with target and use it like this:

var foo = GetFoo(); // returns proxy
var bar = foo.Bar();
bar.Bar();

Can you see the bug here? The second call is performed not on a proxy but on a target object itself! Our proxy is leaking its target.

This issue obviously does not affect class proxies (since in that case proxy and target are the same object). Why does not Dynamic Proxy handle this scenario on its own? Because there’s no general easy way to handle this. The example I showed is the most trivial one, but proxied object can leak this in a myriad of different ways. It can leak it as a property of returned object, it can leak it as sender argument of raised event, it can assign this to some global variable, it can pass itself to a method on one of its own arguments etc. Dynamic Proxy can’t predict any of these, nor should it.

In some of these cases there is often not much you can do about it, and its good to know that problem like this exist, and understand its consequences. In other cases though, fixing the issue is very simple indeed.

public class LeakingThisInterceptor:IInterceptor
{
    public void Intercept(IInvocation invocation)
    {
        invocation.Proceed();
        if(invocation.ReturnValue == invocation.InvocationTarget)
        {
            invocation.ReturnValue = invocation.Proxy;
        }
    }
}

You add an interceptor (put it as last one in the interceptors pipeline), that switches the leaking target back to proxy instance. It’s as simple as that. Notice that this interceptor is targeted specifically at the scenario from our example above (target leaking via return value). For each case you will need a dedicated interceptor.

Override equality

One of the most common mistakes when it comes to Dynamic Proxy is not overriding Equals/GetHashCode methods on proxy generation hooks and interceptor selectors, which means you’re giving up caching and that in turn coupled with bugs in BCL means performance hit (plus increased memory consumption).

Solution is very simple, and there’s no exceptions to this rule – always override Equals/GetHashCode methods on all your classes implementing either IProxyGenerationHook or IInterceptorSelector.

Make your Proxy Generation Hooks purely functional

Pure function, is a function that for given set of inputs always returns the same output. In case of proxy generation hook, it means that two equal (as specified by overriden Equals/GetHashCode methods) proxy generation hooks will for given type to proxy return the same values from their methods, and when asked again about the same type will again return the same values/throw the same exceptions.

This is a major assumption that Dynamic Proxy makes, and that’s what makes the caching mechanism work. If proxy generation hook is equal to the one already used to generate a proxy type, Dynamic Proxy will assume it would return the same values as the other one, which would result in identical proxy type, so it cuts through the generation process and returns the existing proxy type.

Make your supporting classes serializable

If you’re going to be serializing your proxies, you should make all the classes that go with it serializable. That includes proxy generation hooks, interceptors and interceptor selectors. Otherwise you will get an exception when trying to serialize your proxies. It is not mandatory, but I find it useful. Notice that you will need this also when persisting your proxy assembly to disk.

Use ProxyGenerationHooks and InterceptorSelectors for fine grained control

Do your interceptor’s methods look like this?

public void Intercept(IInvocation invocation)
{
    if(invocation.TargetType!=typeof(Foo))
    {
        invocation.Proceed();
        return;
    }
    if(invocation.Method.Name!="Bar")
    {
        invocation.Proceed();
        return;
    }
    if(invocation.Method.GetParameters().Length!=3)
    {
        invocation.Proceed();
        return;
    }
    DoSomeActualWork(invocation);
}

If they do this often means you’re doing something wrong. Move the decisions to proxy generation hook and interceptor selector

Do I ever want to intercept this method? If the answer is no, use proxy generation hook to filter it out of methods to proxy.

Notice that due to bug in Dynamic Proxy 2.1, if you choose not to proxy method on interface proxy, you will get an exception. Workaround for this is to say you want to intercept the method, and then use interceptor selector to return no interceptors for the method. This bug is fixed in Dynamic Proxy 2.2

If I do want to intercept this method, which interceptors do I want to use? Do I need all of them? Do I need just a single one? Use interceptor selector to control this.

On the other hand, remember that as every feature this one is also a double edged sword. Too liberal use of proxy generation hooks and interceptor selectors may greatly decrease efficiency of proxy type caching, which may hurt your performance. As always think how much control you need and what the implications on caching will be. Sometimes single if on top of your interceptor is lesser evil than increasing number of proxies required tenfold. As always – use the profiler in scenarios that mimic your production scenarios as closely as possible to check which option is the best for you.

SRP applies to interceptors

SRP stands for Single Responsibility Principle, which means that a class should do just one thing. Many people seem to forget about it when it comes to interceptors. They create one monstrous interceptor class that tries to do all the things they need from Dynamic Proxy – logging, security checking, parameter verification, augmenting target objects with behavior and many more.

Remember that Dynamic Proxy lets you have many interceptors per method call. Use this ability to split behavior between interceptors. You may end up with some general purpose interceptors for things like logging that you use for each intercepted method on each class. As long as all it does is logging – that’s ok.

You may end up with some interceptors that are used for methods on just some classes, like classes inheriting from common base class. As long as these interceptors do just one thing – that’s fine.

You may end up with some interceptors that exist solely for the purpose of intercepting just a single method on specific class or interface. That also is fine. Use interceptor selectors to match interceptors to their respective targets, and don’t be afraid to have multiple interceptors per method.

Technorati Tags: Dynamic Proxy,Castle

The HornGet Project: Bringing "apt-get install" to .NET Projects

Billy McCafferty — Fri, 30 Oct 2009 02:34:00 GMT

For years I used nothing but Windows. When I started getting into robotics (for fun - let me know if you'd like me to do it professionally ;), I had to dive into the Linux world. After only a couple of weeks with Ubuntu, I was stunned at how far behind our Microsoft-following community is in some respects. Take Linux's "apt-get install" command, for example. Running this simple command, followed by an application name, finds the referenced application on the "Information Super Highway," downloads the binaries and installs it locally. No biggie, right? Well it also looks to see what dependencies the application has, downloads the latest of all of them, and installs them as well before installing the target application. It does all of that with just one command line (and sometimes even successfully! ;).

There are two scenarios that come to mind where something like "apt-get install" is tremendously useful when developing a project. The first, and most akin to the intent of "apt-get install" is when you're managing an open source project (e.g., S#arp Architecture) and want to provide an easy way for developers to get the latest of the project while concurrently grabbing the latest of its dependencies (e.g., Rhino tools, NHibernate, Fluent NHibernate, MVCConrib) in the process. The second scenario is if you have a project which has a large number of dependencies and dread checking for updates to the project dependencies. Which dependencies do you download? Where do you find the source? Which order should you build them in? How do you know, except through a lot of tedious snooping, which secondary dependencies are also involved in rebuilding the project dependencies?

The HornGet project is attempting (and succeeding I might add, even in its pre-beta form) to greatly ease the burden of updating dependencies of complex projects. With Horn installed and configured, it only takes a single command line to get the latest of your favorite OSS project or to rebuild your project's dependencies. Similarly to "apt-get install," you simply tell Horn what you'd like to have built and it does the rest. There's a full listing of all of Horn's supported packages found at http://code.google.com/p/hornget/wiki/SupportedPackages. As you can see, Horn supports a wide variety of projects such as NHibernate, Castle, LinFu, Ninject, AutoMapper, Subsonice, MVCContib, S#arp Architecture, and many others. Something quite unique about Horn is that it even checks for indirect, bi-directional library dependencies. For instance, NHibernate depends on a Castle project while one of the Castle projects depends on NHibernate. Horn is smart enough (through config files) to know which projects to build in which order to resolve such scenarios.

The best way to experience and appreciate Horn is to try it out. The following steps demonstrate using Horn to automatically download and build the latest of NHibernate with updated dependencies:

Install TortoiseSVN (if you haven't already) to download Horn and to be used during the build process.
Install msysgit as some of the dependencies will be downloaded from from Git distributed source repositories.
Make sure that "C:\Program Files\Git\bin" and "C:\Program Files\Git\cmd" are included in your Environment Variable's PATH (and add them if not)
Install Windows PowerShell (used during the dependency build process - it's included in Win 2008 automatically)
Open a PowerShell command prompt and run "set-ExecutionPolicy RemoteSigned" to allow Horn to invoke PowerShell commands used during the dependency build process.
Use SVN command line or TortoiseSVN to get latest of http://hornget.googlecode.com/svn/trunk/ to a folder we'll call HornRoot
(Here's the only kludgey part, which I'm sure will be cleverly resolved very soon...) Open /HornRoot/src/Horn.Console/Program.cs in Notepad, or whatever, and modify, under GetRootFolderPath(), the line "var ret = new DirectoryInfo(rootFolder);" to be "var ret = new DirectoryInfo(@"C:\...\HornRoot\" + PackageTree.RootPackageTreeName);" and save/close the file - replacing C:\...HornRoot with a real file path. NOTE: Make sure there are NO spaces in the file path that you provide. PowerShell abhors spaces in file paths.
Open a command prompt, cd to the /HornRoot/src folder and run "hornbuild.bat"...you be triumphantly rewarded with a BUILD SUCCEEDED message...but that's just the Horn project.
In the same command prompt, cd to /HornRoot/src/build/net-3.5/debug and run "horn"
- You should see the Horn usage guidelines...that's a good sign.
- At this point, Horn is now installed, ready and configured to build any of the supported packages.
As an example, run "horn -install:nhibernate" (and be patient as it'll take some to run...30 minutes to an hour or more for a project with many dependencies is possible probable)
- After executing this one liner, horn will spit out a whole bunch of "working......" statements as it figures out what NHibernate's dependencies are, downloads the source of the dependencies, builds them, and then downloads and builds NHibernate with all of the updated dependencies.
- Keep waiting...Horn is doing a LOT of tedious work for you right now. Don't be surprised if you see very long strings of "working......" statements at a time, throughout the build process; this is expected as it downloads each project dependency and builds them, accordingly. Go get another cup of coffee or something.
- Assuming the OSS world is in a Zen-like state with each other you'll get a number of BUILD SUCCEEDED messages for each project dependency and then eventually get a BUILD SUCCEEDED message for the target project itself.
- Horn outputs its results (the updated DLLs) into /HornRoot/.horn/result. Don't worry if there are more DLLs that you expected; just grab the updated ones that are applicable to your project and you're good to go.

If you've ever tried to update a bunch of project dependencies, you'll appreciate the enormous time savings in using Horn to pull together the dependencies for you. Doing this manually usually takes me at least a few hours to get latest of all dependencies, build them, and build them with S#arp Architecture. With Horn, it takes a one liner and a coffee break.

How does it do this magic you ask? Good question! Each project that Horn supports has a Boo configuration file; e.g., the S#arp Architecture Horn description is at http://hornget.googlecode.com/svn/trunk/package_tree/frameworks/sharp.architecture/sharp.architecture.boo. The file speaks for itself in describing what dependencies are necessary for the project and where to find the source of S#arp Architecture itself. So when you run "horn -install:sharp.architecture" (which takes a very long while mind you) Horn references the respective project description file and off it goes. It's really quite a remarkable feat that Horn has pulled off.

Horn is still maturing - it's not even beta yet - but it's quite a time saver already. So if you have ideas, would like to get involved, or have a project that you'd like to have added to the roster, be sure to let the Horn team know.

For more Horn:

Project home: http://code.google.com/p/hornget/
Discussion forum: http://groups.google.co.uk/group/horn-development

Enjoy!

Billy McCafferty

Compiling Mapping using Fluent NHibernate

Michael Nichols — Thu, 29 Oct 2009 23:03:01 GMT

This took me some time to find and work out so I am posting this in case I ever need again. I was getting mapping errors so wanted to see what Fluent NH spits out.

public class FluentNHUtil
{
	string schemaExportPath = Path.Combine(AppDomain.CurrentDomain.BaseDirectory, 
		"FluentNHMappings");
	[Observation]
	public void compile_mappings_to_disk()
	{
		if (Directory.Exists(schemaExportPath))
			Directory.Delete(schemaExportPath, true);
		Directory.CreateDirectory(schemaExportPath);
		var model = new ReportingModelPersistenceMappingHandler().CreateModel();
		model.CompileMappings();
		model.WriteMappingsTo(schemaExportPath);		
	}
	
}
public class ReportingModelPersistenceMappingHandler
{
	public MappingConfiguration Handle(MappingConfiguration mappingConfiguration)
	{
		mappingConfiguration.AutoMappings.Add(CreateModel());
		mappingConfiguration.HbmMappings.AddFromAssembly(GetType().Assembly);
		return mappingConfiguration;
	}

	public AutoPersistenceModel CreateModel()
	{
		//the Components convention seems redundant but is dealing with an oddity in FluentNH
		return AutoMap.Assembly(GetType().Assembly)
			.Setup(s =>
					{
						s.IsComponentType = type => type.Namespace.Contains("Components");
					})
			.Conventions.Add(
			new ReportingModelIdConvention(),
			DefaultLazy.Never(),
			new PluralizeTableNameConvention(),
			new HasManyDefaultConvention(),
			new LabNumberComponentConvention()
			).Where(t => t.Namespace.Contains(GetNamespaceConvention()) && t.Namespace.Contains("Components")==false);
	}

	private string GetNamespaceConvention()
	{
		return GetType().Namespace + ".Model";
	}
}

It’s all about the delivery

Hadi Hariri — Thu, 29 Oct 2009 20:32:00 GMT

The Dependency Inversion Principle states:

A. High-level modules should not depend on low-level modules. Both should depend on abstractions.

B. Abstractions should not depend upon details. Details should depend upon abstractions.

(Source WikiPedia).

Throw that at a terrible programmer, and all you’ll get is a terrible programmer that is annoyed and hates you. So true!

Take the following method:

        public void PrintHelloMessage()

            Console.WriteLine("Hello");

Now ask a developer to add a new method to print the message ‘Goodbye’. Do you think he would do:

        public void PrintGoodbyeMessage()
        {
            Console.WriteLine("Goodbye");
        }

or:

        public void PrintMessage(string message)
        {
            Console.WriteLine(message);
        }

Most likely, he’d do the latter. Why? Because he realizes he’s gaining a benefit by passing a parameter to a method. He knows that if tomorrow you ask him for a “Good Afternoon” message, he won’t have to write a new method.

What is Dependency Injection? It’s one way of complying with the Dependency Inversion Principle. However, when you think about it, what does it boil down to? Passing a parameter to a method, which happens to be a constructor. It seems simple enough doesn’t it? Yet, it’s hard for people to understand it. Why? because they don’t see the value in it.

Explaining a principle to someone without them understanding the benefits and values they get out of it is useless, and that is why concepts such as Dependency Injection or Inversion of Control seem overly complex to the vast majority of developers (believe it or not, those of us that use these things are still a very big minority). It’s complex because they haven’t been explained the values of it. They’ve just been thrown some definition and they are expected to understand that it’s bad for one class to create an instance of another class it uses.

Present a developer with the following code:

    public class AuthServices

        public void AuthUser(string username, string password)

            var authDAL = new AuthDAL();

            var user = authDAL.GetUserByUsername(username);

            if (user != null)

                if ...

and ask them how they’d go about testing this code without having access to a database. Ask them how they’d go about changing AuthDAL for some fake DAL that doesn’t really connect to a database.

They’ll probably come up with the solution of passing the AuthDAL class in as a parameter, and eventually realizing that multiple methods will use the same class, they’ll pass it in via the constructor and set it as an instance field. As long as their AuthDAL has virtual methods, they can create any fake DAL that overrides those methods and returns some dummy value. They might argue that they don’t want virtual methods. And that’s fine. Tell them to define the parameter as an interface. In fact, they probably have already heard of a principle that says that you should program to an interface and not a class. They’ll eventually end up with this code:

  public class AuthServices
    {
        IAuthDAL authDAL;

        public AuthServices(IAuthDAL authDAL)
        {
            _authDAL = authDAL;
        }

        public void AuthUser(string username, string password)
        {
            var user = _authDAL.GetUserByUsername(username);

            if (user != null)
            {
                if ...
            }

        }
    }

And voila! You have Dependency Injection via Constructor.

Once they *get* that, then explain to them other benefits, you know the real benefits they get from doing this: decoupled code, easy maintenance, promotion of SRP, etc. and then throw the principle in their face:

A. High-level modules should not depend on low-level modules. Both should depend on abstractions.

B. Abstractions should not depend upon details. Details should depend upon abstractions.

And they’ll see how it all makes sense.

It’s not about throwing or not throwing books. It’s about showing people how something can help them, how they get value of it.

Simple Kick Start Example using MEF (Preview 8)

Derik Whittaker — Tue, 27 Oct 2009 10:34:00 GMT

If your application needs extension points what do you do? Building a plugin based system is not cutting edge, it is not rocket science. However, it does take a little effort and can be a bit painful depending on your implementation. The guys at MS (Glen Block and crew) has been working on this kickin framework for about a year now called the Managed Extensibility Framework (most commonly known as MEF). The core goal of MEF is to simplify the creation of extensible applications. MEF offers discovery and composition capabilities that you can leverage to load application extensions.

There are a metric crap-ton of samples out on the net which show how to get running with MEF, however many of the posts are based off of older previews and most are also incomplete in terms of the code they show you on screen. What I would like to do is provide a detailed how-to on getting your first (simple) MEF application up and running.

Goal of the demo code?
For this demo code we are going to put together a very simple rules plug-in engine. The goal is to be able to add in a new IRule at any point and have your application pick it up.

What is needed?
If you have not already done so head out to http://mef.codeplex.com/ and grab the latest source download. More than likely you will need to download and compile all the source in order to get working binaries (hey, it is a preview after all). Once you have compiled the source you need to grab the output from the ComponentModel project (assembly name is System.ComponentModel.Composition) and include this into your project.

Putting it together?

Creating the rule Interface : IRule
This is needed because in order to define a plug-in you need to define what that plug-in looks like.

public interface IRule
{
    void DoIt();
    string Name { get; }
    string Version { get; }
    string Description { get; }
}

Creating a rule instance (or two)
Now that we have our rule interface we need to create specific instances of the rule and mark them for export. Marking them for Export simply entails adding a attribute provided by the MEF framework and this attribute allows you to describe your plug-in to the MEF framework so it can pick it up.

[Export( typeof( IRule ) )]
internal class RuleInstance1 : IRule
{
    public void DoIt() {}

    public string Name
    {
        get { return "Rule Instance 1"; }
    }

    public string Version
    {
        get { return "1.0.0.0"; }
    }

    public string Description
    {
        get { return "Some Rule Instance"; }
    }
}

[Export( typeof( IRule ) )]
public class RuleInstance2 : IRule
{
    public void DoIt() {}

    public string Name
    {
        get { return "Rule Instance 3"; }
    }

    public string Version
    {
        get { return "1.1.0.0"; }
    }

    public string Description
    {
        get { return "Some Rule Instance"; }
    }
}

Creating the holder for all your plug-ins
In order to have your application know about the plug-ins that MEF has found you need to define a storage location for them. We will do this by creating a property of IList<IRule> which will hold each instance. When we create this storage location we need to tell MEF that we are going to use this as a storage location and to do this you need to mark it with the ImportMany (use this attribute if you want a collection, use Import for only a single instance) attribute. This is another special attribute provided by the MEF framework.

[ImportMany( typeof( IRule ) )]
internal IList<IRule>: _rules { get; set ;}

Creating the logic to load the plugin
Now that we have all the heavy lifting out of the way in terms of defining our Imports and Exports it is time to setup our application to consume the data. It is here where you tell MEF where to look to find your exports (plug-ins) and what to do with them once you have found them.

public void Init()
{
    var catalog = new AggregateCatalog();
    var container = new CompositionContainer( catalog );
    var batch = new CompositionBatch();
    batch.AddPart( this );
    // because all our types are in the same assembly we simply use the current one.    
    catalog.Catalogs.Add( new AssemblyCatalog( Assembly.GetExecutingAssembly() ) );
    container.Compose( batch );
    foreach ( var rule in _rules )
    {
        Debug.WriteLine( rule.Name );
    }
}

Wrapping it up
As you can see getting a simple example of MEF up and running is a pretty simple task (great job MEF team). You should be able to get this up and running in about 10 minutes. You should also have all the code you need in order to get this running. I hope this helps kick-start someone’s learning and adoption of MEF.

Till next time,

Caliburn v1 RTW for WPF, Silverlight 2.0 and 3.0!

Rob Eisenberg — Mon, 26 Oct 2009 17:06:00 GMT

Hooray!!! I finally released Caliburn v1 to RTW and got the official site launched! This has been a long time coming and I could not have done it without the generous help and support of the .NET community, family and friends. Many individuals contributed by finding bugs, submitting patches, recommending features or improvements and providing general support and encouragement. I would like to call out a few special individuals (in no particular order) who contributed significantly:

Michael Davis – For submitting numerous bug fixes and patches.
Ryan Rauh – For creating the fabulous Prism integration module, which I believe makes Prism easier to use with Caliburn than without!
Marco Amendola – For implementing several new features, fixing tons of bugs, submitting patches, writing demos and being an awesome help answering questions on the forums!
Christopher Bennage – For fixing bugs, inventing and inspiring cool features, participating in the forums, believing in my vision and being willing to put this framework to the test on every WPF/SL application our company has built for the last several years.
Anna Eisenberg – It goes without saying that my wife has been very gracious to me. She has supported and believed in me and my work without faltering. I love you!

I would also like to thank the codeplex users MichaelDBang, Bezieur, p_matyjasek and davidpadbury for their patches and participation in the forums. And, as always, if I left someone out, I sincerely apologize. (I’m going to do a better job of tracking this stuff for v2…)

In addition to the release build and the official site, we’ve added a gallery of applications and related projects to our new documentation. In the coming months I am going to be extending this documentation with additional articles in my MVVM series as well as some cool tutorials.

For those of you who have never heard of Caliburn, it is a UI framework designed to aid in the development of WPF and Silverlight applications. Caliburn implements a variety of UI patterns for solving real-world problems. Patterns that are enabled by the framework include MVC, MVP, Presentation Model (MVVM), Commands and Application Controller. Here’s a bullet point list of what Caliburn gives you that you don’t get from WPF/SL out of the box:

Extends databinding to methods, making MVVM architectures simple and intuitive.
Adds pre/post execution filters and rescues to MVVM actions.
Simplifies asynchronous programming through a powerful implementation of Coroutines.
Provides base classes supporting common UI roles such as Screen Activator, Screen Conductor, Screen Collection and Application Controller.
Encourages a convention over configuration approach to architecting solutions.
Supports TDD by providing a powerful databinding validation framework for WPF.
Enables use of the same API for WPF and Silverlight architectures

Here’s a more detailed explanation of its key features:

Actions

Actions extend the databinding capabilities of WPF/SL by enabling a UI to bind not only to data but to methods as well. Caliburn provides a consistent API for wiring events, gestures, and attached events to methods on a presentation-related class. This type of method binding removes much of the glue code involved in building an MVP or Presentation Model (MVVM) architecture. In addition to basic execution of methods, Caliburn's action mechanism can pass data from the UI into the methods as parameters and bind return values back to the UI. A filter mechanism (similar to ASP.NET MVC) exists for decorating methods. Filters can affect the availability of a given action through the UI, which can be represented by automatically disabling, hiding or collapsing controls. Caliburn can also automatically execute methods asynchronously, and execute callbacks. It does all the thread marshalling for you. If that's not enough power, you can take advantage of Caliburn's Coroutine implementation through actions as well.

Commands

Caliburn's command implementation is an alternative to WPF's and supplies very useful functionality that is altogether missing from Silverlight. As you might expect, it is an implementation of the Command Pattern.. Commands are built on top of Actions and thus share many of the same features, including multiple input parameters, filters and automatic asynchronous execution. Additionally, commands can be created in hierarchies, such that a parent command can execute multiple child commands. The parent command's availability can also be affected by its children in various ways. There are two types of composite commands available out of the box, but the mechanism is extensible.

Application Model

Caliburn supports UI architectures based on MVP and MVVM through its various implementations of the IPresenter interface. Often times, these types of architectures involve tricky UI lifecycle issues such as handling activation, deactivation and shutdown semantics for various UI components. The basic logic for handling these scenarios is found in Caliburn’s Presenter, PresenterManager, MultiPresenter, MultiPresenterManager and Navigator classes. By composing these classes you can create a hierarchical model representing the entire runtime state of your application. In Silverlight, you can even use the browser as an Application Controller with Caliburn’s support for deep linking. By using these classes as a starting point, you can very quickly get up in running with an MVP or MVVM architecture.

Conventions

Convention over configuration is a way to leverage a great deal of a framework's power without having to go through tons of tedious configuration or setup code. Caliburn has basic conventions around view discovery, binding of actions and building-up of hierarchical View Models. These are all implemented through well-known services which are easily replaceable or extendable with your own conventions.

Testability

One of the goals of Caliburn is to make it easier to build applications right. To this effect, Caliburn has features geared around unit testing. There is currently rich support for testing databindings in WPF and a simple fluent interface for verifying change notification on model objects. Unit tests for view bindings give the developer the confidence they need to refactor their models, knowing that they will be aware of broken bindings before they run the application. Not only will they be aware that the bindings are broken, but Caliburn’s binding validator will tell you exactly where the problem is in the UI hierarchy and what the specific error was.

Utilities

Various utility classes and extension methods are provided as part of Caliburn. The most popular of which is the Execute static class, which enables a developer to easily execute code on a background thread or on the UI thread.

Caliburn has come a long was since I first started working on it about three years ago and we are not finished yet. I’ve got a host of ideas for v2 and now is a great time to get started. Download the framework. Start using it to build UI’s, give me feedback and help us make it even better in v2!

With Much Gratitude (and hoping this makes your work a little easier),

Rob Eisenberg

NHibernate CurrentSessionContext tip

Michael Nichols — Sun, 25 Oct 2009 04:32:16 GMT

I recently implemented a reporting model in my app (a windows service) and so now have two session factories to manage within a unit of work. Originally, I was using this setting:

<property name="current_session_context_class">thread_static</property>

This was causing the wrong session to get injected into my entities since only one session factory is supported with this setting. So I changed it to this:

<property name="current_session_context_class">call</property>

Now things work as expected. You don’t want to use this on ASP.NET.

Resources

NH docs on Contextual sessions

Virtual Errors From The Crypt

Michael Nichols — Sun, 25 Oct 2009 04:03:38 GMT

Resuming a Win 2K3 session on VMWare 6.5.2 and got an interesting error:

VMware Workstation unrecoverable error: (vmx)
NOT_IMPLEMENTED d:/build/ob/bora-156735/bora/devices/mainmem/mainMemCpt.c:850
A log file is available in "F:\VirtualMachines\VMWare\Windows\Server2003R2\DevBAK\vmware.log". A core file is available in "F:\VirtualMachines\VMWare\Windows\Server2003R2\DevBAK\vmware-vmx-984.dmp". Please request support and include the contents of the log file and core file.
To collect data to submit to VMware support, select Help > About and click "Collect Support Data". You can also run the "vm-support" script in the Workstation folder directly.
We will respond on the basis of your support entitlement.

I started digging around and found some links but none helped resolve my issue. The problem is, my machine was in suspended state. I have a backup but I forgot to git commit before shutting down last night…lame.

So I just deleted the .vmss file in the VM folder that informs the suspended state and the machine boots up fine now.

Can anyone spot what is wrong here?

Derik Whittaker — Fri, 23 Oct 2009 11:40:00 GMT

4 Advil later and my head really hurts. Here is a little story about how a simple little typo can really cause major headaches and pain.

Yesterday I was in the process of setting up one of our new WCF services to use Jimmy Bogard’s solution to use StructureMap to create our services. At one point during my development I had the setup correct because when I would do a ObjectFactory.WhatDoIHave() I could see the output. However, a few minutes later everything was broke. Not knowing what had changed (I had not yet committed anything to svn so I could not do a compare even) I did what most developers do, I tried it again and again just hoping it would magically work. (ok, what I really did was kill the dev web server, restarted IIS, restarted VS, etc). After about 30 minutes of trying to determine what had changed I finally went home for the night, hoping that a new day would magically solve the problems.

Well, when I came in today the problem was still there (looks like my laptop Gremlins took the night off.

Can you spot what is wrong with this code?

ObjectFactory.Configure( 
    scanner =>
        {
            scanner.AddRegistry( new IoCDataStrategyRegistry() );
            scanner.AddRegistry( new IoCLicensingRegistry() );
            
        }
    );

Did you see the error? It is subtle. Ok, give up, take a look at this code

ObjectFactory.Initialize( 
    scanner =>
        {
            scanner.AddRegistry( new IoCDataStrategyRegistry() );
            scanner.AddRegistry( new IoCLicensingRegistry() );
            
        }
    );

Turns out that StructureMap does not puke when you use the DSL syntax in an incorrect manor. What it does do however is simply not wire up correctly, which makes sense.

Anyway, not that my head hurts, but my code is back to normal I guess it is time to move on to the next issue.

Till next time.

Castle Windsor forwarded types and proxies

Krzysztof Koźmic — Thu, 22 Oct 2009 19:41:00 GMT

Castle Windsor allows you to use single component for multiple services, which is called Forwarded Types.

Forwarded Types

In other words, you can tell Windsor – when IFoo is requested use FooBar as implementation, and when Bar is requested also use FooBar (when using default lifestyle of singleton you’ll get the same instance).

Here’s some code:

var container = new WindsorContainer();
container.Register(Component.For<Bar>().Forward<IFoo>()
                       .ImplementedBy<FooBar>());
var foo = container.Resolve<IFoo>();
var bar = container.Resolve<Bar>();
Debug.Assert(foo == bar);
foo.DoFoo();
bar.DoBar();
Console.ReadKey(true);

Proxies

What if you want to use proxies for that component though?

var container = new WindsorContainer();
container.Register(Component.For<IInterceptor>()
                       .Named("interceptor")
                       .ImplementedBy<FooBarInterceptor>(),
                   Component.For<bar>().Forward<ifoo>()
                       .ImplementedBy<FooBar>()
                       .Interceptors(new InterceptorReference("Interceptor")).Anywhere);
var foo = container.Resolve<IFoo>();
var bar = container.Resolve<Bar>();
Debug.Assert(foo == bar);
foo.DoFoo();
bar.DoBar();
Console.ReadKey(true);

Now, what happens next depends on how you implemented the interface IFoo on class FooBar. Say this is FooBar:

public class FooBar : Bar, IFoo
{
    public void DoFoo()
    {
        Console.WriteLine("DoFoo");
    }
 
    public override void DoBar()
    {
        Console.WriteLine("DoBar");
    }
}

Notice that DoFoo is non-virtual. In this case, here’s what we’re gonna get.

DoFoo did not get intercepted. So what’s the issue here, and how do we fix it?

The What

When you forward a registration, Windsor runs just the first type through the complete registration pipeline, and subsequent forwarded types are treated just as additional piece of data “Oh, by the way, use this component I just registered for this type as well". Proxy registration is a part of the component model building, and since we end up having just one component only information about its main type gets recorded for proxying.

While this might appear at first clearly as a bug, I think it’s rather a by-design feature. Forcing Windsor to figure it out by itself could pretty quickly become very tricky and we might not always get what we expected. There are however ways of getting what we want.

The fix no 1

Now that we know what we’re up against, how do we fix it? First and the most trivial fix would be simply to make the DoFoo virtual – this way it would get picked when proxying Bar base class and we could successfully proxy it. While this may not always be applicable (you may not be able to modify the class) this is the only option that is available if you’re using the released version. However if you’re using trunk there are two more possible ways of bending it to our will.

Meet my attributes

Due to some changes in how Dynamic Proxy 2.2 (current trunk) handles additional interfaces to proxy, it is possible to intercept non-virtually implemented interface members on a class proxy. Since Windsor by default will request just the class proxy (with no additional interfaces) we need to tell it to toss an IFoo attribute in as well. The quickest way of doing it is throwing an attribute on top of our class:

[ComponentProxyBehavior(AdditionalInterfaces = new[] { typeof(IFoo) })]
public class FooBar : Bar, IFoo
{
    public void DoFoo()
    {
        Console.WriteLine("DoFoo");
    }
 
    public override void DoBar()
    {
        Console.WriteLine("DoBar");
    }
}

If we run the code now we’ll get this:

This is not a solution most people would choose anyway. Even if you can do it (your service does not come from a 3rd party library), you’re decorating your service class with a Windsor-specific attribute which many consider an anti-pattern. There’s however a third, more pure way.

Remember that you need trunk version of Dynamic Proxy for this to work. If you use version 2.1 you’ll end up with this instead:

Windsor will implement the interface, but it will treat it as interface proxy without target. You can make it work by inserting a dedicated interceptor that will forward the calls to your class, but it’s something you’ll have to do manually all the way through.

Black belt approach

I said that forwarded types don’t get ran through whole registration pipeline. However, kernel does raise its component lifecycle events for them, so we can hook up to them and get notified when our forwarding handler gets registered, and modify its component model.

We start by hooking up to kernels HandlerRegistered event, before we register any components.

var container = new WindsorContainer();
container.Kernel.HandlerRegistered += OnHandlerRegistered;

In the OnHandlerRegistered method we check whether the handler at hand is a ForwardingHandler and if so we add its interface to the list of additional interfaces we want to proxy, just like we did using attribute in the example above.

static void OnHandlerRegistered(Castle.MicroKernel.IHandler handler, ref bool stateChanged)
{
    var forwardingHandler = handler as ForwardingHandler;
 
    if (forwardingHandler == null)
        return; //we're only interested in forwarding handlers...
 
    if(!forwardingHandler.Service.IsInterface)
        return; //we're only interested in interface services...
 
    var targetHandler = forwardingHandler.Target;
    if(!targetHandler.ComponentModel.ExtendedProperties.Contains(ProxyConstants.ProxyOptionsKey))
        return; //apparently this service is not registered for proxying
 
    var options = targetHandler.ComponentModel.ExtendedProperties[ProxyConstants.ProxyOptionsKey] as ProxyOptions;
    Debug.Assert(options != null);
 
    options.AddAdditionalInterfaces(forwardingHandler.Service);
}

Now we get our interface proxied without having to touch our component’ code.

Technorati Tags: Castle Windsor

Lambdas aren’t just for managed code

Scott Seely — Wed, 21 Oct 2009 23:50:29 GMT

A long time ago, I was a C++ developer. I actually thought of myself as a pretty darn good C++ developer and got way too excited when I finally got to meet folks like Scott Meyers and actually landed a job working with Bobby Schmidt—same team on MSDN. (If you know Bobby’s name, well, you were pretty deep into C++ circa 1999.) Then, like many C++ devs, I moved over to a garbage collected language. I’ve done more than my fair share of professional .NET and Java development. C++ has been left by the wayside. Today, I finally downloaded and installed Visual Studio 2010 Beta 2. I dug into the “What’s New” and, out of curiosity, decided to look at C++ first (I already know about many of the C# and VB changes). I saw two cool things:

C++ now has an auto keyword. For you C# devs, it is pretty much the same as the C# var keyword.
C++ has lambdas.

Now, I’m only a little ways into understanding C++ lambdas, so some of my information here may be suspect. The C++ lambda is just an anonymous function. You can pass variables into the function so that the variable is visible within the function. The syntax is:

[ list of variables from current scope to pass into lambda scope ] return-type( function signature ) { code }

The canonical example appears to be std::for_each from <algorithm>.

   #include "stdafx.h"      
#include <iostream>       
#include <algorithm>       
#include <vector>       
using namespace std; 
    int _tmain(int argc, _TCHAR* argv[])      
{       
    vector<int> myints;       
    for (auto i = 0; i < 10; ++i){       
        myints.push_back(i);       
    }       
    auto number = 0;       
    auto numSquared = 0;       
    for_each(myints.begin(), myints.end(), [&number, &numSquared](int n) {  
        cout << n << endl;       
        number += n;       
        numSquared += n * n;       
    });       
    cout << "The sum is " << number << endl;       
    cout << "The sum of the squares is " << numSquared << endl;       
    return 0;       
}

In this example, I have two values: number and numSquared. I make references of the value visible to the lambda, which prints out each value as it comes through and then sums the numbers and their squares. Once the function completes, the code emits the values to the console window. If you don’t want to pass anything to the lambda, you still need to state this. If I didn’t want number or numSquared visible, the lambda signature would be:

   [](int n){}

At some point, I’ll dig in and see what else this is good for, including how to build my own Functor signatures. Anyhow, just thought I’d share this little nugget with you.

IE6 still haunts me

sergiopereira — Wed, 21 Oct 2009 22:16:00 GMT

Oh, the woes of supporting IE6 (or, better put, IE666 — the browser of the beast.)

Halloween is definitely upon us. Today I spent a good chunk of time trying to identify the source of a problem in my application. Right now I'm in the process of jQuery-fying some legacy JavaScript, which includes Ajax calls and error handling logic.

At some point I needed to pop-up a DIV that was supposed to look like a modal message box, reporting some error that happened during the Ajax call. That was not hard at all. I used the SimpleModal plugin and got the message box up in not time at all.

Not so fast, you have IE6 users

As with many web developers out there, I don't have the luxury of ignoring IE6 users because they are upwards of 60% of our user base (corporate users that for some reason can't easily upgrade their browsers.)

I thought it wouldn't be a problem because the SimpleModal plugin handles a number of IE6 issues, including the insertion of an IFrame to overcome the bleedthrough of Select tags. But of course it couldn't be that easy right?

In some of my tests IE6 was simply crashing when I tried to open the "modal" message. After a lot or hair pulling, I saw this suspicious HTML in one of my messages:

<table style="font-size: expression(parentnode.currentstyle.fontsize);" >
    <!-- rest of the table is normal -->
</table>

Sure enough, moving that hack to a proper CSS rule in the external .css file made the error go away. We shouldn't be using dynamic CSS expressions anyway, since they were removed from IE8, so I went ahead and ditched that kind of usage wherever I could find it.

This is just to keep us on our toes regarding IE6 support. Even though the modern JavaScript libraries go to great lengths to support IE6 and make our coding transparent, nothing substitutes good old manual testing to make sure IE6 doesn't play pranks on us in production.

Without Context everything is suspect

Derik Whittaker — Mon, 19 Oct 2009 12:02:52 GMT

Over the weekend I was having a conversation with my wife and we were not communicating on the same wave length. After a few minutes of talking in circles it dawned on us that we had not established the context around the conversation and we had no real understanding of what either of us was saying. This lead to remember a time a few jobs ago when ‘lack of context’ lead people to draw the wrong conclusions about a forth coming client visit.

The background for this little story goes something like this. We had an existing client of ours that had an internal development project underway and they wanted us to come onsite to gain a better understanding of this project as well as to see how our product could integrate/play nice with their project. Prior to meeting with the client (in person or via a phone conversation) we were presented with a power point presentation which laid out the ideas and intent of this project. Now keep in mind that this power point was not created specify for our viewing, but it was very, very relevant in respect to the projects goals and aspirations.

As this was the first interaction (from a product development standpoint, not a sales standpoint) with this given client our team had no background or history to draw from when reviewing the slide deck. As we were reviewing the deck the entire team stopped at the page that was titled ‘Rules of the Game’ and had a few bullet points which said things like ‘Don’t ask dumb questions’ and ‘Don’t make this harder than it has to be’. Immediately upon reviewing this deck we all go the impression that this meeting was going to be rough and that the client was going to be a little bit on the difficult site.

Fast forward a few weeks till when we were able to get onsite with the client and have a conversation with them. During the initial stages of the meeting the client was doing a white board session (which I love when a client does this) about their goals and what they had in mind. During this session the CIO started to go over the ‘Rules of the Game’ with the group. However, this time because we had more context to go on our perception and understanding of the rules changed 100% percent. The context of the conversation was not pointed towards us, the product team. But rather about how he did not want the application to get in the way of the user by 1) asking dumb questions or 2) making their life harder than it needed to be.

About 30 seconds after our client was finished with his whiteboard session the team members all kind of looked at each other and all came to the realization that we had misinterpreted the the message based solely on the fact there was not context in the power point deck. This realization was great, because now we fully understood the client as well as their intent. It also made us feel a little better because we had gone into the meeting expecting there to be a bit of hostility and in fact the exact opposite was the case.

The moral of the story is this. Context is a powerful part of any message. If you do not clearly communicate the context in a clear and concise manor you are leaving your messages up for interpretation and this can lead to bad things. The same holds true not only for emails, but also for your code.

Till next time,

IncaBlocks Released, Thanks AgileZen and Kanban!

Michael C. Neel — Wed, 14 Oct 2009 15:21:00 GMT

FuncWorks, LLC’s first XNA game, IncaBlocks, is now available on Xbox Live Indie Games (XBLIG)!

This game represents the many hours and weekends Dylan, Cicelie and myself worked the past several months. Looking back at SVN, I started this as a side project to ROCS around July 30th. Shortly thereafter we decided to put ROCS on hold and make IncaBlocks the first game we would release. Keeping with our belief in over delivering, we priced IncaBlocks at 80 Points ($1.00).

Game play is pretty simple – stack blocks following some rules, and the one with the most blocks on top at the end wins. I recorded a short video of a game to help everyone check it out (there is also a free trial version on Xbox):

IncaBlocks was also the first project that we made heavy use of Kanban and AgileZen. Kanban is an idea I’ve loved in theory for a while, but hadn’t had the chance to use it on a real project (meaning a project with a deadline). We used both the online board at AgileZen, and a real board in my office. Nate and Nicole have done an awesome job with AgileZen, and in my not-so-humble opinion have a better project management system than Basecamp. As with Ninject, Nate has a knack for stripping away the excess and leaving only the good parts.

That said, you cannot beat the feeling of a physical Kanban board. Moving a work item physically through the project flow gives one a great sense of accomplishment. We stuck to two basic rules of the board: first, you can only have one task in progress at a time, and second, you must take a task, once started, all the way to done. I think at least 3 times I “reset” the board and moved tasks around in the ready columns to change priority. This allowed us to keep a high velocity while reacting to change (considering this was our first XNA game to be release, we had many changes as a result of just learning XNA and XBLIG worked). While we pruned the done items from AgileZen, we left them all up on the wall:

We already have ideas for our next games, though I will have to take a break from game development while I work on an ebook for Wrox. The working title is “XNA 3D Primer”, and will be a crash course in 3D game programming. I also plan to do some post mortem posts on IncaBlocks and the lessons we learned along the way.