Devlicio.us - Just the Tasty Bits

Ruby Is Scary

Jak Charlton — Sat, 31 Jul 2010 01:55:00 GMT

Why is Ruby on Rails all the rage at the moment, and why do a lot of .NET people seem so defensive?

Undoubtedly, there is a buzz in development right now, things are changing rapidly, possibly more rapidly than they have for a good number of years. New languages are sprouting up all over it seems, with PHP and Python gaining massive popularity, F#, Erlang and Haskell suddenly being talked about as mainstream, Javascript evolving beyond that thing that makes "onClick" work in your browser, and Ruby (and especially Rails) becoming "flavour of the month" for web development. Ruby is even starting to invade the .NET mainstream space with evolutions like Rake, Cuke4Nuke and Nu muddying the divide that there once was. We even have IronRuby to make Ruby run on .NET

And yet, many .NET people seem defensive, as though their safe world was being invaded by a parasite.

I find this quite odd. As a developer who has been around for far too long, I have seen more than my fair share of languages and platforms come and go, none of them was perfect, and I would venture to say none of the ones we have now are either.

It would appear that a large proportion of the uncertainty is in the C# development 'community', though that may be as I don't really frequent circles that use VB.NET (and I'm fairly sure they are still busy being defensive about C# and probably haven't noticed that's *so* last year :) Somehow the introduction of new ideas is rocking the C# type safe world.

Some people seem to be concerned about Ruby itself, some seem to have concerns about the lack of a statically typed safety net, and some seem to think that "the Enterprise" needs something more professional than toys like Ruby and Rails.

To The Static Typing Stalwarts

Yes, it's nice to have that compile time checking that static typing gives you, it gives us all a warm sense of fuzziness knowing that the compiler told us that this code would run just fine when we dropped it onto our web server.

Yes, we appreciate the great benefits that this has for things like Intellisense and for easily discoverable APIs, and even for automated documentation.

And yet, none of these things seem to bother the Ruby (and PHP/Python/Javascript) crowd too much. Why is that?

I would suggest that the static typing benefits a language like C# brings are illusory to a large degree.

The compiler isn't telling us that this code will run correctly at all, it's actually just telling us that the CLR won't throw our code out before the application even starts up - but correctness is so much more important than that. The safety net static typing provides us with is just one part of the equation, and possibly the least important part - we really should be enforcing correctness upon our code.

Correctness is verified by good automated testing, and static typed languages start to come back and bite us here - we trade that compile time security blanket for a much harder experience testing our code. Sure, tools like NUnit, xUnit, Rhino Mocks, Moq, SpecFlow, StorEvil et al ease away our pain, but still our application code is littered with constructs that are pretty much there to support SOLID (or SOLID is required due to the constraints of type safe OO languages), and they become most obvious when we start testing in languages like C# (I am *so* over Interfaces, IoC, Covariance, Contravariance and Generics !

The testing experience in Ruby is a world apart from in C# and .NET, it is just easy and simple ... so simple in fact that it is almost harder to not write automated tests in Ruby - and that's how it should be. In C# testing is often convoluted, complex, fragile and just plain hard work - I can't think of the last time a C# developer described automated testing as fun ... and yet, in Ruby, it just seems like FUN!

And yes, Ruby without automated testing leaves you open to all kinds of runtime errors that C# just wouldn't - so in Ruby, you just make sure you test, and not only test your code will run, but also test it will run *correctly* - there is no safety net, but the trade off is you are ensuring correctness of code, not just compilation of it.

Intellisense, sure it's nice, but as RubyMine and even Visual Studio (under Javascript) demonstrate, you can do some form of Intellisense in dynamic languages, you just can't always be certain what may or may not be available - but this is getting better. And honestly, is discovering which method you are meant to call though typing "." all that great an idea anyway? Shouldn't you as a competent developer know *in advance* what you wanted to call, rather than guessing it as you type?

To The Enterprise

Sure, Ruby doesn't have the track record that C# has, nor does it have the exposure, or market reach, or backing of a company like Microsoft.

But, is that what is really important?

I would bet that a large part of the appeal for statically typed languages in the "Enterprise" is actually a need to deal with a much lower skilled developer base overall. Compile time safety means that your developers don't have to be top notch, the compiler can make up for their weaknesses (and in the case of C# and .NET, Visual Studio 'drag and drop' tooling is trying to make up for a lot of the rest)

Enterprises tend to see dollars and cents, not people and value. So anything that lets them hire cheaper developers to churn out more product must be good.

Again, I would argue this is a false economy. Sure that team of 30 developers may give you a warmer fuzzier feeling inside than a team of 4. And sure, the quantity of code those 30 can type out will probably be much more.

But this misses some real issues around productivity and value - a 'good' developer is 10x as productive as an 'average' developer, and more importantly, the 'average' developer will never be able to create the same quality level as the 'good' developer, even given a near infinite amount of time. No matter how much time a hobbyist painter spends with oil and canvas, he will never create a Leonardo. And as a Jackson Pollock will amply demonstrate, sometimes less is more.

So are you measuring bodies or productivity? Surely it is the end result that matters, not the comfort factor of people looking busy.

And, when you get a good developer, and let them have the freedom of a dynamic language, they can spend less time fighting compile time safety and language constructs that exist almost solely for that type safety, and more time concentrating on business logic and the end product.

In fact, the best argument for why Ruby is not suited to the Enterprise is ... the Enterprise probably already has a large investment in one platform and one core language (or maybe two), and the cost of retraining all those developers, support staff, renegotiating supplier contracts, etc etc is just disproportionately expensive. Lethargy is rife in the Enterprise, and monoliths take a long time to move - sure it's easier for startups to hop on new technologies and run with them, and often it's why they quickly challenge the status quo. This isn't really a technical issue, this is a political and management one.

Maybe Ruby and Rails will gain traction here, maybe not. Things like functional programming are certainly starting to grow roots in financial services, and things like Javascript are prevalent in web apps in the Enterprise so maybe dynamic programming in things like Ruby isn't so far off. It just takes one small faction to show how well they solved a particular problem with a new language or platform to plant that thought.

So Should We All Switch To Ruby Now?

Of course not, and maybe this is what the defensive people in .NET miss. The Ruby people aren't saying "you guys have it all wrong, convert now", they are just saying "hey, I found a really cool way of solving this problem".

Ruby is about choice, it's another tool in your arsenal. As are Javascript, PHP, Python, Erlang, F#, Java, Groovy, C++ and a host of others.

There is no "one right path", so let's all stop pretending there is.

We don't need to be defensive about any one language or platform, unless we are so unsure of our abilities as developers that we cannot learn and adapt - and if that is the case, maybe a new career is a better idea?

As my recent presentation at DDDSydney said ... My Objective Today was to make you think ... "Maybe There Is A Better Way" - because it would just be depressing to think we are already doing things the best possible way.

Open Source Whining

Tim Barcz — Wed, 28 Jul 2010 14:04:28 GMT

Was working on a blog post talking about a problem I’ve found in Git (1.7.0.2) and I thought I would check to see if it’s been fixed in the most recent version. After downloading and installing I reviewed the release notes where I’m quite shocked to read the following:

“…All hopes to the contrary, Git for Windows is backed by only a handful of developers, in spite of being downloaded almost one hundred thousand times. You can expect developers to be enthusiastic to fix others' issues in such a situation only for so long. In short: Do not expect other people to fix your issues for you.”

Basically, what I get from this is that the msysgit committers are a bunch of whiners. What they fail to see is that the people who would benefit from their VCS may not have the same skillset to work on the code. This is something we’ve realized long ago with Rhino Mocks.

Should more people help? Possibly. As someone active in open source technology I don’t know that I can be of much assistance to the Git team – I am someone who benefits greatly from their software (I am quite thankful for it) but don’t have the requisite knowledge in C/C++ to assist in any meaningful fashion.

Just a bit disappointed to see this type of whining in their release notes – certainly there are far better ways to say what they’re trying to say. Doesn’t represent msysgit or the broader open source community well.

Best Error Dialog ever w/ Visual Studio

Derik Whittaker — Wed, 28 Jul 2010 12:25:00 GMT

Today I received the following error and thought it summed up my day perfectly.

Now the real question is what was I doing to receive this error…… I was trying to copy a single line (w/ 50 characters of text) to the clipboard…DOH

Till next time,

CodeBetter/Devlicio.us/LosTechies MSDN Ultimate Giveaways

Tuna Toksoz — Tue, 27 Jul 2010 11:46:00 GMT

UPDATE: I have added subscription donors/contributors who made this possible.
UPDATE: Our friends from LosTechies also wanted to participate, and they donated a number of licenses (6 and counting). Thank you guys!

In an internal discussion we had, an interesting idea popped up. MVP bloggers we had at CodeBetter/Devlicio.us were generous enough to donate some of their MSDN subscriptions they were given as part of MVP program. Then the cool kids at LosTechies stepped in, and donated a number of licenses as well! Currently we have 13-16 licenses available, and this number may change depending on the demand and outside donations. The subscriptions are for one year.

We decided to give them away to successful/promising OSS projects that are in need of licenses. The rules are simple.

The project has to be opensource
The project has to be in need of MSDN license. We’ll trust your word in this.
The selection will be based on our discretion, we’ll do our best on being fair.
We may change the number of licenses available during the selection progress.

You can send me an email (tehlike (hat) gmail (hot) com) with title starting with [CDL/MSDN] (or [CD/MSDN]), or DM me on twitter (@tehlike) if you want to participate. You have to include

Public URL for the project page
Your name and your position in the project

It wouldn’t have been possible with the help of following fellow bloggers. Thanks to Codebetter Crew: Ben Hall, Ward Bell, James Kovacs. Devlicious Crew: Hadi Hariri, Christopher Bennage, Tim Barcz, Rob Reynolds. Lostechies Crew: Eric Hexter, Jimmy Bogard, Keith Dahlby

Good luck!

How to detect the theme being used in WP7

Derik Whittaker — Tue, 27 Jul 2010 10:07:19 GMT

As the Windows Phone 7 have either a dark (black) or light (white) theme which can be applied it will become very important for you to know which theme the user enabled in order to determine your applications color schema, this is assuming you are using styles which are not built into the skinning on WP7.

Sadly detecting the current theme is a bit hackish as it requires you to take a look at a current loaded resource to determine the theme. I would have hoped that this would be part of the built in SDK as I see this as a common need for many applications.

