.NET OSS dependency hell

Paul, whom some of you may know as the maintainer of Horn project, left a comment on my blog, that was (or to be more precise – I think it was) a continuation of series of his tweets about his dissatisfaction with the state of affairs when it comes to dependencies between various OSS projects in .NET space, and within Castle Project in particular.


I must say I understand Paul, and he’s got some valid points there, so let’s see what can be done about it.


One of the goals of Castle Project from the very beginning has been modularity of its elements. As castle main page says:

Offering a set of tools (working together or independently) and integration with others open source projects, Castle helps you get more done with less code and in less time.

How do you achieve modularity. Say you have two projects, Foo and Bar that you want to integrate. You could just reference one from the other.


This however means that whenever you use Foo, you have to drag Bar with you. For example, whenever you want to use MonoRail, you’d need to drag ActiveRecord with it, along with entire set of its dependencies, and their dependencies, etc.

Instead you employ Dependency Inversion (do not confuse with Dependency Injection). You make your components depend on abstractions, not the implementation. This however means, that in .NET assembly model, you need to introduce third assembly to keep the abstractions in.


Now we have 3 assemblies instead of 2 to integrate two projects. Within Castle itself common abstractions are being kept in Castle.Core.dll. But what if we want to take more direct advantage of one project in another project still maintaining the decoupled structure? We need to extract the functionality bridging the two projects to yet another assembly. Tick – now we have 4 of them.


In this case the FooBar project would be something like ActiveRecord integration facility, which integrates ActiveRecord with Windsor.

When you mix multiple projects together you enter another problem – versioning.

Say you want to integrate few projects together, some of which are interdependent (via bridging assemblies, not shown here for brevity)


Now, once a new version of one of the projects is released, you either have to wait for all the other projects to update their dependency to the latest version, do it yourself (possibly with some help from Horn), or stick to the old version. The situation gets even more complicated when there were some breaking changes introduced, in which case plain recompilation will not do – some actual code would need to be written to compensate for that.

These are the main issues with this model, let’s now look at possible solutions.


First thing that comes to mind – if having some assemblies means you’ll need even more assemblies, perhaps you should try to minimize that number? This has already come to our minds. With last wave of releases we performed some integration of projects. EmailSender got integrated into Core, one less assembly. Logging adapters for log4net and nlog were merged into core project, which means they still are separate assemblies (as they bridge Castle with 3rd party projects) but they’re now synced with Core and are released with it, which means this is one less element in your versioning matrix for you to worry about. Similar thing happened with Logging Facility, which now is versioned and released with Windsor itself.

For the next major version, there are suggestions to take this one step further. Merge DynamicProxy with DictionaryAdapter and (parts of) Core into a single assembly; Merge Windsor and MicroKernel (and other parts of Core) into an other assembly. With that you get from 5 assemblies to 2.

That reduces Castle’s internal dependencies, but what about other projects that depend on it? After the recent release, we started a log of breaking changes, along with brief explanation and suggested upgrade paths, to make it easier for applications and frameworks to upgrade. We have yet to see how this plays out.

What else can be done?

This is the actual question to you? What do you think can be done, for Castle specifically, but more broadly – for entire .NET OSS ecosystems to make problems Paul mentioned go away, or at least make them easier to sort out?

ReSharper’s “hidden” gem – live templates.

I’m sure many of you, even those who use ReSharper on a daily basis, almost never use one of its most powerful features – live templates.

I just love how with single shortcut (ctrl + alt + insert) I can go to


enter, I go to


Type class name, enter


and I have just saved roughly 30s as compared to bare Visual Studio, but most importantly, I didn’t loose my momentum and focus. Sure it’s a small thing, but that’s how you build a palace – brick by brick.

Disabling Visual Studio F1 Help shortcut

If you, like Mario (or me today), ever accidentally hit F1 in Visual Studio, and spent next couple of minutes looking at similar screen, I have a remedy.


How often do you really use F1 to access Visual Studio help anyway? Wouldn’t it be good to just disable this shortcut? Well, as I learned today – you can do this.


