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.
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.
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.
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.
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.
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.
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:
I just got this test pass:
[Test]
public void BasicCase()
{
ProxyGenerationOptions options = new ProxyGenerationOptions();
options.Selector = new AllInterceptorSelector();
var target = this.generator.CreateInterfaceProxyWithTarget(
typeof(ISimpleInterface),
new SimpleClass(),
options,
new NoopInterceptor() ) as ISimpleInterface;
Assert.IsNotNull( target );
target.Do();
}
And here’s how Do proxy method looks like in Reflector:
Code created in more recent versions of C# has a lot of generated types, even if you don’t use code generation explicitly. Interators (the yield keyword), and anonymous delegates both use generated types underneath. Also those neat anonymous types introduced in C# 3.0 are nothing more than a compiler magic.
All this may clutter your NDepend window of choice, when looking at your projects. You can however get rid of generated stuff, pretty easily, with this simple CQL query:
// <Name>Types not generated by the compiler</Name>
SELECT TYPES FROM ASSEMBLIES "YourAssembly"
WHERE !(HasAttribute "System.Runtime.CompilerServices.CompilerGeneratedAttribute")
Simple, but useful.
If you want to get rid of just some types of generated classes, for example you want to get rid of iterators, but want to leave anonymous delegate classes, you may use regular expressions for that. This is my clumsy attempt to that:
// <Name>Types not generated by the compiler</Name>
SELECT TYPES FROM ASSEMBLIES "Castle.Facilities.WcfIntegration" WHERE
!NameLike ".+<>c__.+" /* Anonymous delegates, like private sealed class <>c__DisplayClass1
*/ AND
!NameLike ".+\+<.*>d__.+" /* Iterators, like private sealed class <FindDependencies>d__0<T> :
IEnumerable<T>, IEnumerable, IEnumerator<T>, IEnumerator, IDisposable */
Last minor version of NDepend introduced cool, interactive Dependency Graph, that was really a huge step forward as compared to static .png we got earlier. You can now load set of assemblies, and immediately see dependencies between them, without running your_picture_viewer_here. You also can drill down the dependency tree and see dependencies between namespaces within an assembly, classes within namespace, methods within class…
One thing (ok, there are more, but we’ll get to that in a minute), that I missed, was the ability to remove an element from the graph. You could do this using CQL, but this just was too complicated solution. This is now possible with new and fresh 2.10.3 build.
So, back to my wishlist. You can interact with only one element of the graph at any given moment. That means, although you can select few assembles with ctrl+LMB if you click Remove, only one will get removed. Same with drilling down. You can’t select few assembles and go “View internal dependency cycles on graph” to see cycles between classes in all of those assemblies. (well, you can as a matter of fact do this with CQL, but again, this may require a lot of typing and GUI just feels like the right place to do it.)
Second thing I wish it had, is a scrollbar for zooming instead of + / – buttons. Can we get this Partick?