Amiralles's Blog

In the previous post I showed you how to implement conditional format functionality for datagridviews using C#, working on conditions that we already know at compile time, which means that those conditions will be written by programmers, not end users. In this post I’ll show you how to deal with user defined conditional formats, which is a more useful thing to do if what you want to provide this kind of functionality. With this new feature the users are going to be able to write conditions in an Excel fashion (formula like, if you will) To implement this feature I’ve upgraded the project that we been using for this series to .NET Framework 4.5 in order to use the latest version of the Roslyn compiler. The Roslyn compiler is the backbone of this feature. If you are interested in Roslyn, I made a series on How to build a DSL on top of Roslyn  that covers some basic stuff of this great piece of software. As in the Roslyn DSL series I'll rely on source to source translati...

Why Source to source translation? In order to answer that question, I wanna provide some background on what are the choices that we have when building a DSL on .NET (at least the most common that I’ve used). Prior to the “magic lambda” era, there were few choices, the one I've used the most, was a hand written parser that creates syntax trees and a code generator that traverses those trees generating MSIL code using Reflection.Emit. This solution was OK but it was also a lot of work, even for a simple "Hello World DSL". It’s definitely a path I wouldn't take nowadays. When .NET 3.5 saw the light, we had more options, back then it was possible to use linq expressions to represent our programs and traverse those expressions in order to emit target code. It wasn’t  the easyest thing, but at least the days were we have to build a bunch of classes to represent or compose expressions were gone. Then we had the lambda compiler and linq statements which allowed ...

An effective way to create a DSL is by building a thin layer that runs on top of a façade that interacts with the domain objects. This is how those components looks in the sample app of this post. In this case, the DSL only talk to the façade and the façade is in charge of talking with domains objects (or services or whatever component that goes underneath). This makes things really easy to implement and fit perfectly to work with Roslyn, because if we use the façade as the Roslyn script engine’s host object, the engine will let us access directly from our DSL syntax to any member of the façade's public API. By looking at this unit test you will see how to wire up the components, execute the DSL script and modify the order state (the domain object) right from the DSL. * If this were a real app, the order will continue with the processing pipeline. So far so good, now how to go from our DSL syntax to façade calls? * Notice that the facade exposes the ...

In this post I will be reviewing some considerations that I usually have in mind while designing a DSL. The audience When you are working on a DSL, the first and most important thing to have in mind is the audience you are aiming for. It’s gonna be technical people, business executives, sales people, etc…, etc…. The syntax If the audience is not a bunch of techies, here is set of design rules that you should follow (at least, they've worked out for me): The syntax should be as much as closest to the domain terms that the user uses on a daily basis. Use sentences like “ when something_happen :” instead of “ if (somethingHappen){..} ”. Use logical operators like “ and ”, “ or ” instead of “ && ”, “ || ”. Don't make your syntax case sensitive. snake_case works better than PascalCase. When syntax error happen (and it will happen) provide useful messages that lead the user to the right path. Try to avoid the use of parentheses as much as you can. (our...

Lately, a lot of people where asking on mailing lists and users groups, how to dynamically load and execute C# code. This code maybe be stored as expressions in the database or will be entered by the user in some sort editor or whatever they want to use, but the important thing is that the app should compile and execute the code at runtime. Unlike Ruby or Python, C# does not support this kind of stuff right out of the box. Fortunately, the Redmond guys had implemented a nice library called Roslyn, which allows us to do this and a lot of other crazy stuff. Whereas this was possible in the past by using reflection or the CodeDomProvider, it were a lot of work (complex and error prone work), so, very few people did it. In this post I’m going to show a little app that uses Roslyn to compile and execute C# code at runtime . Instead of work with expressions like 2+2 or a>b (a.k.a. the classic “hello world!” example), I’ll work with something more close to a DSL. This DSL w...