Note: This was presented to the Tampa C# Meetup on April 20th, 2011. One of the greatest challenges in writing code is that nebulous time when the code is too complex to keep the flow all in your head, and when the debugger gets too much in the way for watching the state of your program as it runs. This is the coding twilight zone in which the quality of the code tends to drop as you add line after line of instrumentation to your code to find that spot where something goes wrong.
Note: This was presented to the Tampa C# Meetup on April 6th, 2011. Most large .NET projects will use a number of libraries and frameworks. Those dependencies of your project will have their own dependencies. To make it more complex, those libraries may depend on other libraries, and in some cases – on each other. The Dependency Management Problem The dependency problem is something that strikes fear into the heart of many a developer, and even more in to the lead or manager.
Over the last few weeks I have been writing some in-depth articles for my Learning Caliburn.Micro series. Today is a brief side-discussion where I introduce a ReSharper File Template to help with the task of generating view-models. Background So why do you need this template? Simple – to write those twenty or so lines of code you constantly have to do yourself. I will warn you – this template is highly opinionated.
It has been about two weeks since my last post in my Learning Caliburn.Micro series, so it far past the time for this post. Prepare the Project This post is going to focus on using the Autofac IoC with Caliburn.Micro. From the point of view of the framework it fulfills the same task as the MEF bootstrapper I discussed in Caliburn.Micro the MEFtacluar, or Rob discussed in Caliburn.Micro Soup to Nuts Pt.
Caliburn.Micro Logging Abstraction This post covers logging. Caliburn.Micro has a simple logging abstraction that consists of an ILog interface, and a LogManager class (see below). To add logging to any Caliburn.Micro project, you need to implement a class that extends the ILog interface, and you need to replace the delegate for GetLog. In this post, I will show you how to hook up a debug logger that logs to the Output window in Visual Studio, a log4net logger, and an NLog logger.
I was going to call this post ‘How I learned to stop worrying and love MEF.‘, but I am not sure enough people would get the reference. Besides, it would put the focus too much on MEF, and not on Caliburn.Micro, which is the topic of the post. This is the second in my series of using Caliburn.Micro for WPF applications. The first post, Caliburn.Micro – Hello World, covered an introduction to setting up a project, and the basics of view and view-model interaction.
In this post we are going to create a simple WPF application using Caliburn.Micro. I have created an empty Visual Studio 2010 solution for all the projects in this blog series. All of the code for this series will be available on my Github Learning Caliburn.Micro repository. But I suggest you follow along, and try and do it yourself. Start Visual Studio, and create a new WPF Application project called HelloWorld.
I have used a number of different MVVM frameworks, and none has so-far felt right. Not the worlds most scientific criteria, I will grant you, but still one that I consider valid. I have a preference for lighter-weight frameworks. Another vague criteria, but my definition of it is simple – frameworks that do not impose rigid structures and significant bloat to my application by adding features I dont need. Some of the frameworks I have worked with are: Cinch, MEFedMVVM, MVVM Light Toolkit, and Caliburn.
I really like MEF and I really like proper IoC containers (let the flames begin). I do not think they are mutually exclusive, but best suited for different goals. I consider MEF to be a great way to perform macro level componentization. In other words, it is a way to wire up components that are physically in different assemblies, but it is not well suited for the micro level componentization in which I need to wire up my dependencies within my application.
Nearly every application I write has a project called ConsoleDriver in it. This project is almost always the same as it is just a main routine that create the class that starts my program, wraps it in an exception block, usually configures logging, and waits until I hit enter or CTRL-C to signal the application to exit. Well, after the writing this thousands of times, or copy and pasting it probably even more times, I have had enough.