Refreshed

This weekend I went to the Houston ALT.NET Open Space Conference.  It was definitely a refreshing experience.  You can check the wiki to see what went on and get summaries of the sessions (not all the sessions have summaries yet).
I started to collect a list of things to read, things to listen to, and things to watch that was recommended by anyone in any of the sessions at the conference.  If you have any other recommendations for the list, please either send them to me or edit the page and add it yourself.  A lot of the entries there still need some explanation on why people should spend their time reading, listening, or watching.
I learned a whole heckuva lot over the weekend.  What I really found though was a desire to help build the developer community here in Houston.  I saw this weekend that we could have just as stimulating a conference here in Houston as in that other big Texas city up north with all the weirdos.  We need to show everyone that Houston is a great city for software developers!
Here are some quick things that I’m going to be exploring in the coming weeks (sooner than later hopefully):

• Composite Application Guidance for WPF and Silverlight (aka Prism):
• I learned that you can use Prism to build any type of application, it’s not completely tied to WPF or Silverlight.
• I’d like to see how to apply it to ASP.NET MVC or Windows Forms.
• Building complex (multiple-solution) software:
• The build is software too.
• Move away from copy/paste build scripts and towards convention based builds.
• Data Binding and Transformation:
• I’m still interested in how to do simple data binding and make it extensible.
• This is the basis for rich Windows Forms applications I think.

All in all, a great weekend.  Thank you to Ben Scheirman and his crew who organized the Houston ALT.NET Open Space Conference, and thanks to “Doc” for his expert adult supervision.  It was great seeing familiar faces and making new friends, thank you all for an awesome weekend!

Technorati Tags: altnetconf,altnethouston

Refreshing