Here is how you determine which theme is being used.

Color themeColor = (Color)Application.Current.Resources["PhoneForegroundColor"];
        
if (themeColor.ToString() == "#FFFFFFFF")
{
    this.PageTitle.Text = "Dark ";       
}
else if (themeColor.ToString() == "#DE000000")
{
    this.PageTitle.Text = "Light ";    
}

As you can see the code to determine the theme is easy, but not clean in my opinion.

Till next time,

YouTrack for OSS Projects

Hadi Hariri — Mon, 26 Jul 2010 19:18:00 GMT

Quite some time ago, several OSS leads asked us about whether JetBrains could provide OSS license for YouTRACK. We’ve taken it one step further, and in collaboration with the great folks at CodeBetter and Devlicio.us, we are pleased to announce YouTRACK at CodeBetter. Having TeamCity running most of the OSS projects on there, it only made sense to offer the same facilities for issue tracking at the same location. And seeing that YouTRACK integrates with TeamCity, we can offer all the functionality the combination is capable of.

I’d like to thank Kyle Baley, James Kovacs and Bredan Tompkins for making this possible, as without their support this wouldn’t happen. Not only are they generous in hosting YouTRACK, but also ran the risk of providing me with the credentials to the server, and at one point it looked like it had all gone to hell. Luckily however all seems to be working great now.

What are the next steps?

If you are an OSS project lead and would like to use YouTRACK for your issue tracking, please email teamcity@codebetter.com with your details and you’ll be up and running in no time. If you want to learn more about YouTRACK, please visit our web site.

The Future of .NET Open Source Software Delivery

Rob Reynolds — Mon, 26 Jul 2010 18:57:00 GMT

Imagine we are awhile into the future. How do you get open source releases down to your project so that you can use them? How do you get the products down to your computer so that you can use them? Is it easier or harder than the way we’ve always done it before?

The Past and Present

Before we can go there, let’s look at what we do now (the past is really the same for us here). Let’s say I want to use NHibernate. What do I do? There are basically three paths we all follow in this process.

1. Never had product x before. If I don’t have a current version, I have to go out and look for it. So what do I do?

Open a browser
Find the site
Find the downloads
Find the particular download I want through the plethora of options that may be presented to me
Download it
Unzip it
Then put it into my project references folder somewhere so I can keep it in source control with my project

2. Use the current version without upgrade. If I have a current version, I may just copy it over and use it in my new project. Nevermind that it is two versions ago. I don’t want to take the time to upgrade because it could be a pain.

Open file explorer and find the project with the old version
Open file explorer and find the new project
Create the structure I need for the references folder
Copy the contents of the old project to the new project

3. Upgrade. If I find a bug or I decide it’s time to upgrade to a newer version, how do I get it? Repeat the process of #1 (Never had product x before) and getting the latest version.

Problems with the Present Method of Delivery

It's slow. How long did it take me to get all of that? Yeah, now multiply times every library I want to use.

Too many decisions. I have to make way to many decisions to get the right product and right version downloaded and referenced into my project.

Dependencies may be hard to manage. I may be using projects that depend on the same libraries. In the example above I am using Castle in my project. That got upgraded as well when I got the latest version of NHibernate. Now I may have to test the changes to that. What if the latest version of Castle Windsor I am using is not compatible with the latest version of NHibernate? I won’t see that issue necessarily until I try to run my code. I can try binding redirects, but there is no guarantee that that will work. So now I have a problem. I have to figure out what version of Castle Windsor to use so that I can use the latest version of NHibernate. And this is where dependency management is fully placed on me as a developer. I can now decide to move forward or just continue to use the old version.

Too easy to just continue using the same version you have. It's way too easy to keep using the version you first downloaded and never learning about all of the awesomeness that comes with more current versions of the product.

Unfortunately for a lot of people, what I just mentioned with projects that have dependencies on the same things as other projects is the biggest barrier to using OSS (Open Source Software). So let’s talk about the future.

The Future

So now that we have looked at how we currently do it, how will it be in the future?

Open source developers will publish their latest releases to a central repository (possibly in addition to other methods of offering releases). Then everyone can get their latest releases and develop from there.

Same three scenarios.

1. Never had product x before. Here’s the process.

Know what I’m looking for and confirm the name at the central repository
open a command line
type something to the effect of nu install nhibernate

And I’m done. It’s all brought to me and sitting in my references folder of my project.

2. Use the current version without upgrade. This is still an option. Same as in the present described above.

3. Upgrade. Here’s the process.

open a command line
type something to the effect of gem update
type something to the effect of nu install nhibernate

What Issues Does the Future Method of Delivery Address?

Speed. The process is amazingly streamlined. We are talking seconds as compared to minutes of time to get something. I can now concentrate on what I want to do instead of spending all the time I was on just getting the packages I needed.

The decision tree is reduced. How many decisions did I have to make to get what I needed in the present scenario? How about the future scenario? Greatly reduced. Less choices to get what I want actually gets me to a decision faster.

I immediately see the dependency changes. All of the dependencies that are required come along nicely with NHibernate. I can immediately see that it downgraded my versions of Castle Core and Dynamic Proxy2. So now I know immediately that I have a problem between Castle Windsor and NHibernate using different versions. It doesn’t solve my problems on this, but it brings it to the surface. So now I can try something like the aforementioned binding redirects.

The process of upgrade became easier than use the current. Another thing you may have noticed. It actually becomes easier to upgrade to the latest version as compared to #2 (Use the current version). That will move people to upgrade, because people will choose the easiest path to get them on their way. And when everyone using the latest version, everyone wins.

The Future Is Now

Oh yeah, the future? It’s now. http://groups.google.com/group/nu-net

Before you comment about “cluttering” the ruby community, please be sure to read this (we’re with you on this): http://devlicio.us/blogs/rob_reynolds/archive/2010/07/19/gems-for-net-community-response.aspx

Gems - Package Management for .NET

How To – Gems & .NET & How To – Gems & .NET - Dependencies (References)

Walkthrough - Create Gems Even Easier With a Conventional Build (UppercuT)!

Dynamically Changing Resources in a ListBox using Binding and Converters

Derik Whittaker — Sat, 24 Jul 2010 18:51:00 GMT

While working on an application targeted towards WP7 I wanted to have the application change style resource which was attached to a border element based on a value (aka a status) in my view model. After searching around for a bit I was not able to come up w/ a complete end to end solution, only bits and pieces. In order to help the next poor newbie I thought I would post my solution (btw, there may be a MUCH better solution than this out there).

In this sample I simply created a test application based off of the Item List Template which comes out of the box with a few minor changes.

Setting up the XAML

The important item to pay attention to above is the highlighted line. This is the line which will change the border brush via the converter based on the value in the ‘Color’ property in my view model.

Changes to the View model

The code above is the property I added which will allow us to trigger the border brush to determine what style to use

Creating the Converter

The above is a pretty standard converter which uses the IValueConverter interface. The Part in here it pay attention to is how I am grabbing the brush resources out of the App.xaml file (there may be a better way to do this, but i could not find this). What this code does is basically determines which loaded resource to return based on the value passed into the converter

Registering the Converter

Once you create your converter class (see above) you do need to register it in your app.xaml class. Do do this simply follow the logic above.

Creating the Brush Resources

The code above will create the various resources needed to allow us to change the color of our item in XAML

Populating the ‘live data’

The default template for the Item List project has all the data hard wired in the MainViewModel class. I simply added the above logic to populate the color properties.

After you put all the above together you get….

Notice how the little colors next to each item change, this is our doing :) Now of course this is a simple example, but it does go to prove how you can accomplish this.

Till next time,

Semi final release – Windsor 2.5 beta 2 (now with Silverlight support)

Krzysztof Koźmic — Wed, 21 Jul 2010 00:21:42 GMT

A bit later than expected (ah, work) I published beta 2 of Windsor 2.5 today. The release has the following changes as compared to beta 1.

Silverlight version (for Silverlight 3 and Silverlight 4) is now included in the package.
Synchronize Facility is now included in the package (.NET only)
The following code changes and fixes were made (incl. one breaking change)
- added support for selecting components based on custom attributes and their properties. See Component.HasAttribute<T>() methods

- added WithService.DefaultInterface() to fluent API. It matches Foo to IFoo, SuperFooExtended to IFoo and IFooExtended etc. If you know how DefaultConvention works in StructureMap, this is pretty similar

- added support for CastleComponentAttribute in fluent API. Also added helper filter method Component.IsCastleComponent

- added ability to specify interceptors selector as a service, not just as instance

- added ability to specify proxy hook in fluent API

- indexers on IKernel are now obsolete.

- added WithAppConfig() method to logging facility to point to logging configuration in AppDomain's config file (web.config or app.config)

- BREAKING CHANGE: Restructured lifecycle concerns - introduced ICommissionConcern and IDecommissionConcern and favors them over old enum driven style.

