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.
Software quality is the great white whale of the software industry. We often seek it, but are totally unprepared to do anything about it. As in the tale by Melville, we can point out our Captain Ahab’s who are driven towards the extremes in ensuring quality. We also have the rest of the world that gets by not even thinking about it, except to say we know someone who knows someone that heard someone else talk about it in the dark corners of tavern once.
I have decided to dig deeper into an area of development I usually try to avoid – the client. Not just another rich desktop client, but a web client. For years, I have always kept myself at arms length when dealing with client technologies, especially web technologies. I have worked with them many times, but I have always preferred the server side. I have worked with nearly every Microsoft client technology from the Window C API, MFC, ATL, WTL, VB, WinForms, WPF, and probably a few others I can no longer remember.
Recently, I have received a few requests for some changes and an example for my Type Tracking Extension for Unity. This post is to address those requests. Of course, all of the source code for this post is added to the GitHub project Unity Extensions.
Part One – Extension Methods for the Type Tracking Extension The number one request I have received, and my own number one issue with using the Type Tracking Extension, is the verbosity of each method call.
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.
Inspired by Scott’s post Hanselminutes – This is usually the podcast that helps to clarify some topic I had been meaning to learn more about. Sometimes a bit too focused on the web end of the spectrum, but still a solid source on what is out there and what is coming up.
Dave’s Bus Ride of Knowledge Podcasts on .NET Development
|Hanselminutes – This is usually the podcast that helps to clarify some topic I had been meaning to learn more about.
A few weeks ago I read the blog post Git and command-line fear by James Gregory. He argues against the common Git on Windows complaint of poor Windows support. While I appreciate James’ position that this is not entirely true, and that most people do associate Windows support with GUI based tools or Visual Studio integration, I do disagree with his assertion that command line tooling is a valid use case.
Edit: Updated link at GitHub.
{: .center_image }
I have finally found an online code sharing site to post my open source code to – Hazware Unity Extensions on GitHub. I posted all of the source code for my Type Tracking Unity Extension there, and decided to follow the Ninject model for licensing – I dual licensed it as MS-PL and Apache, so go enjoy and help me make it better.
In my efforts to experiment with WPF, I decided to try the always popular WPF sample of an irregular or custom shaped window. I had set out the following goals for this sample:
Create an oval shaped window with no standard Windows chrome Create a context menu that supports minimizing and closing the window Support dragging the window when the left mouse button is pressed Step 1 - Create an oval shaped window with no standard Windows chrome Searched the web yields a significant amount of results on how to do this, so I am only going to summarize the solution.
For the past few years Microsoft has been pushing WPF as the future user interface framework for .NET. During that time I have seen numerous demos and presentations showing amazing user interfaces. They would describe the new model of separating the designer from the developer, and how successful they were. I would usually ask two questions as a response. First, how many designers and developers were involved. Second, how close to the original time and resource estimate was the actual effort.