Stop Visual Studio Express 2012 from SCREAMING at you

I don’t develop .NET code professionally but I do like to keep my tools sharp in every direction – that includes knowing the latest technologies even if they don’t relate to JEE.

Playing around with .NET means I need a good environment at a reasonable price (read free) and after trying SharpDevelop and VS Express a couple of years ago I decided that the best IDE for me was VS C# Express.

After happily using it for more than 2 years I upgraded to VS Express 2012 for Windows Desktop (there’s no C# edition anymore) and surprise – the menus WERE SCREAMING AT ME IN ALL CAPS.

At first you ignore it but after a while it becomes really annoying so I decided to fix it.

I asked around and I found a post by @shanselman that mentioned a registry trick to stop VS from capitalizing menus but it only worked for a full install of Visual Studio and not for Express.

I fired up my trustworthy procmon, identified the registry path for VS Express, tried it and it worked. Here’s how it looks like:


If you want to fix it too, here’s the registry key and value that you need to create:



DWORD value of 1

Apis – The Web API builder


I KEEP six honest serving-men

(They taught me all I knew);

Their names are What and Why and When

And How and Where and Who.

Rudyard Kipling



In Prototyping the web API I started describing an idea to build a tool that can be used to try out/prototype web APIs before actually building a back-end implementation, helping a team to describe a clear and strict HTTP API, as well as allowing them to build and test client code without having written one line of server-side code.

This post is taking those ideas further, trying to crystallize the concept, objectives, goals and my overall expectations of this tool.

Based on my previous attempts at crudely building a harness for my web development habits, I’ve outlined a sort of a wishlist.

Apis, as I’ve so naively chosen to name this tool will be a part of my typical development stack and must:

  • Have a pleasant, easy to use interface where I can define the desired HTTP API, including endpoints, request and response configuration that I can export as a well-structured definition document;
  • Allow me to save the definition in a human readable and human editable format that can also be saved, compared and merged in a VCS;
  • Allow me to define standard responses for each API endpoint based on the request configuration so I can test the API, build a proof-of-concept API and even build a whole user interface decoupled from back-end services;
  • Allow me to define static resources that will be served alongside the standard responses, such as JavaScript frameworks, CSS styling and any other kind of resource I want to serve;
  • Be standalone and packaged in an easy-to-use installer so I can send it to my fellow developers that can load the API definition from VCS and work on it.

That’s about it. If it seems pretty simple, it’s because most useful things are, and should be…. simple.


This is a simple one:

  • I like a well-defined, clear and strict web API in my projects. I want others to want one too;
  • I like to prototype a lot. I want to be able to quickly prototype a web interface without having to set up a web server or –hell no– a full development environment. I want to make it easier for others to prototype;
  • I want to test my decoupled web clients in a clean, well-known state and I want my server-side code to have no idea who they’re talking to.


This is a simple one too:

  • Not like I did before. I want a desktop app, not a whole bunch of code, glue and configuration files;
  • I want to build it clean, so I can easily extend it. I don’t really care about other operating systems than Windows so I’ll build a Windows desktop app;
  • No bloody way I am building it in some scripting language again and I code Java professionally so I don’t want to do it in my spare time. Plus, I really like C#, the .Net stack and WPF;
  • I’ll build it in my own time, build it right, and build it for myself (for a change).

So, Windows, C#, WPF, VS Express and a whole lot of will power it is!

I’ll build it iteratively and story-based. I won’t say agile because well, for an agile process treating communication and people problems… let’s say that you need a minimum of two people for hate or love.

When, Where and Who?

There’s no better time than now and no better place than wherever I am. The Buddhists say it well “Wherever I am, I am home, I am now, I am free”.

I’ll start building it alone. I know it’s not a good idea to work alone, that in programming, one is the loneliest number but later on, if it catches on, I’ll try to get some other people on board.

I’ll host everything on gp… it’s been lonely since the migration to WordPress.

That’s it for now. I was storing this in my brain, which is stupid… that’s why I have a blog.


Get all the types contained in all the assemblies loaded, filtered by namespace

This quick snippet will give you all the types declared in all the assemblies loaded, filtered by namespace.

List<Type> types = new List<Type>();
Assembly[] assemblies = AppDomain.CurrentDomain.GetAssemblies();

foreach (Assembly asm in assemblies)
        IEnumerable<Type> asmTypes = from t in asm.GetTypes() 
              where t.IsClass 
                && (t.Namespace != null && t.Namespace.StartsWith(targetNamespace)) 
              select t;

I actually got to this point because of the way NUnit wraps an assembly in another AppDomain.

The snippet need Linq so it’s for 3.5 or newer.

NanoDI, a small .NET Dependency Injection container

Some time ago I worked on some projects using ASP.NET that were mostly ASPX with some specialized ASHX’s (c# behind the scenes).
The handlers just generated some graphs or exported Excel files, regular code monkey style, no architecture, no plan, just write it fast – quick dirty hack, quick buck – and I always thought that these guys that accept .NET inferior stuff deserve what they get.

As time flew by, I started to get a taste of what .NET is all about, luring me to the dark side.

engine1Photo by B-tal

At the beginning I felt like “this is what evil must taste like”, but I quickly got accustomed to all the new things and now, I’m playing with .NET stuff again, mostly C#, trying to level my skills and having a lot of fun in the process. I built things like the quick and dirty multi font viewer, buggy and poor, mostly because nobody uses it.

Now, I wanted to start something bigger, and nicer (I won’t say what) and I felt that I needed to do it the right way, you know, MAINTAINABLE.
I started looking for a DI container and I started with Spring and Pico. I’m pretty accustomed to pico and I’ve been using Spring since version 1 so I though I’d give them a try. Wrong, strange, alien, weird, huge, EVIL.

For what I wanted to do it really seemed this way. How’s about something that is 10 megs big because spring and dependencies is 7 megs big. And I’m not even going to use most of it, I just want some plain dependency injection and maybe some tooling , like fast i18n.

Problem solved, evil destroyed
I found the solution! Why not have some fun AND learn the inner workings of C# and .Net? Why not build my own? So I did!

NanoDI is a small dependency injection container and tooling for .NET C# projects that are small or that do not need the complexity of bigger IoC solutions.

NanoDI‘s goal is to be small, fast and clean.

Nano Dependency Injection home
NanoDI project page
NanoDI Google Code project

The code is junky by my standards but I’m slowly refactoring as my c# skills get better. Next week I’m going to finish scoping and start working on proxies and interceptors. You can help too!

Have a taste, have fun!