Resolving version conflicts on MsBuild projects with dep.exe

I’ve recently came accross a surprisingly painful task which were about removing a warning.
One of them were the famous “MSB3247: Found conflicts between different version of same dependent assembly”.

After hours of manual troubleshooting I finally created a command line tool called dep.exe to dump the nested dependencies of every assemblies inside a directory to easily

  • Know which assemblies are referenced (directly or indirectly) with more than one version
  • Understand the dependency chain which pulled those assemblies in your bin folder

Everything is explained on the README of dep.exe.
dep.exe output sample
If you happen to have any question or suggestions, just post them in the comment section.

Brute force on a .p12 password with c#

It started with a VPN problem

The other day, I had an issue with my VPN and someone from the IT service remotely connected to my machine to put a certificate on it. While he manipulated the certificate manager, he exported a certificate and typed a password of 4 characters that I couldn’t see (characters were obfuscated). Just after that he requested me to use another wifi connection to test the VPN so we had to stop the chat and the remote session. Unfortunatly for me it didn’t work and the guy went to lunch.

So now, I was stuck with no VPN and a certificate which were not working! I decided to delete all the personal certificates having my name from my computer and to re-import the p12 file that the IT guy left on my desktop. I tried to do so but then I was requested to type the password – remember? it was only 4 chars. I tried all the stupid 4 letters password I got in mind (“test”, “1234”, “0000”, “aaaa”, “azer”, “qwert” …) but none of them worked.

Let’s brute force that weak p12 password

So here is the interesting part. I decided to try that very famous thing called “brute force” a password. I was saying in my mind “With my years of programming experience, it should take me 10 minutes to code it and few second to run”.
But actually it took me up to one hour to make the stuff to actually work without obvious bug in C#:

The result

The app was testing 2k passwords per seconds and found the password in less than 3 minutes :) !


The conclusions are

  • don’t use a 4 letters password, obviously, especially on your p12 files which can used to act on your behalf
  • coding simple things can take more time than we expect (think hiring interview questions)
  • The method I’m using to check the password (X509Certificate2Collection.Import) throws an exception when the password is wrong. This makes the process extremelly slow (15x). When you happen to completely ignore the exception (catch(Exception) with a variable), it becomes reasonably faster if you activate the code optimization (Release mode)

That’s it, the code is on Github.  If you happen to spot obvious bugs in the enumerator of passwords, don’t hesitate to let me know with a comment.


How to create deeply nested Dynamic Controls ?

Creating controls at runtime (dynamic controls) in is both tricky and unintuitive. This article will explain a pattern to make it easier.

The main advantages of this strategy are :
– ability to create deeply nested controls with unlimited depth
– each dynamicaly created controls have normal states (Viewstate is not broken)
– you can create those controls whenever you want (including OnClick events, PreRender and Render phases)
– no hacks with postback arguments are required

[UPDATE (2011/08/01)] : “M” found that the PersistentPanel doesn’t work well when it is instantiated in a markup file (aspx/ascx/master …) so I would advice you to instanciate it via code in the CreateChildControl method. The source code in the bottom of the page have been updated to reflect that.

The online demo

To help you understand what am I talking about here is an online example of deeply nested and dynamically created controls using Asp.Net.

You can create as much nested controls as you want and test that each controls persists its state upon postbacks.

The implementation

The PersistentPanel

The PersistentPanel is just a Panel wich persists its child controls collection using the viewstate automatically. This is a key control because it recreates the dynamically created controls on each post back during the right life-cycle phase : OnLoadViewstate. Thanks to this early recreation, those controls can persist their state in the ViewState like any controls declared in the markup page during the design time.

This kind of component is quite common now a days but the particularity here is that I do not try to persits all the nested controls but only the direct children. Indeed, if you try to persist and recreate the whole hierarchy, you’ll encounter problems and will have to handle a lot of special cases. More over since event handlers are not persisted, the restored components wont work.

The implementation process of the PersitentPanel :

  • during the save process of the viewstate we save the control hierarchy (type+Id only) using a serializable entity that store the control type, its Id and and a list of children
  • during the restore process of the viewstate we refill the Controls collection using the previously saved control hierarchy

The parent of the dynamic controls

The component wich will dynamicaly create the controls will first embed a PersistentPanel. And each time it will want to add a control it will add that control in the PersistentPanel’s controls collection. Here is an example :

Combining both to build a hierarchical data editor

Now we have a persistant panel and know that dynamically created controls are persisted, we’ll create a control that would create other complexes controls wich will have the same type as their creator. This would give us a powerfull control that would be able to display or edit hierarchical data wich, in our case, is a filter expression. We’ll have
– a control to edit scalar filter
– a control to edit composite filter
The scalar filter will just contain 3 simple controls for the field name, the operator and the value. The composite filter editor will be the interesting one. Indeed, it’s gonna contains a variable number of scalar editor and other composite filter editor. So it will use a persistant panel to host those nested controls. And that’s it !


The important things to remember are that :
– a control can be created at anytime, but it must be recreated on each postback during/before the LoadViewState of its container
– the ID of the dynamic control must be the same
– event handlers are not persisted, you have to rewire them up on each postback, the PersistantPanel has the ControlRestored event wich is the best place to do so.

Download the source code

The online demo application is available here :

Have fun !

Concise C# Part 3 : C# 3 shortcuts

The version 3 of C# brings us a lot of syntactic sugar to reduce the length of our code. Here are some of them.

This post is part of a serie about making C# code shorter.

Constructors with Property initializers

Collection initializers

Var keyword

Automatic properties

Concise C# Part 2 : Try Catch and reusability

Exception handling is an important part of any software. In this post, I will talk about a trick to make but some kind of reusability on exception handling.

This post is part of a serie about making C# code shorter

When you write code, you usually try to reuse your code by creating methods and calling those methods each time you the need their functionality. When working with exceptions, it’s a bit tricky because, they don’t follow the normal code flow, they jump out of your method … unless you catch them. The consequence is that you usually have multiple similar try {} catch {} blocks that are often copied and pasted.

This is what usually happens

The solution to reuse the exception block

This is what you could do to reuse the same error handling code block in c# :