Go to Tools –> Options… navigate to the option above, find the command Help.F1Help and click Remove, et voilà!

Happy coding.

ReSharper goodness

I upgraded to ReSharper 4.5 recently, and when working with it I discovered new, cool feature.

Having this (notice class Person does not exists yet, hence the red):


You can do this:


And get this:


I’m pretty sure older version would say private static object person;

And even if it’s not new, it’s still a nice little smart feature.

I only wish that doing this…


… would also generate the constructor and property in one go.

Technorati Tags:

Productivity tip of the week, part 3

This time it’s not a single keyboard shortcut. There’s a little known feature of ReSharper, called To-Do Items. It’s a series of tags, you can define, and when you put them in your comments somewhere in the code, ReSharper will pick the comment up and put it, in the To-Do Explorer Window.

There are 3 predefined tags: TODO, BUG, NOTE and NotImplemented which picks up the NotImplementedException occurrences in your code. Yes, this is not a code comment, but most of the time you’ll use comments only.

So how is this useful and boosts productivity?

As you code your way, you can tag it with such comments, mostly for later review or to fix later.


You can then immediately view all of them in To-Do Explorer, and jump to any of them.


One thing I do however, is I redid the tags (defined via regular expressions), because the default ones used to pick up false positives.


I changed the pattern to be case sensitive and to include a colon after a tag. To make use of this feature, I also keep my To-Do Explorer window always visible, to ensure that I do pick up the comments I, or any other developer on the team puts in the code.

Technorati Tags:

Writing Launchy plugin in C# with Launchy#

Today I learned about Launchy# – C# binding for Launchy extensibility API, that allows developers to write Launchy plugins in managed code. I once wrote… a hack more than extensions, that enabled users to tweet from Launchy. I was reluctant to extend it further, because then I’d have to write unmanaged code, which is far from my definition of fun.

However, now I’m thinking about playing a little bit with Launchy# and building a proper Twitter-Launchy pluging (Twitty?).

So now I’m gathering ideas. What would you like to see in  Twitty?


It looks like the name Twitty is already taken (I should have googled that first). So now I’m looking for ideas and name.

Technorati Tags: ,

Working effectively with Reflection.Emit

I’ve been working a little bit with dynamic code generation at runtime (classes in Reflection.Emit namespace, collectively referred to as Reflection.Emit). It’s a low level API, that requires you to work with IL operations, keep track of what is on the stack, and requires quite a bit of knowledge about IL and CLR.

I’m no expert in IL, as probably most of developers, but there are ways to make this things easier.

To work my way through generating code, I use iterative approach.

  1. Write a class/method in C# that exactly (or as closely as possible) reassembles a single small part of what I want my dynamic method to look like. If my dynamic method is a static method – I write a static method. If it has a value type parameter, I write a method with value type parameter. I think you get the picture. The important thing is to really get as close to what you want to achieve with dynamic method as possible, and understand influence of those parts you can’t get exactly the same (for example because of C# limitations).
  2. I compile the class (also notice differences between mode you compile in – you usually want Release version, not Debug), and open it up in Reflector to see its IL.
  3. I write my code that does code generation, to generate IL identical to the one of my statically wrote method (taking into account all the variability).
  4. I save generated assembly, open it up in Reflector, and compare the IL, to the one created earlier, to see if they match. I often switch in Reflector to C# view, to better see some kinds of errors (passing wrong parameters, or calling method on wrong object). If you can’t save your generated code to physical assembly you can’t use this debugger visualizer to see its IL.
  5. Write and run tests.
  6. If everything works, go back to step one, add another part of code and repeat until you have all you wanted.

Here’s an example of this approach. It’s an actual code I wrote while working on DynamicProxy feature. The thing that is different here, is that Castle has an additional layer of abstraction on top of Reflection.Emit so I was not working directly with IL. This makes things a little bit easier, because you’re operating on a higher level of abstraction. On the other hand however, you don’t get that tight control over what gets generated, and you have a new API to learn.