I’m working on a personal refresh right now.  I changed the theme of this site to make it look cleaner.  I’m also signed up for the Houston ALT.NET Conference (http://houston.altnetconf.com), which is pretty exciting.  The last time I went to one of these open space conferences, it lead to a flurry of blog posts followed by a hiatus (thanks to business with school).  I’m guessing something similar will happen here.
I’ve been starting to get active on Twitter (more listening than tweeting).  My alias there is @garoyeri.  I find it to be a good way to find interesting conversations.  My Twitter client of choice (for now) is TweetDeck.  I’m going to try and post interesting links for things I’m looking at.
Code-wise, I’m thinking about a more extensible way to do object data binding for desktop applications.  For web applications, the data is refreshed once on the server-side when it hits the page, then updated by JavaScript/AJAX on the browser-side.  For something like this, AutoMapper looks like a great way to make it happen.  When dealing with desktop applications where the same data could be displayed in several places, the data binding / mapping needs to be “live” instead.  I’ll be posting more about this sooner than later.
I’ve also been looking at coding aspect of the software development process in our workgroup and have set up guidelines for our group.  I’ll write more on that too.
The StockSample I was writing about earlier got a little stale.  We’ll see if I pick that series back up or not.

Technorati Tags: personal

StockSample: Simple Binding

In Windows Forms land, it is easy to just use the existing capabilities of the Forms Designer in order to set up the bindings in the View.  It would be nice to use this functionality on the model end of things, too.  The problem, however, is that the sole purpose of the System.Windows.Forms.Binding class seems to be to bind a property to a control’s property.  What we need is a simple way to bind two properties together.
The SimpleBinding class (StockSample.Core.Framework.SimpleBinding) is based on an article from CodeProject: Understanding Simple Data Binding by Marc Clifton.  Here is the usage pattern we’re looking for:

   1:  SimpleBinding.Bind(obj1, "Property1", obj2, "Property2");

This statement will bind obj1.Property1 to obj2.Property2.  In terms of garbage collection, the Bind method will link the two objects together so that they will have the same lifetime.  In some cases, this is not desirable and we may want to look into using WeakReferences in the binding.  This makes the code more complicated, but will help in cases where we want everything coupled a lot more loosely.
This example statement, however, is not what is actually in the source code right now.  I added an extra parameter of type ISynchronizeInvoke that is called “affinity”.  This parameter can be null if you don’t care about affinity (I’ll add an extra method overload to make it look prettier later).  Affinity in this case refers to thread affinity.  This is very important when binding to UI components because if you make any calls into Windows Forms, you have to make those calls on the thread that created the handle for the controls. 
Whenever you want to make a call into the UI (or potentially make a call into the UI), you want to follow this pattern:

   1:  void DoSomething()

   2:  {

   3:      if (affinity != null && affinity.InvokeRequired)

   4:      {

   5:          affinity.BeginInvoke(new Action(DoSomething), new object[0]);

   6:          return;

   7:      }

   8:   

   9:      // action to perform...

  10:  }

You could easily substitute Action for an anonymous delegate or some other construct that makes sense.  The most important line there is line 6, if you don’t return, then you’ll end up falling through and executing the code anyway. 
Looking at the Control type, you’ll see that it implements ISynchronizeInvoke.  Once the internal handle for the control is created, you can use Control.Invoke and Control.BeginInvoke to post messages on the UI thread’s message loop to execute delegates.  Invoke will wait until the message is processed before returning.  BeginInvoke will post the message and return immediately.  Unlike calling BeginInvoke on a delegate instance, calling Control.BeginInvoke will not post anything into a thread pool, it uses the message loop.  Moreover, if the control handle hasn’t been created yet, this method will fail.  The safe bet is to find the topmost container for the control and use it as your ISynchronizeInvoke reference.  This will make it more likely that the handle has been created.  You can even call Control.CreateHandle to force the handle to be created in a more timely manner.
Now that we know why there’s a fifth parameter in the SimpleBinding.Bind method, we should discuss what the method actually does:

• Get information about the properties being bound (using reflection).
• Some properties may not have setters, some properties may not have getters.  This implicitly establishes if the binding is two-way or one-way.
• We can only bind the properties that we have access to.  If you can’t call the getter or setter from your code, then you can’t bind to it.
• Figure out how the property change is triggered.  Right now, the SimpleBinding supports three types of triggers (technically two, but I guess “no trigger” could be construed as a type of trigger… or lack thereof).
• INotifyPropertyChanged: if the object implements this interface, then the SimpleBinding will subscribe to the PropertyChanged event and use that to trigger the synchronization.
• PropertyNameChanged event: This is a pattern that is evident in Windows Forms as well as in other places.  In .NET 1.1, there was no INotifyPropertyChanged interface to implement.  If the object does not implement INotifyPropertyChanged, then the SimpleBinding will use reflection to find an accessible event named PropertyNameChanged.  For example, to look for the change in the “Text” property, we look for an event called “TextChanged”.
• No trigger: If the SimpleBinding can’t find any of the other triggers, then it just won’t bother with trying to figure out when the property changes.
• Force synchronization from obj1.property1 to obj2.property2.
• The convention is that the left property is pushed to the right.  If everything is set up ok, then these two should be synchronized.
• A more complete binding will check to see if the binding is one-way and which direction it should go before forcing synchronization.

Now we know when a property changes and which thread we need to call getters and setters on.  However, we’re missing the key part of binding, actually performing the synchronization.
In the current version of the SimpleBinding, I take the naive approach and assume that the types are the same.  This is VERY naive and is totally unrealistic, but will work for the time being.

   1:  // precondition: _prop1get != null && _prop2set != null

   2:  object value = _prop1get.Invoke(_object1, new object[0]);

   3:  _prop2set.Invoke(_object2, new object[] { value });

This code will definitely throw an exception if the property types don’t match up.  It would be totally great if there was some pattern or functionality in the .NET Framework that would help us arbitrarily convert types and add new type conversions as needed.  Luckily, such a thing exists: IConvertible.  All the basic types in .NET implement this interface and we can make the following adjustments:

   1:  object value = _prop1get.Invoke(_object1, new object[0]);

   2:  value = Convert.ChangeType(value, _prop2.PropertyType);

   3:  _prop2set.Invoke(_object2, new object[] { value });

This is a simple change (I got rid of the comment though, the precondition is the same as the code snippet above).  Convert.ChangeType will “do the right thing” or throw an exception if the cast is not valid.  If you don’t want an exception, you can add the appropriate try/catch and deal with it however you see fit.
The SimpleBinding is just that, simple.  It definitely has a lot of room for growth and extension.  I purposely made it simple and not very extensible.  If someone wanted to really make a flexible binding system, then a pipeline type approach might work.  In this way, you can insert a sequence of operations that will be performed when the binding is initialized and when the triggers are hit.  The other problem is the strong references between the two objects that are being bound.  These are not insurmountable issues and it is not SimpleBinding’s job to solve them all.  SimpleBinding is a pattern that I like to follow and it can be adapted to different situations and changed to fit the needs of the application.  I find it very useful to be able to use one line of clear code to keep two properties in sync.

Technorati Tags: C#,modelviewpresenter,winforms

StockSample: The View

This post is part of my series on the Windows Forms Model View Presenter with Data Binding sample program I wrote I call StockSample.

In the 20080818 snapshot of the StockSample program, I have a shell program (the main form) and a single view that is in a module called “StockLister”.  I’m using some of the same terminology from CAB (Composite UI Application Block).  The StockSample program doesn’t use anything other than the .NET base class library (and NUnit and DockPanel Suite).  An application such as this might be better hosted on something like CAB, or you can develop your own simpler framework that is specific to your application.  The benefit of going with an application framework that’s already developed is that (1) you don’t have to do it yourself and (2) you can more easily talk to someone else about your application.  For something that will be developed and maintained by multiple developers over time, using something like CAB might be easier to get them trained up since they can troll the Internet for documentation and starter examples.

The module and the view represent a feature (or set of features) that tell a story (or part of a story).  The view is what the user sees and interacts with.  Most applications will have at least one view for the user to interact with.  In the StockSample program, the module is called “StockLister” and its purpose is to allow the user to see all the stocks that are available, their prices, and the timestamp of the last price update.  The view interface IStockListerView is very simple:

   1:  public interface IStockListerView

   2:  {

   3:      IStockList Stocks { get; set; }

   4:  }

It accepts the interface reference to the IStockList we have in the model.  For this simple example, I made it so that the view can consume the model interface directly without modification.  In a more complex application, you may need to map the model data into the view data in different ways (this is handled by the Presenter which I will discuss in a later post).  For now, we will work with the simple example.  Notice that there is no reference to anything in WinForms or ASP.NET.  This view interface is a contract for a particular feature of the application (in this case, allowing the user to see a list of stocks with updated prices).

In the StockSample, this view is implemented as a WinForms UserControl.  Here are the steps I took to build this control:

1. In Visual Studio, create a new UserControl and call it “StockListerControl”.
2. Make the control area bigger and drop a DataGridView on it.  Set the DataGridView DockStyle to Fill.
3. Click on the “Data” menu, then click “Add New Data Source…”.
   
4. Select “Object”, click “Next”.
5. Drill down the tree (this tree is built from the classes in the project and external references) and select the “IStockList” interface.  Click “Next”.
   
6. Click “Finish”.
7. Now, click on the DataGridView, then find the “Smart Tag” in the top right (the little white box with the black chevron), click it, then click the drop-down that says “Choose Data Source”.
8. Drill down into “Other Data Sources”, “Project Data Source”, through a namespace or two, then click “IStockList”.
   
9. The grid should be pre-populated with all the properties of IStock.  Based on how I wrote the interface for IStockList, Visual Studio figured out that this is a list of IStock objects.
   
10. You can edit the grid columns to change the titles, data format, and ordering of the columns to make it look pretty.
    
11. You’ll notice a new component added to your UserControl at the bottom of the screen, I renamed it to “iStockListBindingSource” to look nicer.

Now that we have the control created, we write a little bit of code:

   1:  public partial class StockListerControl

   2:      : UserControl, IStockListerView

   3:  {

   4:      public StockListerControl()

   5:      {

   6:          InitializeComponent();

   7:      }

   8:   

   9:      StockSample.Core.Data.IStockList _stocks;

  10:   

  11:      public StockSample.Core.Data.IStockList Stocks

  12:      {

  13:          get     {  return _stocks; }

  14:          set

  15:          {

  16:              if (this.Stocks == value) return;

  17:   

  18:              _stocks = value;

  19:              iStockListBindingSource.DataSource = _stocks;

  20:          }

  21:      }

  22:  }

The only meat here is line 19.  The “iStockListBindingSource” is what was created when we added the data source to the grid.  The Forms designer already connected the grid to the binding source, now we just need to supply the data source to the binding source to feed to the grid.  Due to the way we implement the model (using BindingList<T>), we get list update events for free.

At this point, all we’d need to do to show a simple form with just this control is to drop the control on a form, create an instance of the stock list, and pass the IStockList reference to the control.  Coincidentally (or not), that is exactly what the Presenter does.

The Visual Studio Forms Designer has a lot of easy to use features for data binding.  You can perform your own experiments on object data sources in Windows Forms applications.  It makes it super easy to create a functional prototype application as well without touching a database.  At work, I took half a day to create a fairly functional data driven application and not have to write a bunch of UI code.  Most of the work was spent creating the Model layer, then throwing a UI together and wiring everything up was a snap.

Technorati Tags: C#,modelviewpresenter,winforms

StockSample: The Model's Interfaces

This post is part of my series on the Windows Forms Model View Presenter with Data Binding sample program I wrote I call StockSample.

One of the big things that is enabled by following the Model View Presenter pattern is "persistence ignorance".  For the model, I like to have POCO (Plain Old CLR Object) classes that represent the logical model that makes the most sense for the application.  This logical model might be different from the physical model if it makes the application easier to write.  Each of the model objects will also implement an interface that covers all the relevant publicly accessible properties, methods and events on the model types.  Interfaces will help with testability during development as you can create simpler test classes or use a mocking framework to create the desired test behavior.

In the current StockSample snapshot (20080818), I have one model, the Stock.  It has the following interface:

   1:  public interface IStock

   2:  {

   3:      string Name { get; }

   4:      string TickerSymbol { get; }

   5:      decimal CurrentPrice { get; }

   6:      DateTime LastUpdate { get; }

   7:  }

The Stock is special in that most of the application will not be modifying the stock information, but will be listening to changes to the stock.  I didn't make this interface inherit from INotifyPropertyChanged because the model class could use an alternative trigger for property change notifications (PropertyNameChanged events, for example).  The stock information will be populated and updated by the IStockProvider:

   1:  public interface IStockProvider

   2:  {

   3:      IStockList Stocks { get; }

   4:  }

Now that I think about it, I suppose a better name would be StockListProvider, I'll have to make those tweaks later.  The IStockList represents a collection of IStock objects:

   1:  public interface IStockList : IBindingList

   2:  {

   3:      IStock CreateNew(string tickersymbol, string name);

   4:      void Add(IStock stock);

   5:      IStock FindByTickerSymbol(string tickersymbol);

   6:      new IStock this[int index] { get; }

   7:  }

This interface has some more meat to it.  I inherit from IBindingList because I want to make sure we can bind this collection.  IBindingList is a bundle of interfaces that is necessary for binding a collection to places where a DataSet or DataView would typically go.  I'll go into more details about this later.

So, when dealing with the Model layer looking purely at the interfaces, we start with an IStockProvider.  The implementation of this is not important, all we care is that it provides is with an IStockList.  This list contains all the IStock instances that we will be able to use in our application.  The implementation of the IStockProvider will allow us to determine how we will actually get updated stock information.  The IStockList will tell us how many stocks there are and allow us to iterate on the list, and finally, the IStock will give us information on the stocks themselves.

Technorati Tags: C#,modelviewpresenter,winforms

StockSample: First Model View Presenter Sample Posted

After a long hiatus, I've created a new sample program for Windows Forms Model View Presenter pattern with data binding.  This example is not what I would call "best practices" but rather a simplification of the concepts to break it down to the most basic components.

The example is a program that is used to get stock price updates.  I wanted an example that I could do a lot of different visualizations and views / operations that just about anyone can understand.  I know that Glenn Block posted on the Composite UI WPF guidelines here (http://blogs.msdn.com/gblock/archive/2008/07/03/composite-application-guidance-is-live.aspx) and they also have a stock trading reference application.  The goal of my sample is to show a very simple example of Model View Presenter with Windows Forms and data binding.  There is no Inversion of Control container, no database, and no extra frills.  The sample is done in Visual Studio 2008 Express Edition (which is all you need to build / run it).  The only external libraries that are referenced are NUnit (http://www.nunit.org) and Weifen Luo's DockPanel Suite (http://sourceforge.net/projects/dockpanelsuite/).

You can get the source from my google code project here, see this link for instructions on checking out code from my repository (http://code.google.com/p/garoyeriazarian/source/checkout).  The code is in the StockSample/tags/Snapshot20080818 folder.  I'll be updating the trunk periodically with extra functionality.  There are some tests... I'm still trying to get the hang of Test Driven Development.

I'll have a series of posts following talking about parts of the sample and as I build more onto it, I'll talk about those and link to the new snapshots.  You can then use your favorite Subversion client to see what exactly is different.  If you have any specific requests on things you want to see, let me know and I'll try to work it into the sample.

Technorati Tags: C#,modelviewpresenter,winforms

Model View Presenter Data Binding Part 2: The Model

In my Model-View-Presenter application, the Model is fairly simple, but can be extended to be more complicated (I guess that's really true for just about anything). I won't go into details on persistence, I'm going to concentrate on how I do the data binding. For the Model, I follow the same pattern for properties that I did on the View:

int _nThingy;
public int Thingy
{
   get
   {
       return _nThingy;
   }
   set
   {
       bool bChanged = (this.Thingy != value);
       _nThingy = value;
       if (bChanged) FireDataChanged("Thingy");
   }
}

The FireDataChanged(string) method will fire a PropertyChanged event for the specified property. When I'm working with collections, I create a class that inherits from BindingListBase (my custom .NET 1.1 class that implements IBindingList) or from System.ComponentModel.BindingList (when using .NET 2.0). Both IBindingList implementations will look for changes to each of the elements in the list and translate them to ListChanged events. This will make life really easy when binding to grids and lists. Oh yea, I almost forgot, there's one more piece that needs to be in place. The data object needs to implement IEditableObject. The MSDN documentation has an example on how to implement it. While this is deceptively simple, it does have some interesting consequences. Now, I can make changes to properties (with sheer impunity) and I can notify everyone else of all the changes that happen on the data objects. Here's an example: I have a program that lets the user define a set of tubular equipment that is laid end to end. Each piece of equipment has the following properties: Inner Diameter, Outer Diameter, Top Depth, Bottom Depth, Length. For the sake of simplicity, lets say they are all integers. For each equipment, Bottom Depth = Top Depth + Length. The equipment has to enforce this rule all the time. Also, when making adjustments, it should favor keeping the Length property constant. Here's how the properties end up looking:

public int TopDepth
{
   get { return _nTopDepth; }
   set
   {
       bool bChanged = (this.TopDepth != value);
       _nTopDepth = value;
       if (bChanged)
       {
           this.BottomDepth = this.TopDepth + this.Length;
           FireDataChanged("TopDepth");
       }
   }
}

public int BottomDepth
{
   get { return _nBottomDepth; }
   set
   {
       bool bChanged = (this.BottomDepth != value);
       _nBottomDepth = value;
       if (bChanged)
       {
           this.Length = this.BottomDepth - this.TopDepth;
           FireDataChanged("BottomDepth");
       }
   }
}

public int Length
{
   get { return _nLength; }
   set
   {
       bool bChanged = (this.Length != value);
       _nLength = value;
       if (bChanged)
       {
           this.BottomLength = this.TopDepth + this.Length;
           FireDataChanged("Length");
       }
   }
}

If I set any of these three properties, the others will be synced up until the system stabilizes. Also, setting any one property will not only make adjustments to another property, it will fire both notifications automatically. This is OK for a single piece of equipment, but we need to have some more interaction between the equipment. When the BottomDepth of a piece of equipment changes, the next equipment's TopDepth needs to change. When the TopDepth of a piece of equipment changes, the previous equipment's BottomDepth needs to change. To make this work, we hook into the ListChanged event on the BindingList and look at the ListChangedEventArgs.PropertyDescriptor property. If the change was BottomDepth or TopDepth, we make a change to the appropriate item. We have to take care of all the different types of ListChanged events: ItemAdded, ItemChanged, ItemDeleted, ItemMoved, and Reset. In each case, we make sure the adjacent TopDepth/BottomDepth pairs match up on the changed equipment. Once all the pieces are in place, I just need to create a list, add some items to it, then set the DataSource property of a DataGridView, sit back, and watch the magic. If you edit the TopDepth, Length, or BottomDepth columns, then the model will make the adjustments and the DataGridView will be automatically updated. Also, you can assign the same list instance to another DataGridView, then the two grids will be synchronized automagically. This is the basis for the Model layer of the Model View Presenter architecture. Using these techniques, we can bind any collection of data fearlessly to any UI component as well as binding properties with each other.

ALT.NET Conference Sessions: Architecture

I rummaged Technorati and looks like a lot of people already put up their summaries / impressions of the sessions at the ALT.NET Conference in Austin, TX. Here's some more about some of the sessions that I'm not seeing much discussion about: Architecture (Trends and Observations) The architecture chat started off a little sparse, but fattened up nicely fairly quickly. Aaron Armstrong was driving the conversation to see what people were seeing in architectures. There were a lot of familiar terms on the whiteboard (I can't really remember them all, did anyone write this down?) I stood up and talked about the Model-View-Presenter architecture of the WinForms application I'm working on at work (picture 1, picture 2). I have a post about it that I'm planning to turn into a series of posts with some code and stuff. There was some interest in the data binding work I was doing, too. I'll talk more about that later. The main point that I was trying to make was that you can have multiple Models that don't know anything about the Views and are tied together using the Presenters. You can have multiple Models aggregated (in whole or partially) into one or more Views. Aaron asked how someone would handle the scenario where you have a composite View in a WinForms application. The approach I would use would be to expose the different sub-Views on the composite View as properties and use an Inversion of Control framework to tie it all together. In the application I'm working on, I'm using Spring.NET to tie everything together (coincidentally, Mark Pollack was in the back of the room). My property data binding would then keep everything in sync. The conversation then moved to more distributed architectures and web-related systems. There was some mention of the technique of using commodity hardware and/or software to create cheaply replaceable systems. On a similar note, Amazon released a white paper (papers?) on "Dynamo", their network architecture. It is designed with the simple fact that hardware will fail and needs to be easily (and cheaply) replaceable. We also talked about Service-Oriented Architecture and what to do about data. Some people feel compelled to integrate all the databases and data sources into one unified database. This leads to some friction as the different functions of the system move forward. When the data stores are properly separated, then the needs of the different applications (or services) can be met without affecting other applications (or services) that may be using the same data store. Everyone agreed that the database should not be used as an integration tool. Someone (I forget who) also explained the idea of thinking of the data flowing through the distributed system as a "document" instead of just messages going back and forth. We also talked a little about how to have a good architecture while still doing agile development. Agile development is against "Big Design Up Front", but sometimes you will need to have a vision and an architecture to scale properly. The main idea is to keep the architecture simple at first, get the project working, then make refinements as needed. Don't optimize too early, otherwise you may end up debugging strange issues that would not have risen from a simpler design. Also, you can more easily optimize when you start from a simple design and you can do small steps at a time to keep the system stable as you try to improve performance. That's all I can remember off the top of my head. I'm sure others will fill in the gaps and make corrections. All in all, it was a very interesting talk. Software Architecture is one of the subjects that I am very interested in and I found it very invigorating to hear from others and their thoughts on architecture. altnetconf

ALT.NET Conference Sessions: DSL

I rummaged Technorati and looks like a lot of people already put up their summaries / impressions of the sessions at the ALT.NET Conference in Austin, TX. Here's some more about some of the sessions that I'm not seeing much discussion about: Domain-Specific Languages for Business Users / Developers The DSL talk started off a little rough (the organizer wasn't there), but Arafat Mohamed stepped up and started the conversation. Just about everyone in the room was there to learn about DSLs and were not really using them in their projects. We talked about what we thought a DSL really was. It seems that just about anything can be a DSL (depending on how specific you are to what domain). According to Martin Fowler, "a domain-specific language is a veneer over an API" (I think that's the verbage he used). He differentiates between an internal DSL (one that is consumed by developers) versus an external DSL (one that is consumed by the users). Martin Fowler has some more information on his website. There is also some information on Wikipedia. One of the primary applications for DSLs that I can think of is a business rules engine. For example, you have a cell phone provider who has complex billing semantics and wants to be able to add new rules easily. There are a lot of concerns with this, however. Developers may not want the analysts modifying the behavior of the system as they may not be as disciplined. On the flip side, managers want the analysts to do the work to keep the developer freed up. It is a delicate balance that can only really be helped by properly training the analysts so that they know the proper practices. You can also avoid problems by creating the proper tooling. Going to the more practical side... Scott Guthrie pointed out that IL had some pragmas that could be used to give the debugger hints on what the original source file was and what line of that source file corresponds to the generated code. He said that they used this mechanism for debugging the generated code from XAML, XOML and the other declarative constructs. You could also use Boo as a meta-language to construct your DSL. In theory, Visual Studio should be able to debug Boo since Boo compiled to IL and _should_ have the line numbers and source file information embedded in the PDB files. (in theory). Boo is also the source of Boobs (the build system with an oral fixation) and Binsor. Oren (Ayende) has a lot of posts regarding Boo. Also, if you want good IDE support for Boo, look at SharpDevelop. If you need to develop your own language from scratch, Antlr seems to be the way to go. The people in the room who had used it said it was better than the old-school lexx / yacc approach. There are a lot of concerns though in creating a DSL in that you would have to maintain it and train everyone how to use it. This reminds me of two things: 1) Wasabi, the language created by Joel Spolsky for FogBugz (linky) 2) The MUMPS System (linky) In both cases, developers will basically have a bunch of work that they can't really put on their resume because their expertise is in an in-house language. A DSL may create the same sort of situation. Also, whoever develops the DSL will be the authority on it and if he/she decides to leave the company without properly documenting it, the DSL will be useless. At the end of the session, I think everyone got a good feel for the positives and negatives of creating and using domain-specific languages. I learned that I would need to think long and hard before considering implementing a DSL and that there are a lot of solutions (Boo, Ruby, scripting) that would require a lot less work up front and would provide fellow developers with some take-aways. Another summary on the DSL session: David Woods altnetconf