Let's integrate our DSL compiler into the build process

This is the second article in "Capture business requirements with the Boo-based DSL" series. We are just getting started on the series and will talk about simple way of integrating our DSL compiler into the build process of Visual Studio. This approach would simplify learning custom DSLs and could save some head-ache for anyone, who does not want to bother with on-the-fly compilation in the very beginning.

Normally any DSL scripts implemented via Boo could be used in two distinct ways:

• Scripts that are distributed in the raw form and get compiled into .NET at run-time.
• Scripts that get compiled into .NET within the main build and are distributed as assemblies.

First approach is more suitable for large and complex solutions. that could require on-the-fly configuration without recompiling the solution. For example, by editing files manually or automatically getting the update from the central update server (file monitoring could be established to recompile the files once the change is detected).

Advantages of this approach are obvious; disadvantages are:

• We have to deal with possible memory leaks here (scripts get compiled to in-memory assemblies and loaded into the AppDomain without any option of unloading).
• Although there is Rhino.Dsl (micro-framework that helps to tame the Boo compiler), the complexity of logic being introduced to the system could be too much for the task (unnecessary complexity of the solution drops the efficiency of any future development and maintenance).
• DSL scripts in this situation should be 100% issue-free, since it would be a nightmare to debug them.

Second approach is more suitable for small solutions that are easy to deploy and do not need real-time flexibility. It could also be used to develop and debug the actual scripts before deploying them to the real-time system.

One of the simplest ways to implement that is:

• Put *.boo scripts into the same project that defines base classes, custom compiler steps, meta attributes and other customizations that compose the DSL.

• Add post-build steps to the project file:

• Invoke boo compiler with custom pipeline to generate compiled DSL .NET assembly

• The previous step could be enough, but we can take it a little bit further - additionally use ILMerge to merge the DSL assembly back into the base assembly.

Here's the sample snippet that can do this:

<Import Project="..\Resource\Build\Boo.Microsoft.Build.targets" />
<PropertyGroup>
  <ILMerge>..\Resource\Build\Ilmerge.exe</ILMerge>
  <BooAssembly>$(IntermediateOutputPath)_boo_$(TargetFileName)</BooAssembly>
  <CoreAssembly>$(IntermediateOutputPath)$(TargetFileName)</CoreAssembly>
</PropertyGroup>
<Target Name="AfterBuild">
  <Booc ToolPath="..\Resource\Boo\" 
    Verbosity="Verbose" 
    SourceDirectory="$(MSBuildProjectDirectory)" 
    TargetType="Library" 
    OutputAssembly="$(BooFilePath)" 
    References="@(MainAssembly)" 
    Pipeline="Request.Core.MyPipeline, Request.Core" 
  />
  <Exec Command="$(ILMerge) 
    /out:&quot;@(MainAssembly)&quot; 
    &quot;$(CoreAssembly)&quot; 
    &quot;$(BooAssembly)&quot;" 
  />
</Target>

NB: "Exec Command" xml node should be on one line, I've wrapped it here for the readability.

Boo.Microsoft.Build.targets is just an MSBuild file that hooks to the Boo.Microsoft.Build.Tasks.dll from the BooLangStudio distribution. It just have following statements:

  <UsingTask
    TaskName="Boo.Microsoft.Build.Tasks.Booc"
    AssemblyFile="Boo.Microsoft.Build.Tasks.dll"/>

  <UsingTask
    TaskName="Boo.Microsoft.Build.Tasks.ExecBoo"
    AssemblyFile="Boo.Microsoft.Build.Tasks.dll"/>

Some notes about the approach:

• Boo scripts are compiled right in the main build process (it means "Ctrl+Shift+B" for the VS users and seamless support by the continuous integration)

• Failures and warnings of your own compiler pipeline get out into the same "Error List"

• Double-clicking on any compiler error will get you to the script

• FXCop, NDepend or any other assembly-based analysis on the integration server will pick up the DSL code automatically
• Later you will be able to re-use your Boo compiler customizations and DSL scripts in on-the-fly compilation.

PS: as always, check out the series page for all the links, referenced projects and updates.

Some more new ReSharper 4.0 features