- Fixed how contextual arguments are handled. Null is no longer considered a valid value (That would cause an exception later on, now it's ignored).

- Changed method DeferredStart on StartableFacility. It now does not take a bool parameter. A DeferredTryStart() method was introduced instead.

This is probably the last pre-release for 2.5 and if no critical issues are found, we’ll release final release in 2, 3 weeks. Go grab the bits, see if it works for you and if it does not report back. I’m also looking for people who want to contribute sample applications for the final release. Ping me if you’d like to contribute to that.

Writing plug-ins for ReSharper: Part 2 of N

Hadi Hariri — Tue, 20 Jul 2010 21:02:00 GMT

[Finally I’ve managed to get the second part of the post on plug-ins. Sorry for the delay to everyone who was waiting. Appreciate your patience. And now I’ll resume my holidays!]

In the previous part of this series, we saw the basics of how to create a plug-in for ReSharper, install it and run it. We created a context action that would allow us to mark a public method as virtual (where applicable). However, this was done as an explicit action by the user, as such, you didn’t get any kind of hint or suggestion to do this. What we want to do now is make this a hint, so that highlighting appears under methods that could be made virtual. In this part we are going to expand on the same plug-in and convert it into a QuickFix.

What is a QuickFix?

Have you seen the little squiggly lines that appear in Visual Studio?

They usually indicate a Suggestion (field can be made read-only), Warning (possible null reference) or Error. ReSharper analyzes and can detect potential issues in the code (similar to what static checker of Code Contracts does). These are known as Highlights and they are related to QuickFixes in that usually a highlight has an QuickFix associated to it, which invokes a context action. This is usually done by placing the cursor on top of the highlighting and press Alt+Enter

Highlighting Daemons

In the gutter of the Visual Studio editor (right-side), ReSharper displays a series of warnings, errors and hints, which indicate potential issues on a specific file. These issues are detected by background processes known as Daemons. Since what we are looking for is for ReSharper to warn us of existing methods that could be made virtual, what we need to do is somehow hook into these daemons.

Step by Step Guide

The Daemons in ReSharper use the Visitor pattern to use act on elements, be it code, files, etc. The first step is to implement an IDaemonStage interface, which hold metadata about our daemon stage at at the same time acts as a factory for the actual process we are implementing.

[DaemonStage(StagesBefore = new[]  { typeof(LanguageSpecificDaemonStage) })]
public class MakeMethodVirtualDaemonStage: IDaemonStage
{
     public IDaemonStageProcess CreateProcess(IDaemonProcess process, DaemonProcessKind processKind)
     {
         return new MakeMethodVirtualDaemonStageProcess(process);
     }

     public ErrorStripeRequest NeedsErrorStripe(IProjectFile projectFile)
     {
         return ErrorStripeRequest.STRIPE_AND_ERRORS;
     }
}

There are two main methods to implement. The CreateProcess is what creates the actual process for us and the NeedsErrorStrip which indicates whether this daemon uses the gutter to display strips. The DaemonProcessKind parameter passed into the first method helps us discriminate on when this process should be executed, i.e. only during checking of visible (current) document, during solution wide analysis, etc.

The next step is to implement the process via the IDaemonStageProcess interface:

  public class MakeMethodVirtualDaemonStageProcess : IDaemonStageProcess
  {
      readonly IDaemonProcess _process;

      public MakeMethodVirtualDaemonStageProcess(IDaemonProcess process)
      {
          _process = process;

      }

      public void Execute(Action<DaemonStageResult> commiter)
      {
          if (_process.InterruptFlag)
          {
              return;
          }

          var file = _process.ProjectFile.GetPsiFile(CSharpLanguageService.CSHARP) as ICSharpFile;

          if (file != null)
          {
              var highlights = new List<HighlightingInfo>();

              var processor = new RecursiveElementProcessor<IMethodDeclaration>(declaration =>
              {

                  var accessRights = declaration.GetAccessRights();

                  if (accessRights == AccessRights.PUBLIC && !declaration.IsStatic && !declaration.IsVirtual &&
                      !declaration.IsOverride)
                  {
                      var docRange = declaration.GetNameDocumentRange();

                      highlights.Add(new HighlightingInfo(docRange, new MakeMethodVirtualSuggestion(declaration)));
                  }
              });

              file.ProcessDescendants(processor);

              commiter(new DaemonStageResult(highlights));
          }

      }


  }

The main meat of this class is in the Execute method. We first check to make sure that we’ve not received an interruption (Interrupt Flag raised) due to some external action. Next step is to get access to the current file (remember that we are visiting the entire visible document, not just a specific method). Having the file, we can now create a RecusiveElementProcessor* to perform a tree walk of the AST and perform the specific action on each element. The action to perform is declared as the lambda expression. Since we’re interested in the method declaration, the type is IMethodDeclaration (there are many others). If we look at the expression, we can see that it’s pretty much the same as that of Part 1, the only difference is that we add the results to the highlighting variable.

The HighlightingInfo class has a parameter which can be a Suggestion, Warning or Error, as explained previously. Since in our case we need a suggestion, we pass in the MakeMethodVirtualSuggestion:

[StaticSeverityHighlighting(Severity.SUGGESTION)]
public class MakeMethodVirtualSuggestion : CSharpHighlightingBase, IHighlighting
{
     public ICSharpTypeMemberDeclaration Declaration { get; private set; }

     public MakeMethodVirtualSuggestion(ICSharpTypeMemberDeclaration memberDeclaration)
     {
         Declaration = memberDeclaration;
     }

     public string ToolTip
     {
         get { return "Method could be marked as virtual"; }
     }

     public string ErrorStripeToolTip
     {
         get { return ToolTip; }

     }

     public override bool IsValid()
     {
         return Declaration.IsValid();
     }

     public int NavigationOffsetPatch
     {
         get { return 0; }
     }
}

This class is pretty simple. The main property to define is the ToolTip, which is the text that will show when we hover of the highlighting. The ErrorStripeToolTip is what’s displayed in the right-hand side gutter. Finally the Attribute StaticSeverityHighlighting is to indicate what type of tip it is (Warning, Error, etc.).

[*Note: In this case, the operation we want to perform is very simple. If we want a more complex scenario where we need to do some processing before and after each element is visited or have a more fine-grained control, we can implement the IRecurisveElementProcessor. I’ll cover this in another post].

To recap, right now we would have everything place to display highlighting when a method that could be made virtual is encountered. The only remaining part is to now be able to apply a QuickFix. This is in many ways similar to the ContextAction we saw in Part 1:

[QuickFix]
public class MakeMethodVirtualQuickFix : BulbItemImpl, IQuickFix
{
    readonly MakeMethodVirtualSuggestion _highlighter;

    // Takes as parameter the Highlighter the quickfix refers to
    public MakeMethodVirtualQuickFix(MakeMethodVirtualSuggestion highlighter)
    {
        _highlighter = highlighter;
    }

    // In the transaction we make the necessary changes to the code
    protected override Action<ITextControl> ExecuteTransaction(ISolution solution, IProgressIndicator progress)
    {
        _highlighter.Declaration.SetVirtual(true);

        return null;
    }

    // Text that appears in the context menu
    public override string Text
    {
        get { return "Make Method Virtual"; }
    }

    // Indicates when the option is available
    public bool IsAvailable(IUserDataHolder cache)
    {
        return _highlighter.IsValid();
    }
}

The MakeMethodVirtualQuickFix needs to implement the IBulbItem and IQuickFix interfaces. For ease of implementation we can inherit from BulbItemImpl. The constructor should take as parameter always the actual highlighting that has given way to invoking the QuickFix, in our case the MakeMethodVirtualSuggestion. Similar to the ContextAction we implemented in Part 1, the actual fix itself is pretty trivial. All we need to do is make the method virtual. How do we get access to the method? The easiest way is via the Declaration property of the highlighting passed in (this is a property we added before). The only thing left is to call the SetVirtual method on it. Since we are in the ExecuteTransaction method, ReSharper makes sure that any change made is executed as a whole.

The rest of the properties are trivial. Text returns the text of the QuickFix (what appears in the menu), and IsAvailable indicates when the QuickFix is available, which in our case is whenever the highlighting is valid.

The End Result

Once we compile the plug-in and place it in the corresponding Plugins folder under ReSharper\Bin, we’re done. Here’s the end result:

and invoking Alt+Enter on the highlighting gives us:

Summary

Extending ReSharper to create highlightings and quick fixes is pretty simple once you understand how all the pieces fall into place. Most of the code will usually be the same and what will vary will be the actual element processing to be performed and the corresponding QuickFix. As mentioned previously (in the Note), for complex scenarios, we can have more control over the tree walk and that’s something we’ll examine in a future post.

I’ve placed the code up on my github account so feel free to download it, play with it and ping me if you have any comments or questions. The code is updated to work with ReSharper 5.1

How To – UppercuT and Gems

Rob Reynolds — Tue, 20 Jul 2010 14:00:00 GMT

In a previous post I mentioned how I was going to show you how UppercuT (UC) has the ability to make gems stupid simple to create and publish. You ask if gems can get any easier and to that I answer, “Why YES, they can!” How about just filling out the information for the gemspec, running a build and having a nice, shiny new gem ready for publishing?

Rock The Gems

Basically you want to get the latest release of UppercuT. You can download it or grab the source and compile.

There are already instructions out there for how to get UC in your project, so I’m not going to concentrate on that.

Once you upgrade (or add and get everything else set up), you want to have this gems folder at your top level (just under trunk or branch name).

In that gems folder you are going to find a file named something like the file below. Rename that file to your new gemname.gemspec.

Note: Once you have a gemspec file in a gems folder, your build server NOW needs to also have ruby and gems installed.

Open that file in your favorite text editor and fill in the details. Here’s a good post on how to do that.

Then just for having the gems folder with a gemspec in it, UC will automatically try to build the gem for you (the code in your code_drop/projectname folder is brought over to code_drop/gems/lib folder).

Removing All of the Other Output After the Gem is Built

Once we are good with what we are getting back for the gem, we can start cleaning up. So we go into our build.custom (don’t have one? create it right next to the build folder) folder and create a file named gemsBuild.post.step.

Let’s open the file and insert this:

<?xml version="1.0" encoding="utf-8"?>
<project name="CUSTOM POST GEMSBUILD" default="go">
  <!-- Project UppercuT - http://projectuppercut.org -->
  <property name="build.config.settings" value="__NONE__" overwrite="false" />
  <include buildfile="${build.config.settings}" if="${file::exists(build.config.settings)}" />
  <property name="dirs.current" value="${directory::get-parent-directory(project::get-buildfile-path())}" />
  <property name="path.to.toplevel" value=".." />
  <property name="folder.code_drop" value="code_drop" overwrite="false" />
  <property name="dirs.drop" value="${dirs.current}\${path.to.toplevel}\${folder.code_drop}" overwrite="false" />
  <property name="folder.gems" value="gems" overwrite="false" />
  
  <target name="go" depends="run_tasks" />
  
  <target name="run_tasks">
    <delete>
      <fileset basedir="${dirs.drop}/${folder.gems}" >
        <exclude name="*.gem" />
        <include name="**/*" />
      </fileset>
    </delete>
  </target>
  
</project>

Note: Don’t like NAnt? You can also use Ruby or PowerShell instead of NAnt to write your custom extensions.

Now when we run our build again, we have a nice clean folder.

What If I Want to Change What Goes Into my Gem?

Interested in influencing what goes INTO your gem in the first place? That’s a pretty good thing to be concerned with so that you don’t have all of your referenced assemblies sitting in there. Read about how to set up dependencies. Then you will create a file next to gemsbuild.post.step named gemsPrepare.post.step.

In that file, you will insert something similar to the following (roundhouse file):

<copy todir="${dirs.drop}\${folder.gems}\lib">
  <fileset basedir="${dirs.drop}\${folder.gems}\lib\MSBuild">
    <include name="**/*.*" />
  </fileset>
</copy>

<copy todir="${dirs.drop}\${folder.gems}\lib">
  <fileset basedir="${dirs.drop}\${folder.gems}\lib\NAnt">
    <include name="**/*.*" />
  </fileset>
</copy>

<delete>
  <fileset basedir="${dirs.drop}\${folder.gems}\lib" >
    <include name="ConsoleApp/**" />
    <include name="MSBuild/**" />
    <include name="NAnt/**" />
  </fileset>
</delete>

Learn More

With this knowledge, you shall build. Interested in more UppercuT? Check out the ChuckNorris framework and join the group.

Gems - Package Management for .NET

How To – Gems & .NET & How To – Gems & .NET - Dependencies (References)

The Future is Now!

Gems For .NET – Community Response

Rob Reynolds — Mon, 19 Jul 2010 18:28:03 GMT

There has been a lot of response in the community about this gems idea we’ve been talking about. I even had the opportunity to sit down with Nick Quaranto, the guy behind Rubygems.org, over coffee Sunday and talk about where we think we are going and what it will take to get there.

One of the biggest things that everyone wants to see carrying this idea forward is that we migrate off of Rubygems.org and have our own gem server. And we all agree this is a great idea. There are just two things that really keep that from happening at the current moment. The devil is in the details and when we are ready to move off to our own server, it’s real money at that point (to do it right).

Right now we are embracing the idea of “one community,” and we are certainly not the first non-ruby community to use RubyGems.org. Long term a different host for the .net gems will be both necessary and beneficial. As we move off, we’ll be able to even expand some of the things we can do as far as checking gems as they are published to make sure they meet certain constraints.

If you are concerned about getting started versus later migrating – the process will be well thought out and seamless for the user experience of getting your gems and pushing them. The user experience is still going to be rock solid, and the same concept of gem install gemname is going to be there no matter what happens.

And for you gem owners – we’ll be working closely with Nick to ensure that the process is still rockstar.

The more community involvement there is from you and others like you, the faster we move to our own servers. And as far as when, well that all depends on you.

My Objective Today is to Make You Think

Jak Charlton — Mon, 19 Jul 2010 00:08:00 GMT

"Maybe There is a Better Way"

I recently presented at DeveloperDeveloperDeveloper in Sydney, and although my talk was Stuff About CQRS, I opened with the slide

My Object Today Is to Make You Think ... 'Maybe There is a Better Way'

(slides here)

The real focus of this was around how normal people think, and how unlike normal people we developers really are. My role in development is all about enabling better communication, because fundamentally I believe the real value a developer brings to a project is not technical, but is in the way they interact with the team, and more importantly with the normal people they are actually creating software for.

Obviously some of this has roots in DDD, the Ubiquitous Language is obviously an attempt to traverse this chasm that seems to exist between us.

Then I touched on user interfaces, and how they are so rarely designed the way people think - normal people think about their objectives and goals, not in terms of data like we developers do. Inductive UIs are focused on tasks, unlike the traditional data driven UIs that we tend to throw at users - users and people don't think in grids and columns and rows, they think "I want to change my address", not "open my customer record, edit the three fields under address and save to the database" - only a sadist or a developer would think that way.

And finally I touched on things like NoSQL databases, which neatly solve a communication problem - they stop us thinking about How to store information and let us focus on What we are storing and Why.

And lastly I tried to show the link between CQRS and these business problems - how it made you focus on the language, on tasks and objectives and how it let you detach the How from the What and Why.

But most importantly, what I was trying to do in that presentation was to throw some non-mainstream ideas out into the audience, to spark discussion and debate, and to get people to think - Maybe There is a Better Way

If only a few of those in the audience went away and Googled some of the ideas I was talking about, it will be another step towards moving development away from it's heavy focus on technology and technological solutions - and towards a people and business driven focus, where technology is an artifact, not the deciding factor.

Caliburn.Micro Soup to Nuts Pt. 3 – All About Actions

Rob Eisenberg — Sat, 17 Jul 2010 16:04:00 GMT

We briefly introduced actions in Pt. 1, but there is so much more to know. To begin our investigation, we’ll take our simple “Hello” example and see what it looks like when we explicitly create the actions rather than use conventions. Here’s the Xaml:

<UserControl x:Class="Caliburn.Micro.Hello.ShellView"
             xmlns="http://schemas.microsoft.com/winfx/2006/xaml/presentation"
             xmlns:x="http://schemas.microsoft.com/winfx/2006/xaml"
             xmlns:i="clr-namespace:System.Windows.Interactivity;assembly=System.Windows.Interactivity"
             xmlns:cal="http://www.caliburnproject.org">
    <StackPanel>
        <TextBox x:Name="Name" />
        <Button Content="Click Me">
            <i:Interaction.Triggers>
                <i:EventTrigger EventName="Click">
                    <cal:ActionMessage MethodName="SayHello" />
                </i:EventTrigger>
            </i:Interaction.Triggers>
        </Button>
    </StackPanel>
</UserControl>

As you can see, the Actions feature leverages System.Windows.Interactivity for it’s trigger mechanism. This means that you can use anything that inherits from System.Windows.Interactivity.TriggerBase to trigger the sending of an ActionMessage.* Perhaps the most common trigger is an EventTrigger, but you can create almost any kind of trigger imaginable or leverage some common triggers already created by the community. ActionMessage is, of coarse, the Caliburn.Micro-specific part of this markup. It indicates that when the trigger occurs, we should send a message of “SayHello.” So, why do I use the language “send a message” instead of “execute a method” when describing this functionality? That’s the interesting and powerful part. ActionMessage bubbles through the Visual Tree searching for a target instance that can handle it. If a target is found, but does not have a “SayHello” method, the framework will continue to bubble until it finds one, throwing an exception if no “handler” is found.** This bubbling nature of ActionMessage comes in handy in a number of interesting scenarios, Master/Details being a key use case. Another important feature to note is Action guards. When a handler is found for the “SayHello” message, it will check to see if that class also has either a property or a method named “CanSayHello.” If you have a guard property and your class implements INotifyPropertyChanged, then the framework will observe changes in that property and re-evaluate the guard accordingly. We’ll discuss method guards in further detail below.

Now you’re probably wondering how to specify the target of an ActionMessage. Looking at the markup above, there’s no visible indication of what that target will be. So, where does that come from? Since we used a Model-First approach, when Caliburn.Micro (hereafter CM) created the view and bound it to the ViewModel using the ViewModelBinder, it set this up for us. Anything that goes through the ViewModelBinder will have its action target set automatically. But, you can set it yourself as well, using the attached property Action.Target. Setting this property positions an ActionMessage “handler” in the Visual Tree attached to the node on with you declare the property. It also sets the DataContext to the same value, since you often want these two things to be the same. However, you can vary the Action.Target from the DataContext if you like. Simply use the Action.TargetWithoutContext attached property instead. One nice thing about Action.Target is that you can set it to a System.String and CM will use that string to resolve an instance from the IoC container using the provided value as its key. This gives you a nice way of doing View-First MVVM if you so desire. If you want Action.Target set and you want Action/Binding Conventions applied as well, you can use the Bind.Model attached property in the same way.

Let’s see how we would apply this to achieve MVVM using a View-First technique (gasp!) Here’s how we would change our bootstrapper:

public class MefBootstrapper : Bootstrapper
{
    //same as before

    protected override void DisplayRootView()
    {
        Application.Current.RootVisual = new ShellView();
    }

    //same as before
}

Because we are using View-First, we’ve inherited from the non-generic Bootstrapper. The MEF configuration is the same as seen previously, so I have left that out for brevity’s sake. The only other thing that is changed is how the view gets created. In this scenario, we simply override DisplayRootView, instantiate the view ourselves and set it as the RootVisual (or call Show in the case of WPF). Next, we’ll slightly alter how we are exporting our ShellViewModel, by adding an explicitly named contract:

[Export("Shell", typeof(IShell))]
public class ShellViewModel : PropertyChangedBase, IShell
{
    //same as before
}

Finally, we will alter our view to pull in the VM and perform all bindings:

<UserControl x:Class="Caliburn.Micro.ViewFirst.ShellView"
             xmlns="http://schemas.microsoft.com/winfx/2006/xaml/presentation"
             xmlns:x="http://schemas.microsoft.com/winfx/2006/xaml"
             xmlns:cal="http://www.caliburnproject.org"
             cal:Bind.Model="Shell">
    <StackPanel>
        <TextBox x:Name="Name" />
        <Button x:Name="SayHello"
                Content="Click Me" />
    </StackPanel>
</UserControl>

Notice the use of the Bind.Model attached property. This resolves our VM by key from the IoC container, sets the Action.Target and DataContext and applies all conventions. I thought it would be nice to show how View-First development is fully supported with CM, but mainly I want to make clear the various ways that you can set targets for actions and the implications of using each technique. Here’s a summary of the available attached properties:

Action.Target – Sets both the Action.Target property and the DataContext property to the specified instance. String values are used to resolve an instance from the IoC container.
Action.TargetWithoutContext – Sets only the Action.Target property to the specified instance. String values are used to resolve an instance from the IoC container.
Bind.Model – View-First - Set’s the Action.Target and DataContext properties to the specified instance. Applies conventions to the view. String values are used to resolve an instance from the IoC container.
View.Model – ViewModel-First – Locates the view for the specified VM instance and injects it at the content site. Sets the VM to the Action.Target and the DataContext. Applies conventions to the view.

Now, let’s take a look at another interesting aspect of ActionMessage: Parameters. To see this in action, let’s switch back to our original ViewModel-First bootstrapper, etc. and begin by changing our ShellViewModel to look like this:

using System.ComponentModel.Composition;
using System.Windows;

[Export(typeof(IShell))]
public class ShellViewModel : IShell
{
    public bool CanSayHello(string name)
    {
        return !string.IsNullOrWhiteSpace(name);
    }

    public void SayHello(string name)
    {
        MessageBox.Show(string.Format("Hello {0}!", name));
    }
}

There are a few things to note here. First, we are now working with a completely POCO class; no INPC goop here. Second, we have added an input parameter to our SayHello method. Finally, we changed our CanSayHello property into a method with the same inputs as the action, but with a bool return type. Now, let’s have a look at the Xaml:

<UserControl x:Class="Caliburn.Micro.HelloParameters.ShellView"
             xmlns="http://schemas.microsoft.com/winfx/2006/xaml/presentation"
             xmlns:x="http://schemas.microsoft.com/winfx/2006/xaml"
             xmlns:i="clr-namespace:System.Windows.Interactivity;assembly=System.Windows.Interactivity"
             xmlns:cal="http://www.caliburnproject.org">
    <StackPanel>
        <TextBox x:Name="Name" />
        <Button Content="Click Me">
            <i:Interaction.Triggers>
                <i:EventTrigger EventName="Click">
                    <cal:ActionMessage MethodName="SayHello">
                        <cal:Parameter Value="{Binding ElementName=Name, Path=Text}" />
                    </cal:ActionMessage>
                </i:EventTrigger>
            </i:Interaction.Triggers>
        </Button>
    </StackPanel>
</UserControl>

Our markup now has one modification: We declared the parameter as part of the ActionMessage using an ElementName Binding. You can have any number of parameters you desire. Value is a DependencyProperty, so all the standard binding capabilities apply to parameters. Did I mention you can do all this in Blend?

One thing that is nice about this is that every time the value of a parameter changes, we’ll call the guard method associated with the action(CanSayHello in this case) and use its result to update the UI that the ActionMessage is attached to. Go ahead and run the application. You’ll see that it behaves the same as in previous examples.

In addition to literal values and Binding Expressions, there are a number of helpful “special” values that you can use with parameters. These allow you a convenient way to access common contextual information:

$eventArgs – Passes the Trigger’s EventArgs or input parameter to your Action. Note: This will be null for guard methods since the trigger hasn’t actually occurred.
$dataContext – Passes the DataContext of the element that the ActionMessage is attached to. This is very useful in Master/Detail scenarios where the ActionMessage may bubble to a parent VM but needs to carry with it the child instance to be acted upon.
$source – The actual FrameworkElement that triggered the ActionMessage to be sent.

You must start the variable with a “$” but the name is treated in a case-insensitive way by CM.

Word to the Wise

Parameters are a convenience feature. They are very powerful and can help you out of some tricky spots, but they can be easily abused. Personally, I only use parameters in the simplest scenarios. One place where they have worked nicely for me is in login forms. Another scenario, as mentioned previously is Master/Detail operations.

Now, do you want to see something truly wicked? Change your Xaml back to this:

<UserControl x:Class="Caliburn.Micro.HelloParameters.ShellView"
             xmlns="http://schemas.microsoft.com/winfx/2006/xaml/presentation"
             xmlns:x="http://schemas.microsoft.com/winfx/2006/xaml">
    <StackPanel>
        <TextBox x:Name="Name" />
        <Button x:Name="SayHello" 
                Content="Click Me" />
    </StackPanel>
</UserControl>

Running the application will confirm for you that CM’s conventions even understand ActionMessage parameters. We’ll discuss conventions a lot more in the future, but you should be happy to know that these conventions are case-insensitive and can even detect the before-mentioned “special” values.

Now, lets look at a simple Master/Detail scenario that demonstrates ActionMessage bubbling, but let’s do it with a shorthand syntax that is designed to be more developer friendly. We’ll start by adding a simple new class named Model:

using System;

public class Model
{
    public Guid Id { get; set; }
}

And then we’ll change our ShellViewModel to this:

using System;
using System.ComponentModel.Composition;

[Export(typeof(IShell))]
public class ShellViewModel : IShell
{
    public BindableCollection<Model> Items { get; private set; }

    public ShellViewModel()
    {
        Items = new BindableCollection<Model>{
            new Model { Id = Guid.NewGuid() },
            new Model { Id = Guid.NewGuid() },
            new Model { Id = Guid.NewGuid() },
            new Model { Id = Guid.NewGuid() }
        };
    }

    public void Add()
    {
        Items.Add(new Model { Id = Guid.NewGuid() });
    }

    public void Remove(Model child)
    {
        Items.Remove(child);
    }
}

Now our shell has a collection of Model instances along with the ability to add or remove from the collection. Notice that the Remove method takes a single parameter of type Model. Now, let’s update the ShellView:

<UserControl x:Class="Caliburn.Micro.BubblingAction.ShellView"
             xmlns="http://schemas.microsoft.com/winfx/2006/xaml/presentation"
             xmlns:x="http://schemas.microsoft.com/winfx/2006/xaml"
             xmlns:cal="http://www.caliburnproject.org">
    <StackPanel>
        <ItemsControl x:Name="Items">
            <ItemsControl.ItemTemplate>
                <DataTemplate>
                    <StackPanel Orientation="Horizontal">
                        <Button Content="Remove"
                                cal:Message.Attach="Remove($dataContext)" />
                        <TextBlock Text="{Binding Id}" />
                    </StackPanel>
                </DataTemplate>
            </ItemsControl.ItemTemplate>
        </ItemsControl>
        <Button Content="Add"
                cal:Message.Attach="Add" />
    </StackPanel>
</UserControl>

The first thing to notice is that we are using a more Xaml-developer-friendly mechanism for declaring our ActionMessages. The Message.Attach property is backed by a simple parser which takes its textual input and transforms it into the full Interaction.Trigger/ActionMessage that you’ve seen previously. If you work primarily in the Xaml editor and not in the designer, you’re going to like Message.Attach. Notice that neither Message.Attach declarations specify which event should send the message. If you leave off the event, the parser will use the ConventionManager to determine the default event to use for the trigger. In the case of Button, it’s Click. You can always be explicit of coarse. Here’s what the full syntax for our Remove message would look like if we were declaring everything:

<Button Content="Remove"
        cal:Message.Attach="[Event Click] = [Action Remove($dataContext)]" />

Suppose we were to re-write our parameterized SayHello action with the Message.Attach syntax. It would look like this:

<Button Content="Click Me"
        cal:Message.Attach="[Event Click] = [Action SayHello(Name.Text)]" />

But we could also leverage some smart defaults of the parser and do it like this:

<Button Content="Click Me"
        cal:Message.Attach="SayHello(Name)" />

You can specify literals as parameters as well and even declare multiple actions by separating them with a semicolon:

<Button Content="Let's Talk"
        cal:Message.Attach="[Event MouseEnter] = [Action Talk('Hello', Name.Text)];
                            [Event MouseLeave] = [Action Talk('Goodbye', Name.Text)]" />

WARNING: Those developers who ask me to expand this functionality into a full-blown expression parser will be taken out back and…dealt with. Message.Attach is not about cramming code into Xaml. It’s purpose is to provide a streamlined syntax for declaring when/what messages to send to the ViewModel. Please don’t abuse this.

If you haven’t already, run the application. Any doubts you had will hopefully be put to rest when you see that the message bubbling works as advertised :) Something else I would like to point out is that CM automatically performs type-conversion on parameters. So, for example, you can pump TextBox.Text into a System.Double parameter without any fear of a casting issue.

