This is pretty cool – Mike Stall has posted the source code for Blue, a C# compiler written in C#. It’s not a complete implementation of the language, but it does bootstrap (it’s capable of compiling itself). I’m interested in cracking it open and taking a look at the lexer/parser implementation, and finally seeing a real-world example of Reflection.Emit…

In the mean time, check out Mike’s writeup or just go download the source yourself.

Scott lays out an interesting little idiom over here.

Basically, he’s proposing an ‘aggregated’ or ‘lifted’ version of ToString() that would render this:

Person p = new Person("Scott","Hanselman",new DateTime(1974,1,22);
string foo = p.ToString("My name is {FirstName} {LastName} and my birthday is {Birthdate:MM/dd/yyyy}");

Semantically equivalent to this:

string foo = String.Format("My name is {0} {1} and my birthday is {2:MM/dd/yyyy}",p.FirstName,p.LastName,p.BirthDate);

It’s definitely syntactic sugar, but I’ve got a notorious sweet tooth and I like it. However, I don’t think I’d do this in a class library for a couple of reasons:

·         Performance. Really the only way to implement this would be via Reflection, and reflection is slow relative to native member access. I expect a library implementation of Scott’s idiom to be about an order of magnitude slower than native member access. That amounts to expensive sugar.

·         Lack of type safety. The format string in Scott’s suggestion is coupled to the type of target object. If Person doesn’t expose a field/property called FirstName, the only way you’ll find out about it is via an exception at runtime. Furthermore, because the member names are embedded inside of opaque strings, tools like CodeSmith and Resharper can’t include them in a Rename refactoring. This could impeded productivity on large projects that make heavy use of this idiom.

I do think it’s pretty cool, though. My original thought was this could be a pretty cool language feature, implemented by compile-time code generation much the way anonymous delegates are created in C# 2.0. Thinking more about it, though, I’m not sure how you would disentangle the member references from the formatting string so as to make them visible to the compiler without reducing back to something nearly identical to the existing String.Format().

Language design is hard.

Extra! Extra! Generics CLS-compliant in Whidbey!

Peter Drayton comes bearing good news for people who like .NET 2.0 Generics – they’ll be CLS-compliant in Whidbey. This means that developers no longer have to make a choice between the power of generics and the cross-language support implied by strict CLS compliance.

It looks like the CLS rules will be amended to require all languages to support at least the consumption of generic types – you might not be able to write new generic types or methods, but you’ll at least be able to consume them. This is goodness.

A while back, Omar posted about one of my big pet peeves about Visual Studio: the fact that the “Build Clean” function doesn’t actually clean the build. Instinctively, I’d expect this to do something rational (like clean out all the intermediate build artifacts) – but no, it just sits there doing nothing.

Fast-forward to now, and he’s built a little shell extension called CleanSources that does what VS.NET purports to do, but doesn’t. From Omar’s wiki: This Application does one thing. It adds an explorer shell menu to folders that when selected will recursively delete the contents of the bin, obj and setup folders. If you have a .NET project that you wish to share with some one, this is useful to remove the unnecessary stuff from the folder before you zip it up and send it off.

+1 for Omar. Thanks, man.

Sam is so totally right – TestDriven.Net rocks. RightClick -> Test In Debugger is a godsend. That’s my favorite feature, but there are many others that make this tool worth checking out.

Jamie, you kick ass. Thanks for an awesome tool.

You’ll have to wait until the release of next week’s Community Tech Preview release to get it, though. Soma has the details here.

At least everyone can stop asking for it now J

I’m a huge fan of ArsTechnica. Through the articles he’s written, Jon Stokes has taught me a ton of stuff about low-level principles of CPU design and actually made all that CompE stuff interesting. It’s by far my favorite site for general techie-related stuff.

Anyway, I noticed that the finally unveiled their new site design today. It looks really great, but this entry in the Redesign FAQ caught my eye:

Q. Why did you change over from Linux?

A. This is a loaded question, so we'll be brief. Ars started out on Windows NT back in 1998, but shortly after that we moved to FreeBSD, and then later, Linux. We ran Linux until March of 2004, when we made the move to Windows Servers. Linux and Apache had served us quite well, but when we turned to look at building our new CMS, .NET was simply so attractive for our needs that we felt it warranted the switch. If there are enough requests, we may do an article later documenting our thought process, but for now I'll say that the decision was largely a programming one, with the added benefit of the fact that more of us support Windows in our real lives than Linux. (emphasis mine)

Glad to see more people recognizing that .NET is just a kick-butt platform to write software on.

Loading an arbitrary assembly into a design-time tool in order to do interesting things with it seems to be a somewhat common behavioral pattern for development tools. I know of several developer tools that have this general feature – Reflector is the canonical example. We have a couple of internal tools at work that do the same sort of thing. They all have to solve the problem of loading an assembly that lives outside of the application’s BaseDirectory.

Loading such an external assembly via Assembly.LoadFile() is straightforward, provided that the assembly you’re loading does not have dependencies on other assemblies that must also be loaded. If those dependencies are not easily located by CLR Assembly Loader (either by living in the GAC or running app’s probing directories), you’ll get an exception unless you do a little bit of extra work. You’d like Fusion to probe for dependencies in a “working directory” – the directory from which you’re loading the assembly, but it won’t do that automatically. Fortunately, this work is minimal but obscure.

The solution is to subscribe to the AppDomain.ResolveEvent before you attempt to load the external assembly. This gets fired by the loader just before an exception gets throw, and gives your app a last-second chance to try to find the assembly. You can then attempt to do an Assembly.LoadFile() from whatever directory you want. It’s very easy to use this event to implement a “working directory” concept. All you have to do is keep track of the directory from which you loaded the original assembly and use the ResolveEvent to probe there too.

Here’s some example of a quick-and-dirty implementation that might live on some form somewhere:

private void button1 Click(object sender, System.EventArgs e)
{
  FileDialog d = new OpenFileDialog();

  if( d.ShowDialog() == DialogResult.OK )
  {

    string fileName = d.FileName;
    this.workingDirectory = Path.GetDirectoryName( fileName );
    Assembly asm = Assembly.LoadFile( fileName );

    DoInterestingThings( asm );
  }
}

private Assembly CurrentDomain AssemblyResolve(object sender, ResolveEventArgs args)
{
   //Args.Name is the assembly’s full name (“MyAssembly,Version= [etc]”)
   //We want just the part before the comma so we can derive the filename

   string fileBase = args.Name.Split(',')[0];

   if( workingDirectory != null )

   {

     string fileName = fileBase + ".dll";
     string workingPath = Path.Combine( workingDirectory, fileName );
     return Assembly.LoadFile( workingPath );
   }

   return null;
}

And, of course, the event handler wireup:

//Somewhere in your initialization code

AppDomain.CurrentDomain.AssemblyResolve += new ResolveEventHandler(CurrentDomain AssemblyResolve);

There are still ways when this might fail, but it does handle the common cases. Of course, all the standard caveats of Assembly.LoadFile() apply – no load context and whatnot – but it works well for a dev tool.

FYI -- The Beta 1 Refresh (with Team System bits) is available for download on MSDN.

Go nuts.

I confess, I don’t do a ton of VB.NET coding. Check that – I don’t do any VB.NET coding. I’m strictly a curly-braces-and-semicolons kind of guy. However, I’m finding myself responsible for a code generator that needs to be bi-lingual between C# and VB.NET. As a result, I’m sort of forced to code VB by proxy…

Anyway, I wanted to toss out a question to the more VB-minded readers of this blog: what are the best practices around setting the RootNamespace property in the project options? On large projects, do you set this to something and omit namespace declarations from the class files, or do you leave it blank and declare namespace membership explicitly, a la C#?

Personally, the whole RootNamespace feels like pure evil to my C# mind. The thought that my class might actually not be in the namespace it declares seems nefarious at best. I can see how this would be a valuable feature to a VB6 developer who might be namespace-phobic, but I’m curious how this feature gets used on enterprise-level projects.

Diving deep into the implementation of streams in Cw has given me a new appreciation for the power of iterators.

Wes has posted some really cool stuff about how iterators can be applied to problems other than simple iteration. I haven’t quite parsed all of it yet, but his ideas are pretty interesting. Raised my eyebrows a bit, certainly.

Update: fixed the link

I’ve had some real fun tonight playing with the COmega compiler from MS Research. If you’re at all interested in programming languages and haven’t downloaded the compiler yet, you owe it to yourself to check it out. This project is much farther along than the F# compiler released last year. The MSR folks have implemented a full VS.NET language service (using the VSIP Babel API’s, I presume). You get VS.NET project support, syntax highlighting, and limited Intellisense. Plus, you get a .chm file that’s pretty extensive for a research project. Overall, the development experience is quite good.

Anyway, on to the interesting stuff. COmega has done a number of really cool things. Aside from implementing the X#/Xen stuff around XML and SQL integration, they’ve incorporated the concurrency syntax from the Polyphonic C# research effort. Polyphonic C# is a set of language-level syntactical primitives designed to make asynchronous programming easier by lifting support for various synchronization primitives out of the API and into the language itself. 

The concurrency extensions in COmega add a couple of new syntactical elements to the C# language – async’s and chords. An async is a cross between a method and a counting semaphore. Like methods, async’s can be called. However, async’s don’t declare a set of body statements – instead, they are strictly a blocking primitive that behaves similarly to a counting semaphore. Every time you “call” an asyc, you stick a message on its queue. Operations can wait on an async – if a message exists in the queue, it will be dequeued and the operation will proceed. If there are no more messages left in the async, the operation will block until one appears (just like blocking on a semaphore until it becomes signaled). Blocking on an async is accomplished through the use of chords.

A chord is a language-level representation of things that must occur simultaneously (the way a chord is composed of several simultaneous notes in music – hence the “Polyphonic” nature of Polyphonic C#). Here’s a very simple example of asyncs and chords taken from the COmega docs: 

public class Buffer 
{
   public async Put(string s);
   public string Get() & Put(string s) { return s; }
}  

Here we have a simple class that defines one async ( Put ) and one chord (Get). The “Get() & Put( string s)” construct means that anytime somebody calls Get(), the operation will block until a message appears on the Put() async. Once that happens, the body of Get() will execute. It’s interesting to note that the body of the Get() chord has access to the string passed to the Put() async, even though Get() itself is called with no parameters.

Using asyncs and chords, you can do some very interesting things. This, for example, is the equivalent of a C# lock statement: 

//The lock object
async syncRoot(); 

//Aquire the lock by waiting on syncRoot()
public DoSomthing() & syncRoot()
{
       MyThreadSafeFunc();
       //release the lock
       syncRoot();
}           

Using asyncs and chords, it’s possible to implement constructs similar to Thread.Join. The COmega has a pretty good discussion of how to do this (see the “Asynchronous Call and Return Patterns” tutorial), but it doesn’t cover anything like WaitForSingleObject() or WaitForMultipleObjects(). They’re pretty easy to do yourself, though.

Of the two, WaitForSingleObject ( a.k.a “Select” ) is the easiest to implement. Basically, you define a class to represent the Select operation. This class defines a private async member (which the WaitOne() operation will block on) and a callback delegate that external tasks can use to invoke this async when they’re done with their work. Here’s my implementation of Select: 

public class Select
{

  //Tasks will invoke this async via the CompletionCallback delegate when they’re done

  async ProcessCompleted( object result );      

  private TaskCompletionCallback completionCallback;

  public Select()
  {

     //Set up the CompletionCallback member. Tasks will invoke
     //this callback (and thus signal the ProcessCompleted async)
     //when they're done with their work.
     completionCallback = new TaskCompletionCallback( this.ProcessCompleted );
  }   

  public TaskCompletionCallback CompletionCallback
  {
    get{ return this.completionCallback; }
  }

  //The WaitOne() operation will block until the ProcessCompleted async
  //gets signaled. Effectively, it will unblock after the first task
  //completes – the other tasks will still complete, but the thread
  //waiting on WaitOne() will get unblocked once the first task is done.  

  public object WaitOne() & ProcessCompleted( object result )
  {
       Console.Out.WriteLine( "Done: " + result.ToString());
       Console.Out.WriteLine( "" );

       return result;
  }
}  

Here’s how it’s used in practice:

Random r = new Random();
Task task0 = new Task( r.Next( 10 ) );
Task task1 = new Task( r.Next( 10 ) );

Console.Out.WriteLine( "Waiting for one of two processes to finish via Select" );

Select @select   = new Select();
StringBuilder sb = new StringBuilder();

task0.Execute( sb, @select.CompletionCallback );
task1.Execute( sb, @select.CompletionCallback ); 

//This will unblock once either task0 or task1 is done,
//depending on which one completes first.

StringBuilder results = (StringBuilder) @select.WaitOne(); 

It’s possible to extend the pattern exhibited by Select into a more general WaitForN. Instead of returning once one task completes, we wait until a specified number of tasks complete. To do this, we add another async – TaskCompleted(). The handler for the async keeps track of how many outstanding taks are done, and if it reaches a threshold value it singles the completion of the whole process by posting a message to the ProcessCompleted async. Here’s my implementation of WaitForN:

public class WaitForN
{

   //This signals that all N tasks are done
   async ProcessCompleted( object result ); 

   //This signals that a single task has completed
   async TaskCompleted( object result );   

   async syncRoot();

   private TaskCompletionCallback completionCallback; 

   private int n;
   private int maxN;

   public WaitForN( int n )
   {
       this.n = 0;
       this.maxN = n;          

       completionCallback = new TaskCompletionCallback( this.TaskCompleted );
      
       //Need to prime the lock with a message, so the first call
       //to the locked statements doesn’t deadlock
       syncRoot();
    }

    public TaskCompletionCallback CompletionCallback
    {
       get{ return this.completionCallback; }
    }   

    //This blocks until ProcessCompleted fires
    public object WaitN() & ProcessCompleted( object result )
    {
       return result;
    }

    //This is a completely asynchronous chord. It gets called
    //on a new thread whenever a message gets posted to the TaskCompleted async.
    //It’s locked via syncRoot() to guarantee only one thread can be in this function
    //at a time.
    when TaskCompleted( object result ) & syncRoot()
    {
       this.n++;
       Console.Out.WriteLine( n + " tasks completed." );