Anyway, I actually already had a pretty good idea of what I wanted to do (I only needed to change the way things worked, by calling other constructor in my dynamic method, passing additional parameters). I wrote some tests to verify that my code works the way I wanted it to, and I implemented it. Unfortunately one test didn’t pass with the following error.


One parameter I wanted to pass was an array, passed by reference, and it seemed that there was something wrong with it.

I opened Reflector and peeked into the generated method. Everything looked just fine when I switched to C# view.


To investigate things further I saved IL of generated method to a file, and I did the same with IL of C# method I wrote as an example of what I wanted to accomplish. I then opened them both up in a diff tool to see where the difference was.


As it turns out, the code below (generated.txt) passes the loads the field value (ldfld) while it should load its address (ldflda). Knowing this it was trivial to fix my code.

On a side note, there’s also a Reflection.Emit Language plug-in for Reflector that may be useful to you if you’re working directly with Reflection.Emit classes. It shows you for any method you select the C# code that you’d write to generate that method with Reflection.Emit.

Technorati Tags: , ,

Multilingual .NET applications. Enter .NET localization

Creating multilingual applications is a huge topic. There are whole books devoted to it, and if you’re serious about it, you should definitely read those, because what you see on surface, is only the tip of an iceberg.

If you only want to play with localization or need a quick reference, hopefully this post will help.

Fist thing is, .NET is really well thought of if it comes to localization, so if you know what you’re doing, it’s pretty painless to create application that will be easy to translate to other languages (localization is a LOT bigger topic than showing labels in different languages, but I’ll leave this topic out.)

Second thing is, localization mechanism in .NET is greatly based on conventions, and it’s what we’ll focus here.

First obvious rule is, that each string, picture, video… generally speaking localizable resource must not be hardcoded.

If you don’t hardcode resources where do you keep them? In (surprise) Resources file. Generally you can use .resx files, or plain .txt, though the latter are useful only if you only keep strings.


Visual Studio has pretty good support for editing resources in .resx files, and later I’ll show you another tool that can do it as well.

To access the resources programmatically you need ResourceManager class. To instantiate it you need to give it the part to resources within an assembly, and the assembly itself. If it’s a little bit unclear, here’s the example:


If the Visual Studio project is named LocalizableApp, and the .resx file we want to use is in folder Properties, and the file itself is named Resources.resx, the whole base name for the resources is “LocalizableApp.Properties.Resources”.

That’s where the compiled .resx file (.resources) will be located within the assembly. You can see it, if you open the compiled assembly with Reflector.


So to instantiate the ResourceManager you’d write code similar to the following:

var manager = new ResourceManager("LocalizableApp.Properties.Resources", typeof(Program).Assembly);

Each resource is identified by it’s unique name string. For example in the picture below, we have two resources with names, “greeting” and “howAreYou”


You use these names to get the values of the resources. The resource manager does its magic, to provide you with resources best matching the CultureInfo you provided. If you don’t provide any Culture, current thread’s CurrentUICulture is used. So if you write:

Console.WriteLine("{0} {1}", manager.GetString("greeting"), manager.GetString("howAreYou"));

The CultureInfo object held in CurrentUICulture property of currently executing thread will be used. The default value for this property is the same as language version of Windows OS the program is executing on, which is reasonable. If your user uses Polish Windows she will probably want to interact with Polish version of your app as well.

You may not rely on this default though, and either override the Thread’s property, or specify the culture explicitly when calling methods on ResourceManager, like so:

culture = CultureInfo.GetCultureInfo("pl-PL");
Console.WriteLine("{0} {1}", manager.GetString("greeting", culture), 
    manager.GetString("howAreYou", culture));

Of course you wouldn’t hardcode the culture the way I did in the example, because it would defeat the purpose of using culture in the first place.

OK, so how to add another language?

You have the .resx file with the default, fallback resources, right? So now all you need is either send the file to a localization company, sit back and enjoy life, waiting for them to do the hard job, or do it yourself. To go with the latter option, you may want to use a tool to edit resource files, called Resourcer, by Lutz Roeder (Reflector, people!).