So, we’ve discussed using Interaction.Triggers with ActionMessage, including the use of Parameters with literals, element bindings*** and special values. We’ve discussed the various ways to set the action target depending on your needs/architectural style: Action.Target, Action.TargetWithoutContext, Bind.Model or View.Model. We also saw an example of the bubbling nature of ActionMessage and demoed it using the streamlined Message.Attach syntax. All along the way we’ve looked at various examples of conventions in action too. Now, there’s one final killer feature of ActionMessage we haven’t discussed yet…Coroutines. But, that will have to wait until next time.

*Currently, the full version of Caliburn is not based on System.Windows.Interactivity. Caliburn’s trigger mechanism was around long before Blend’s. You may notice a shocking similarity in the markup. That said, Caliburn v2.0 will be migrated to use the Blend model in the near future.

**Actually, if no handler is found, before an exception is thrown, the framework will check the current DataContext to see if it has the requested method. This seamed like a reasonable fallback behavior.

***One important detail about ElementName Bindings that I didn’t mention…It doesn’t work with WP7 currently. Due to the fact that WP7 is based on a version of Silverlight 3 which had an incomplete implementation of DependencyObject/DependencyProperty, the infrastructure is not present to make this work in any sort of sane way. However, parameter literals and special values still work as described along with all the rest of the ActionMessage features.