Here are some other "minor" features (support for the new C# syntax and Linq being the major feature for me) that I really like in the new ReSharper 4.0:

• New capital letter completion in R# (i.e.: typing CCM in R# Type Navigaton instantly brings you ClientCoreModule). This type of completion still feels a bit weird but it just works for me.
• Solution-wide analysis (like background compilation in VB)
• Support for custom file headers (adding and updating all these copyrights)
• R# code annotations for the BCL (although I still haven't tried to annotate my own classes). I can see Spec# type of functionality probably coming out of this in the future.

BTW, letter auto-completion works in Launchy as well. For example: typing MVS will bring Microsoft Visual Studio.

Hardware upgrades for the efficient development

Over the weekend I've upgraded my development machine to Intel Core 2 Quad Q6700 (4 cores x 2.66GHz) from Core 2 Duo (2 cores x 2.4 Ghz that were usually running at 2.6-3.0 GHz).

Coupled with Windows Server 2008 64bit being used as a workstation, I can now have more Visual Studio instances and virtual machines running in parallel without affecting the performance. And the Resharper is lightning fast on any development solution.

That's the point of any upgrade.

PS: it was really nice of Windows to start up without any problems (this could be a bug) after the processor change, automatically detect new processor, install the drivers and suggest to reboot.

Checking out Microsoft Project Server 2007

Just finished playing with the Microsoft Project Server 2007 (or MSPS for short).

MSPS is server-side addition for the Microsoft Project that provides functionality for the centralized project storage, publications, global resource pool management etc. Additionally there is web access for it that provides lightweight readonly interface to the project data, allows to view assignments and schedule changes. And also, due to integration with the Share Point technology, there is the ability to manage project-related documents, risks, issues etc.

MSPS 2007 (compared to its 2003 predecessor) can be considered a major breakthrough. Complete installation and configuration of the old version used to take away a couple of days (every technology piece starting from the DB and up to MSP templates on the SharePoint had to be separately configured and managed) and you were still unsure if everything will be holding together after the next rain.

In MSPS 2007 you just have to get ASP.NET, .NET 3.0 and then pick "Basic" install. The system will install and configure everything for the basic usage (SQL Express, Share Point Server, Project Server, Web Access for it, etc) in less than half an hour. It feels like magic.

I doubt that the Project Server will be used for my development projects, since single MSP 2007 is more than enough for now. But knowing that the usable potential for project portfolio management is there - just feels good. Additionally, there is Microsoft Team System (something that I still have to check out), that supposedly integrates nicely with the MSPS.

PS: this version of Project Server is implemented with .NET and ASP.NET (PSI is the good old WS), so hacking extending it should be much easier for the developers out there (old version had huge amount of some ugly ActiveX and ASP).

Launchy - Open Source Keystroke Launcher for Windows

In this post I'm just kicking out one item from my "to do list".

Being a developer means that you tend to stick to your keyboard instead of wasting time to reach for the mouse and do some movements. That's why learning R# shortcuts could yield an immense productivity boost in your .NET projects. Same principle applies to the other areas outside your IDE as well.

Launchy (aka "Open Source Keystroke Launcher for Windows") is just like your {Ctrl}+{N} Resharper shortcut for your Windows Operating System. And it is also extensible, skinnable and works. I've used HiddenMenu and PStart before, but this tool is way more efficient.

BTW, do you know, that you can type something like *Report in R# type search and it will work?

Minor code readability

Here's minor thing that just made the code feel a little better:

using (var inputStream = _inputFile.PostedFile.InputStream)
using (var stream = _fileStore.Create(tempInfo))
{
  inputStream.PumpTo(stream, <span style="color:green;">128.Kb()</span>);
}

128.Kb() is more friendly to the eye than 1024*128

Using Windows Server 2008 64 bit as a development workstation

As you may already know, it is a common trend for some developers to use Windows Server 2008 for the development environment. I've done the same thing a couple of months ago (picking 64 bit version).

Here are some advantages of this:

• Performance is a bit better than in Vista (and it is more stable as any server has to be)
• It is said that 64 bit support here is better than in the previous OSes (64 bit support allows you to use more than 3GBs of RAM and utilize you Intel Core 2 processors more efficiently)
• Some trojans and viruses will have hard time running under 64 bit.
• It forces you to get familiar with the new technologies and concepts by Microsoft (I did skip Vista)
• It is free for 240 days

Update. Although, Windows Server and Windows Vista share the same codebase, there are yet diffs in the configuration (that's not just about running services) that give some edge to Server 2008 in the overall performance. Here are some links:

• XP vs Vista vs sp1 vs 2008 vs 32 vs 64 benchmarked (also check out this image)
• Vista SP1 vs Server 2008 as a desktop OS: more comparisons

Disadvantages:

• Although 32 bit programs run under 64 bit, you've still got to go hunting for 64 bit versions of the software in order to achieve native performance (64 is yet to become mainstream within 2-4 years)
• I'm yet to find how to hide this folder navigation pane in the Explorer.
• Avast Antivirus considers Windows 2008 to be Windows NT at fails the installation

On the overall the ride with Windows Server 2008 64 bit has been a smooth ride. Visual studio, .NET and development-related tools just work.

So if your development job is either about staying on the edge or about constant learning, it may be worth switching there.

Notes:

• Disable windows shutdown tracker either through the gpedit.msc or via the registry
• Optimize the program performance: System Properties | Advanced | Performance | Advanced - pick "Programs"
• Turn on the desktop experience component: Administrative Tools | Server Management | Features - Desktop Experience
• You can turn on all the beauty of the Vista UI (I keep it off)
• Enable SuperPrefetch (+ make sure that the "Super Prefetch" service is enabled)
• Enable audio service: Services.msc - switch "Windows Audio" to Automatic
• Rearm the activation timer (Microsoft allows to do that only 3 times): slmgr.vbs -rearm
• Although Windows Virtual PC just works, you can install Hyper-V

PS: I have 3 distinct (as in Separation of Concerns) workstations for my software projects. One is the primary development platform (it has been highlighted above). Second one is virtual development server. Third one is laptop for information management, that has recently been migrated towards more productive (and a bit Linuxy and Gmaily) approach.