You can easily edit any kind of resources in it (not only strings). When you’re done translating your resources, save the file as .resources file, using following pattern: {baseResourceName}.{culture}.resources. For example if you were to translate our example app, to German language as spoken in Germany, you’d save your edited file with the following name: LocalizableApp.Properties.Resources.de-de.resources

It is important to obey this pattern, as by convention, this is what ResourceManager expects. If you fail to obey it, ResourceManager will not be able to pick your translated resources and will fall back to the default.

Having translated and properly named .resource file we need to make a satellite assembly out of it. To do it, you need Assembly Linker (al.exe) tool that is part of .NET SDK.


There are multiple properties you can set with al, the minimal version to get valid satellite assembly is shown on above screenshot. One thing that’s important to note, is the name of resulting satellite assembly. Again, by convention it has to be {NameOfBaseAssemblyWithoutExtension}.resources.dll, so if our application assembly was named LocalizableApp.exe, satellite assembly must be called LocalizableApp.resources.dll

Notice that the name of the assembly is the same for every culture. So how do we deal with that. Obviously we can’t have two files with the same name in one folder. The way it is handled, is through subfolders. Each satellite assembly is held in a folder which is named after the culture of the satellite assembly.


For example if our LocalizableApp.exe is held in a folder, let’s say Debug like on the above screenshot, the de-de satellite assembly would be Debug\de-de\LocalizableApp.resources.dll and for instance pl assembly would be in Debug\pl\LocalizableApp.resources.dll.

I hope this is all clear by now. The greatest thing is, to add new language you don’t even need the actual base assembly. All you need is its resources and their location within the assembly.

Technorati Tags: , ,

Unity framework and the Principle of the Least Surprise

I don’t like the Unity Inversion of Control framework. I find it too verbose, requiring user to be too explicit (except for cases where it doesn’t while it should), not intuitive and I generally don’t like its design. Unfortunately, it’s the only IoC framework I’m allowed to used at work, so I’m stuck with it, good or bad. There are times however that I’m just astonished by how it works, and mostly, in a negative sense. There’s an important principle in computer science, called Principle of the Least Surprise, that says, that framework (in particular) should have its API designed in such a way that it works like the user (programmer in this case) would expect it to.

Let’s take… well, I don’t know… Unity for example.

Take a look at the following piece of code:


Everything seems pretty obvious here, to anyone who has ever used an IoC container. Using generic parameter I register a type (ServiceHost) service, with specific key (myService), then I explicitly (I could write a whole post about how not good idea it is, but it’s leave it out for now) specify constructor I want used and it’s parameters using InjectionConstructor, next I specify method injection with InjectionMethod class. Pretty simple, huh?

Now, let’s take a closer look at InjectionMethod constructor. It takes a string, denoting method’s name, and next it takes the list of objects (array of System.Object to be precise) that should be used as method’s parameters, right? the tooltip leaves no doubt about it. It says:

methodParameters: Parameter values for the method.

Well, if you think it’s obvious imagine my surprise when I saw this, after running this code:


Turns out it’s not so obvious to everybody. To make the long story short, pulling Unity’s source code showed, that there’s a fine print to that method (well, actually there’s none, it just works in unexpected ways, maybe that behavior is mentioned somewhere in the docs, but I’m paid for writing working code, not for reading docs). It does use the parameters you provide literally, most of the time. However if you pass an argument of type System.Type, like I did, Unity implicitly tries to know better, what you want to do, than yourself. It assumes that since you passed a System.Type, as System.Object parameter, for sure what you meant was not to use it literally, but instead to use instance of service of that type registered with the container, and that’s what it tries to do. It then fails to bind those parameters to the method, which results in aforementioned exception. To make it work you have to be yet smarter and know another implicit rule of Unity, that if you pass as parameters values of types derived from InjectionParameterValue it will handle them correctly. So changing the above code to this, yields the expected results:


Technorati Tags: ,