How To – Gems And .NET – Dependencies (References)

Rob Reynolds — Sat, 17 Jul 2010 13:04:00 GMT

In my last post I didn’t mention dependencies. Dependencies are their own animal. They require a couple more things to be in place. Let’s talk about those things.

In the .NET world, the dependency for compiled bits is usually an exact version of a reference.

Let me explain. So for example, you have a reference to log4net, and you don’t ILMerge it into your assembly. You now have a dependency that the DLL needs to be there and a particular version (outside of redirecting the bindings). So what I’m getting at is that you require an exact version of a particular DLL. And what you really need is an exact name, version, culture, and public key token of a DLL. But let’s keep things simple. It’s really the version and the name when culture is neutral (and the key shouldn’t change in the same version). So just the name and version.

Adding a Reference as a Dependency

For each reference you have to a library, you find out what version it is (assembly version) and then add that as a dependency. You can do that by cracking open reflector and taking a look at the actual assembly version.

Don’t use the properties. Neither file version or product version are going to be accurate here:

There is nothing out there that says that assembly, file and informational (also known as product) versions have to be the same. .NET relies on the assembly version for referencing. It makes sense that we should as well. Here’s a better example where things are different:

So what would I put in my gemspec? If your reference was to log4net version 1.2.10.0, then you need to assign a dependency to that exact version. Done like so:

spec.add_dependency('log4net','= 1.2.10.0')

I believe you add each referenced dependency to it’s own line.

Gem Exists?

Now to the sanity check. Before you even add it as a dependency, you want to ensure that the gem exists.

Go to http://rubygems.org and in the top right there is a search box. Search for your reference there.

So let’s search for log4net to be sure it’s there.

Sweet! I can move on to my next reference because the right version of the gem exists.

Keep in mind that the name of the gem may not be the one you are looking for and/or the name may be slightly different. For example. I have a gem for UppercuT. The gem is named uppercutbuild because there was already a gem named uppercut.

Gem Doesn’t Exist?

Now if it’s not there, you can add it. When the actual authors want to start managing the gem, you can just add them as owners so they can push their own gems.

To check the owners of a gem you type:

gem owner gemname

To add someone, according to the gem docs, you issue this command (all on one line):

gem owner gemname --add users.confirmed.email.address.for.ruby.gems@wherever.com

And that’s it.

You see how I am listed as the owner of the log4net gems? I am not really the developer, when I created the gem, I tied it as closely as I could to the apache project and the committers. When those guys are ready to own the gem, I have the specs for both 1.2.9 and 1.2.10 (both are commonly referred to without the last version octet) and I can just add them as owners.

Gems - Package Management for .NET & How To – Gems & .NET

Walkthrough - Create Gems Even Easier With a Conventional Build (UppercuT)!

The Future is Now!

How To - Gems And .NET

Rob Reynolds — Fri, 16 Jul 2010 15:30:00 GMT

In my last post I showed gems being used for .NET. Now let’s talk about How. Most of this stuff I’ve learned over the past two days, so if I have a mistake here or you have a better idea, please don’t hesitate to offer a better solution.

The GemSpec

The Gem::Specification reference is your friend.

In order to create a gem, you need to define a gem specification, commonly
called a “gemspec”.

A gemspec consists of several attributes. Some of these are required;
most of them are optional.

From here you learn what is required and what will just get you there.

Setup

1. Create a folder named gems in your top level source directory.

2. In that folder we are going to put our gemspec and version files. This is where we will store the files in source control (and one of them may become autogenerated).

3. We will bring our gems folder to our compiled source folder after we build. Then we can add in the compiled output.

GemSpec for .NET

1. Create a file named project.gemspec. In our example it is roundhouse.gemspec. This is the most important file for this entire process.

2. Open the gemspec in your favorite notepad editor. Copy the below in and change it for you needs.

version = File.read(File.expand_path("../VERSION",__FILE__)).strip

Gem::Specification.new do |spec|
  spec.platform    = Gem::Platform::RUBY
  spec.name        = 'roundhouse'
  spec.version     = version
  spec.files = Dir['lib/**/*']

  spec.summary     = 'RoundhousE - Professional Database Change and Versioning Management'
  spec.description = 'RoundhousE is a Professional Database Change and Versioning Management tool'
  
  spec.authors           = ['Rob "FerventCoder" Reynolds','Pascal Mestdach','Jochen Jonckheere','Dru Sellers']
  spec.email             = 'chucknorrisframework@googlegroups.com'
  spec.homepage          = 'http://projectroundhouse.org'
  spec.rubyforge_project = 'roundhouse'
end

3. Just about everything with tick marks above you will edit to suit your needs. spec.name and spec.rubyforge_project (and the gemspec file name) should all match and not be an already existing project name on RubyForge.

4. If you are a singular author, instead of spec.authors, replace it with

spec.author = 'somebody'

You can also set up description for multiple lines.

spec.description = <<-EOF
   Rake is a Make-like program implemented in Ruby. Tasks and
   dependencies are specified in standard Ruby syntax.
 EOF

Dependencies On Other Libraries

What we call references. You have a dependency on them existing for your library to run. See this post.

VERSION file

This file is stupid simple. It’s a version number. I believe you can put whatever you want in here. Use the Assembly Version number here and stick with the .NET 4 octets of numbers (like 0.0.0.0) for version.

1. Create a file named VERSION.

2. Open it in your favorite editor and put the version you want here.

Libraries

1. Create a folder called lib.

2. Copy YOUR compiled DLLs into here. Your references (or dependencies) should not go here. See How To: Gems and .NET - Dependencies.

Documentation

Create a docs folder. In that folder goes your documentation. This could be release notes, a ReadMe, actual documentation. This area is open. Just make sure you add the docs folder to the specification.

spec.files = Dir['lib/**/*'] + Dir['docs/**/*']

Executables

If you want to give someone the ability to run an executable from the command line after installing your application with gems, and you use .NET, this is how you do it.

1. Create a folder named bin as a subdirectory next to the gemspec.

2. Put your executable (and dependencies) into the bin directory.

3. Create your shim file (it’s named what you would type at the command line). I’ve called mine rh. The one above allows ruby to be able to actually execute the Windows executable. Let’s open it and see what it looks like. This, we learned from an answer to a post on stack overflow. This shim also goes in source control

result = system(File.dirname(__FILE__) + "/rh.exe " + ARGV.join(' '))
exit 1 unless result

4. Don’t forget that space at the end of your executable name.

5. Open your gemspec. We need to make sure we have spec.executables filled out and our new directory added to our Files.

version = File.read(File.expand_path("../VERSION",__FILE__)).strip

Gem::Specification.new do |spec|
  spec.platform    = Gem::Platform::RUBY
  spec.name        = 'roundhouse'
  spec.version     = version
  spec.files = Dir['lib/**/*'] + Dir['docs/**/*'] + Dir['bin/**/*']
  spec.bindir = 'bin'
  spec.executables << 'rh'

  spec.summary     = 'RoundhousE - Professional Database Change and Versioning Management'
  spec.description = 'RoundhousE is a Professional Database Change and Versioning Management tool'
  
  spec.authors           = ['Rob "FerventCoder" Reynolds','Pascal Mestdach','Jochen Jonckheere','Dru Sellers']
  spec.email             = 'chucknorrisframework@googlegroups.com'
  spec.homepage          = 'http://projectroundhouse.org'
  spec.rubyforge_project = 'roundhouse'
end

Build And Push

You must already have Ruby (1.8.6 or better) and RubyGems installed and/or updated to at least 1.3.7 (gem update –system). You will want to use a RubyInstaller version of Ruby under the Ruby on Windows section.

1. Open a command line and type

gem build project

2. If there are no issues, you should have a gem for upload.

3. Create an account with RubyGems.org.

4. Ensure your project name isn’t already taken by searching for it. If it is you will need to rename your gemspec file, spec.name, and spec.rubyforge_project to a name that is not taken.

5. Type the following command:

gem push project_someversionnumbers.gem

6. Let it finish. Head out to rubygems.org and look at your shiny, new gem!

7. Test it.

gem install project

gem uninstall project

FollowUp

In my next post, I’ll show you how to make it stupid simple. UppercuT will support this feature natively so all you have to do is have a directory called gems (at the top level of your source) with the gemspec. During the build, it will create the VERSION file and copy your output the the lib folder (custom step for bin folder will be necessary). Then it will execute a step that builds the gem. All for the price of “build”. That’s coming up in the next blog post. In the meantime, feel free to ask any questions you have. Stay tuned…

Gems - Package Management for .NET & How To – Gems & .NET - Dependencies (References)

Walkthrough - Create Gems Even Easier With a Conventional Build (UppercuT)!

The Future is Now!

Gems - Package Management For .NET

Rob Reynolds — Fri, 16 Jul 2010 04:27:00 GMT

The Ruby community has enjoyed a great user experience with a package management system they use called Gems. A gem is a package (or a library), compressed with some additional metadata, and can be either source files or binaries. Let’s focus on binary gems. We have the same concept in .NET (DLLs/EXEs). You may have references to other DLLs. When you want to update a reference you are using on a project, you may also need to update its dependencies as well. And so on and so forth. A package management project is meant to help make that easier. It’s actually really hard to explain what gems or package management without just showing you. So take a look here:

I type:

gem install sidepop

And that’s it. It looks and sees that I have a dependency on log4net. Notice how it nicely just pulls down log4net version 1.2.10 as well?

Background

I can count on one hand all of the package management projects that have been started for .NET. Dru Sellers, Chris Patterson, and I have talked about package management stuff from time to time. Dru and Chris have been a part of one project (Nu) that has been started several times to start to answer this question. We’ve participated on the mailing list for HornGet. At one point I casually asked why we couldn’t just use gems. Other people out there have probably stated the same thing. But no one has really carried the idea forward. Until now.

Yesterday Dru asked for a gem-ify feature for UppercuT. We started talking and looking at how easy it is to create a gem. Then we figured out how to make the executables piece work as well. This is where you can install a gem and then call the executable from the command line anywhere and get output. From the thread on ChuckNorris where we talked about this:

Here is something you might find pretty interesting: http://rubygems.org/gems/roundhouse

If you have ruby installed, you can install roundhouse now from the command line:

gem install roundhouse

This gives you the opportunity to type this anywhere:

rh <options>

Why Should I Care?

If you work with Open Source, you know how much of a pain it can be to update your references. You update one library, say NHibernate, and find out that you also need to update your references to Castle. And possibly, you might then need to update your references to log4net. It can be a painful process. This is the start of answering that question.

Why Should I Get Excited?

It sounds like Jeremy Miller among others are getting excited about this. And why not? We’ve been trying to answer the gems question since Ruby made it so easy.

The implications of this are awesome! I still haven’t fully grokked what we’ve just opened up. But it’s huge!

It doesn’t get us all of the way there to updating the references in our source code folder. That’s where projects, like Nu, are going to start showing up that leverage the idea of using the gems infrastructure to get the libraries from the ruby folders to your source code folder. You are going to see UppercuT come back soon with taking care of getting your gem built with the proper version.

This is the start of something very cool.

How To - Gems and .NET and How To – Gems & .NET - Dependencies (References)

Walkthrough – Create Gems Even Easier With a Conventional Build (UppercuT)!

The Future is Now!

Announcing SharpRobotica.com ...the softer side of robotics

Billy McCafferty — Tue, 13 Jul 2010 03:47:00 GMT

After confidentaly turning over the reigns of S#arp Architecture to the adept and au fait hands of Alec Whittington, I capriciously announced that I'd be turning my writing attentions towards robotics...with the diabolical intentions of taking over the world (obviously).

It became apparent after a few posts that the direction I began taking was diverging far from the subject matter of my esteemed colleagues at devlicio.us. Rather than dilute the theme of devlicio.us, I figured it was time to create the proper context for such topics...

It's my great pleasure to announce the humble beginnings of SharpRobotica.com. This blogging community (with an author population of uno at the moment, being yours truly) emphasizes and explores the software side of robotics. While there are many robotic sites, the focus of SharpRobotica.com, accordingly, is in bringing professional software techniques and insight to this vernal, yet burgeoning, industry.

For years, hardware lagged far behind software in the world of robotics; developers were tirelessly constrained by the performance and capabilities of the available hardware platforms. But with the hardware of robotics becoming startlingly sophisticated, there is now incredible opportunity and demand for solid algorithms and software solutions for balancing the scale once again, by creating software which can adeptly take advantage of available robotics hardware to conquer ever challenging contexts such as underwater, space, entertainment, hazardous environments, and in the home.

So if you have an interest in robotics and/or interested in applying your software skills to a completely new context, many of the posts and discussions might be right up your alley. Also, if you're interested in being an author on SharpRobotica.com, sign up as a user and let me know you're interested!

So while I'll still be showing up now and again on devlicio.us...I invite you to also subscribe for a gander to SharpRobotica.com.

Enjoy!
Billy McCafferty

P.S. Thanks Mr. Tompkins (audacious founder of CodeBetter.com and devlicio.us) for the support of this announcement!

Updated Bits for WP7 – Beta Build

Derik Whittaker — Mon, 12 Jul 2010 20:56:00 GMT

Today MS announced an updated release of the WP7 tools. I can tell you from using intermediate builds this is getting better and better.

Check out the build here - http://www.microsoft.com/downloads/details.aspx?FamilyID=c8496c2a-54d9-4b11-9491-a1bfaf32f2e3&displaylang=en

Have fun with the new Bits.

Oh, and great job WP7 Team.

Till next time,

'ServiceReferences.ClientConfig' in the .xap application package Error in WP7

Derik Whittaker — Mon, 12 Jul 2010 13:53:26 GMT

If you are trying to create a WP7 (or any silverlight project for that matter) and you are trying to access a WCF web service you may receive the following error when you try to create an instance of the WCF service.

Cannot find 'ServiceReferences.ClientConfig' in the .xap application package. This file is used to configure client proxies for web services, and allows the application to locate the services it needs. Either include this file in the application package, or modify your code to use a client proxy constructor that specifies the service address and binding explicitly. Please see inner exception for details.

In my project I saw this because my WCF service references were NOT in the UI project, they were in a common/domain project. Because of this the ServiceReferences.ClientConfig file was not being put in to the .xap package. To solve this you simply need add a reference of the ServiceREferences.ClientConfig file inside your UI project. Recompile and the problem goes away.

Hope this helps.

Till next time,

Thank You Activision! King’s Quest Lives On!

Rob Eisenberg — Sat, 10 Jul 2010 19:40:00 GMT

Some months back I blogged about “The Silver Lining,” a King’s Quest fan project that’s been in development for almost eight years. I was upset because Activision, after acquiring Vivendi-Universal, decided to shutdown the project. Well, it seams that things have changed! Activision has granted Phoenix Online a full non-profit license to release all five episodes over the coarse of 2010. Thank you Activision! You did something really good. In about 20 minutes from now, Episode 1: What is Decreed Must Be, releases to web. Here’s the list of episodes planned in the series:

Episode 1: What Is Decreed Must Be
Episode 2: Two Households
Episode 3: My Only Love Sprung From My Only Hate
Episode 4: ‘Tis In My Memory Locked, And You Yourself Shall Hold The Key Of It
Episode 5: A Thousand Times Goodnight

Can you tell I’m excited?! Counting down the minutes…

Do Story Points Relate to Complexity or Time? Response

Rob Reynolds — Fri, 09 Jul 2010 02:24:57 GMT

I was recently pointed to an InfoQ article titled Do Story Points Relate to Complexity or Time? It mentions that some teams estimate by a matter of complexity versus how long in effort something will take. Mike Cohn, who wrote the original post It’s Effort, Not Complexity, makes some very good points into how people should estimate based on how much time a story will take to finish versus another story. Relative effort, not complexity. The argument here is that complexity should not matter if two stories take the same amount of time to complete.

I thought Mike and the article illustrate some very important points. Effort is different than complexity. The InfoQ story mentions:

Dentist - In a BOX!

Mike gave an interesting example where he compares the two backlog items of licking 1000 stamps and performing a simple brain surgery. According to Mike, despite their vast difference in complexity, they should still be given the same story points because they would take the same amount of time.

I am humbly reminded of the humorous video on the right (Dentist – In A BOX!) when presented with this idea of performing brain surgery. The other part of the story that was great talked about story points being a function of effort, risk and uncertainty (link back to Mike’s original comment):

Perhaps the way to say that is that points are a function of effort, risk and uncertainty, or SP = f(E, R, U). (Call one of those complexity if you want; it’s not important.) The idea is that points are an estimate of the effort involved. Risk, uncertainty, complexity, doubt and other things people have mentioned here can be incorporated BUT only to the extent they affect the expected effort. If something is complex but that complexity will not affect the time to implement the feature, that complexity should not affect the estimate—that was my point with the lists of numbers to be multiplied or added.

I do want to point out what Mike mentioned in one of his other comments:

Thinking of points as a function of Effort, Complexity and Doubt is fine. In my reply above to John I just combined Complexity and Doubt into one thing: Uncertainty.

Points are a measure of how long it will take (effort). How long it will take can be affected by other things and those can influence our estimate. The key is to remember and understand that it is always about time–no client ever cares how hard we had to think, only how long it took.

“No client ever cares about how hard we had to think,only how long it took.” What I believe I am hearing is that Mike is not discounting that there is effort in understanding. Thinking, research, and learning time is still effort, and I think a lot of people miss this important point when they talk about effort. The example provided was a doctor versus a boy on the two tasks. What happens if they are the same person and that person is not a doctor? What if it’s you?! In my mind, that makes a better determination of what developers face when estimating a simple problem versus a complex one.

Let’s explore this idea in more detail. What all goes into the effort required to lick 1000 stamps versus perform brain surgery if you had to do them? Sure the effort of actually performing the task is roughly the same, but the effort to learn how to lick a stamp is significantly less than the effort required to learn how to perform brain surgery. And that I believe more accurately represents what we as developers go through.

To further illustrate, where I work, we also take stories and estimate tasks from those stories. With that I have started including ramp up time as part of the effort for my team as developers. A problem could take 15 minutes for me to code. But it might take me 2 hours to understand what it is that needs to be done. That is not a 15 minute task. That is a 2 hour and 15 minute task. And the effort involved was 2 hours and 15 minutes.

Thoughts?

Caliburn.Micro Soup to Nuts Pt. 2 – Customizing The Bootstrapper

Rob Eisenberg — Fri, 09 Jul 2010 00:28:00 GMT

In the last part we discussed the most basic configuration for Caliburn.Micro and demonstrated a couple of simple features related to Actions and Conventions. In this part, I would like to explore the Bootstrapper class a little more. Let’s begin by configuring our application to use an IoC container. We’ll use MEF for this example, but Caliburn.Micro will work well with any container. First, go ahead and grab the code from Part 1. We are going to use that as our starting point. Add two additional references: System.ComponentModel.Composition and System.ComponentModel.Composition.Initialization. Those are the assemblies that contain MEF’s functionality.* Now, let’s create a new Bootstrapper called MefBootstrapper. Use the following code:

using System;
using System.Collections.Generic;
using System.ComponentModel.Composition;
using System.ComponentModel.Composition.Hosting;
using System.ComponentModel.Composition.Primitives;
using System.Linq;

public class MefBootstrapper : Bootstrapper<IShell>
{
    private CompositionContainer container;

    protected override void Configure()
    {
        container = CompositionHost.Initialize(
            new AggregateCatalog(
                AssemblySource.Instance.Select(x => new AssemblyCatalog(x)).OfType<ComposablePartCatalog>()
                )
            );

        var batch = new CompositionBatch();

        batch.AddExportedValue<IWindowManager>(new WindowManager());
        batch.AddExportedValue<IEventAggregator>(new EventAggregator());
        batch.AddExportedValue(container);

        container.Compose(batch);
    }

    protected override object GetInstance(Type serviceType, string key)
    {
        string contract = string.IsNullOrEmpty(key) ? AttributedModelServices.GetContractName(serviceType) : key;
        var exports = container.GetExportedValues<object>(contract);

        if (exports.Count() > 0)
            return exports.First();

        throw new Exception(string.Format("Could not locate any instances of contract {0}.", contract));
    }

    protected override IEnumerable<object> GetAllInstances(Type serviceType)
    {
        return container.GetExportedValues<object>(AttributedModelServices.GetContractName(serviceType));
    }

    protected override void BuildUp(object instance)
    {
        container.SatisfyImportsOnce(instance);
    }
}

That’s all the code to integrate MEF. First, we override the Configure method of the Bootstrapper class. This gives us an opportunity to set up our IoC container as well as perform any other framework configuration we may want to do, such as customizing conventions. In this case, I’m taking advantage of Silverlight’s CompositionHost to setup the CompositionContainer. You can just instantiate the container directly if you are working with .NET. Then, I’m creating an AggregateCatalog and populating it with AssemblyCatalogs; one for each Assembly in AssemblySource.Instance. So, what is AssemblySoure.Instance? This is the place that Caliburn.Micro looks for Views. You can add assemblies to this at any time during your application to make them available to the framework, but there is also a special place to do it in the Bootstrapper. Simply override SelectAssemblies like this:

protected override IEnumerable<Assembly> SelectAssemblies()
{
    return new[] {
        Assembly.GetExecutingAssembly()
    };
}

All you have to do is return a list of searchable assemblies. By default, the base class returns the assembly that your Application exists in. So, if all your views are in the same assembly as your application, you don’t even need to worry about this. If you have multiple referenced assemblies that contain views, this is an extension point you need to remember. Also, if you are dynamically loading modules, you’ll need to make sure they get registered with your IoC container and the AssemblySoure.Instance when they are loaded.

After creating the container and providing it with the catalogs, I make sure to add a few Caliburn.Micro-specific services. The framework provides default implementations of both IWindowManager and IEventAggregator. Those are pieces that I’m likely to take dependencies on elsewhere, so I want them to be available for injection. I also register the container with itself (just a personal preference).

After we configure the container, we need to tell Caliburn.Micro how to use it. That is the purpose of the three overrides that follow. “GetInstance” and “GetAllInstances” are required by the framework. “BuildUp” is optionally used to supply property dependencies to instances of IResult that are executed by the framework.

Word to the Wise

While Caliburn.Micro does provide ServiceLocator functionality through the Bootstrapper’s overrides and the IoC class, you should avoid using this directly in your application code. ServiceLocator is considered by many to be an anti-pattern. Pulling from a container tends to obscure the intent of the dependent code and can make testing more complicated. In future articles I will demonstrate at least one scenario where you may be tempted to access the ServiceLocator from a ViewModel. I’ll also demonstrate some solutions.**

Besides what is shown above, there are some other notable methods on the Bootstrapper. You can override OnStartup and OnExit to execute code when the application starts or shuts down respectively and OnUnhandledException to cleanup after any exception that wasn’t specifically handled by your application code. The last override, DisplayRootView, is unique. Let’s look at how it is implemented in Bootstrapper<TRootModel>

protected override void DisplayRootView() 
{
    var viewModel = IoC.Get<TRootModel>();
#if SILVERLIGHT
    var view = ViewLocator.LocateForModel(viewModel, null, null);
    ViewModelBinder.Bind(viewModel, view, null);

    var activator = viewModel as IActivate;
    if (activator != null)
        activator.Activate();

    Application.Current.RootVisual = view;
#else
    new WindowManager().Show(viewModel);
#endif
}

The Silverlight version of this method resolves your root VM from the container, locates the view for it and binds the two together. It then makes sure to “activate” the VM if it implements the appropriate interface. The WPF version does the same thing by using the WindowManager class, more or less. DisplayRootView is basically a convenience implementation for model-first development. If you don’t like it, perhaps because you prefer view-first MVVM, then this is the method you want to override to change that behavior.

Now that you understand all about the Bootstrapper, let’s get our sample working. We need to add the IShell interface. In our case, it’s just a marker interface. But, in a real application, you would have some significant shell-related functionality baked into this contract. Here’s the code:

public interface IShell
{
}

Now, we need to implement the interface and decorate our ShellViewModel with the appropriate MEF attributes:

[Export(typeof(IShell))]
public class ShellViewModel : PropertyChangedBase, IShell
{
   ...implementation is same as before...
}

That’s it! Your up and running with your bootstrapper configured for MEF.

*If you are using .NET, you will only need to reference System.ComponentModel.Composition.

**I’m quite guilty of this myself, but I’m trying to be more conscious of it. I’m also excited to see that modern IoC containers as well as Caliburn.Micro provide some very nice ways to avoid this situation.

Show Covering Tests with dotCover

Hadi Hariri — Tue, 06 Jul 2010 20:58:00 GMT

One of the new features dotCover has added is the ability to find tests that cover a certain piece of code. Something remotely similar has been available in ReSharper, although it has been kind of an archaic solution (i.e. Find Usages on Method calls, locate Test assemblies in Result window).

dotCover makes this easier by providing quick access to this information and extends it in functionality.

Below we can see some tests from an MVC application. Let’s run Code Coverage on it using dotCover first.

Now let’s switch over to the Source Code and select some random source code, in this case the MembershipService.ChangePassword line in the ChangePassword action:

In order to see the tests that cover this line of code, we can either press the default key combination of Ctrl+Alt+K or select the option Show Covering Tests from the dotCover:

dotCover will then display a small window showing all the different tests that cover that line of code.

At this point, we can run the selected tests or add them to the existing ReSharper Test Runner session. This allows us to easily jump from specific sections of code to the corresponding tests and execute them instantly.

One minor note: The default key mapping conflicts with KeePass, but you can easily re-assign it via Visual Studio Tools | Options | Keyboard, or do as I did and change KeePass to Ctrl+Alt+P (P as in Password…makes more sense).

Caliburn.Micro Soup to Nuts Pt. 1 – Configuration, Actions and Conventions

Rob Eisenberg — Tue, 06 Jul 2010 17:47:00 GMT

In this tutorial we will learn a few of the basics of Caliburn.Micro. Let’s start by getting the framework. Head on over to http://caliburnmicro.codeplex.com/SourceControl/list/changesets Either use Mercurial to clone the repo or click on the link for the latest change set, then click on the download link. I recommend that you go ahead and get setup with TortoiseHG for Mercurial. You can read here and/or watch a free TekPub video here for information on that. Once you have the source downloaded, navigate to the “src” folder. Open the “Caliburn.Micro.sln” Pess Ctrl-Shift-B (or use the Build menu) to build the solution in Visual Studio. Now that we have the framework and it’s been successfully built, let’s create a simple application.

Open Visual Studio and create a new Silverlight 4 Application called “Caliburn.Micro.Hello”. You don’t need a web site or test project. Add a reference to System.Windows.Interactivity.dll and Caliburn.Micro.dll. You can find them both in the \src\Caliburn.Micro.Silverlight\Bin\Release (or Debug) folder. Delete “MainPage.xaml” and clean up your “App.xaml.cs” so that it looks like this:

namespace Caliburn.Micro.Hello
{
    using System.Windows;

    public partial class App : Application
    {
        public App()
        {
            InitializeComponent();
        }
    }
}

Since Caliburn.Micro prefers a View-Model-First approach, let’s start there. Create your first VM and call it ShellViewModel. Use the following code for the implementation:

namespace Caliburn.Micro.Hello
{
    using System.Windows;

    public class ShellViewModel : PropertyChangedBase
    {
        string name;

        public string Name
        {
            get { return name; }
            set
            {
                name = value;
                NotifyOfPropertyChange(() => Name);
                NotifyOfPropertyChange(() => CanSayHello);
            }
        }

        public bool CanSayHello
        {
            get { return !string.IsNullOrWhiteSpace(Name); }
        }

        public void SayHello()
        {
            MessageBox.Show(string.Format("Hello {0}!", Name)); //Don't do this.
        }
    }
}

Notice that the ShellViewModel inherits from PropertyChangedBase. This is a base class that implements the infrastructure for property change notification and automatically performs UI thread marshalling. It will come in handy :)

Now that we have our VM, let’s create the bootstrapper that will configure the framework and tell it what to do. Create a new class named HelloBootstrapper. You can use this tiny bit of code:

namespace Caliburn.Micro.Hello
{
    public class HelloBootstrapper : Bootstrapper<ShellViewModel> {}
}

There are two Bootsrappers available in Caliburn.Micro. This version allows you to specify the type of “root view model” via the generic type. The “root view mdoel” is a VM that Caliburn.Micro will instantiate and use to show your application. Next, we need to place the HelloBootstrapper somewhere where it will be run at startup. To do that, change your App.xaml to match this:

<Application xmlns="http://schemas.microsoft.com/winfx/2006/xaml/presentation"
             xmlns:x="http://schemas.microsoft.com/winfx/2006/xaml"
             xmlns:local="clr-namespace:Caliburn.Micro.Hello"
             x:Class="Caliburn.Micro.Hello.App">
    <Application.Resources>
        <local:HelloBootstrapper x:Key="bootstrapper" />
    </Application.Resources>
</Application>

All we have to do is place a Caliburn.Micro bootstrapper in the Application.Resources and it will do the rest of the work.* Now, run the application. You should see something like this:

Caliburn.Micro creates the ShellViewModel, but doesn’t know how to render it. So, let’s create a view. Create a new Silverlight User Control named ShellView. Use the following xaml:

<UserControl x:Class="Caliburn.Micro.Hello.ShellView"
             xmlns="http://schemas.microsoft.com/winfx/2006/xaml/presentation"
             xmlns:x="http://schemas.microsoft.com/winfx/2006/xaml">
    <StackPanel>
        <TextBox x:Name="Name" />
        <Button x:Name="SayHello"
                Content="Click Me" />
    </StackPanel>
</UserControl>

Run the application again. You should now see the UI:

Typing something in the TextBox will enable the Button and clicking it will show a message:

Caliburn.Micro uses a simple naming convention to locate Views for ViewModels. Essentially, it takes the FullName and removes “Model” from it. So, given MyApp.ViewModels.MyViewModel, it would look for MyApp.Views.MyView. Looking at the View and ViewModel side-by-side, you can see that the TextBox with x:Name=”Name” is bound to the “Name” property on the VM. You can also see that the Button with x:Name=”SayHello” is bound to the method with the same name on the VM. The “CanSayHello” property is guarding access to the “SayHello” action by disabling the Button. These are the basics of Caliburn.Micro’s ActionMessage and Conventions functionality. There’s much more to show. But, next time I want to show how we can integrate an IoC container such as MEF. This sample is attached below.

*All the functionality described in this article works identically for both Caliburn.Micro and Caliburn…with one exception. Caliburn does not have a Bootstrapper currently. At this time, you would inherit from CaliburnApplication and override CreateRootModel. In the coming months, Caliburn’s custom application class will be replaced by a bootstrapper mechanism similar to Caliburn.Micro.

Devlicio.us - Just the Tasty Bits

Ruby Is Scary

To The Static Typing Stalwarts

To The Enterprise

So Should We All Switch To Ruby Now?

Open Source Whining

Best Error Dialog ever w/ Visual Studio

CodeBetter/Devlicio.us/LosTechies MSDN Ultimate Giveaways

How to detect the theme being used in WP7

YouTrack for OSS Projects

What are the next steps?

The Future of .NET Open Source Software Delivery

The Past and Present

Problems with the Present Method of Delivery

The Future

What Issues Does the Future Method of Delivery Address?

The Future Is Now

Related Posts

Dynamically Changing Resources in a ListBox using Binding and Converters

Semi final release – Windsor 2.5 beta 2 (now with Silverlight support)

Writing plug-ins for ReSharper: Part 2 of N

What is a QuickFix?

Highlighting Daemons

Step by Step Guide

The End Result

Summary

How To – UppercuT and Gems

Rock The Gems

Removing All of the Other Output After the Gem is Built

What If I Want to Change What Goes Into my Gem?

Learn More

Related Posts

Gems For .NET – Community Response

My Objective Today is to Make You Think

Caliburn.Micro Soup to Nuts Pt. 3 – All About Actions

How To – Gems And .NET – Dependencies (References)

Adding a Reference as a Dependency

Gem Exists?

Gem Doesn’t Exist?

Related Posts

How To - Gems And .NET

Setup

GemSpec for .NET

Dependencies On Other Libraries

VERSION file

Libraries

Documentation

Executables

Build And Push

Related Posts

Gems - Package Management For .NET

Background

Why Should I Care?

Why Should I Get Excited?

Related Posts

Announcing SharpRobotica.com ...the softer side of robotics

Updated Bits for WP7 – Beta Build

'ServiceReferences.ClientConfig' in the .xap application package Error in WP7

Thank You Activision! King’s Quest Lives On!

Do Story Points Relate to Complexity or Time? Response

Caliburn.Micro Soup to Nuts Pt. 2 – Customizing The Bootstrapper

Show Covering Tests with dotCover

Caliburn.Micro Soup to Nuts Pt. 1 – Configuration, Actions and Conventions