A Corollary to Ockham's Razor

The popular phrasing of the maxim known as Ockham's Razor is, "the simplest solution is usually the right one."  This is not the original statement or William of Ockham.  He might better be paraphrased: "a solution with fewer assumptions is to be preferred."  That restatement, though still not precisely correct, captures the spirit but leaves out the concept of simplicity.  Karl Popper, the imminent epistemologist, would have us define simplicity as the "degree of falsifiability [sic]" of our solution; i.e., how easy is it to prove the solution incorrect?  Popper goes further:

Simple statements, if knowledge is our object, are to be prized more highly than less simple ones because they tell us more; because their empirical content is greater; and because they are better testable.

He could have well been talking about programming! If would follow that declarative programming, currying, constraint programming, and domain-specific languages are to be preferred over alternate paradigms, but so too would an entry to the obfuscated C contest and your average unreadable Perl program.  To rectify this seeming contradiction, we need to understand that a "simple statement", according to Popper, is one with fewer parameters--precisely because it is more testable.

So more testable code is better code, and we might induce that a test driven approach is to be preferred, insofar as the practice encourages the writing of simpler, more testable statements.  But, Ockham's razor is about solutions, not approaches.  So, what can we say about deciding between solutions?

I offer the Programmer's Corollary to Ockham's Razor:

To pick the best solution architecture, choose the one that consistently requires fewest number of parameters.

HOWTO: SQL Server Return Value with Enterprise Library

    int returncode = 0;
    Database db = DatabaseFactory.CreateDatabase();
    DbCommand dbCommand = db.GetStoredProcCommand("<your procedure>");
    db.AddParameter(dbCommand, "@RETURN_VALUE", DbType.Int32, ParameterDirection.ReturnValue, String.Empty, DataRowVersion.Default, null);
    db.ExecuteNonQuery(dbCommand);
    if (!Int32.TryParse(Convert.ToString(dbCommand.Parameters["@RETURN_VALUE"].Value), out returncode))
        returncode = -1;

The returncode local variable is useful, but generally not necessary. It's good to state your assumptions about the operation of external code explicitly.

Everything Crashes, But Programmers Are Still Jocular

This is completely off-topic, but I couldn't resist sharing this with anyone and everyone.  Whilst researching the frequent crashes on my iPhone, I ran across this post, and the first comment made me chuckle.

Posted by Kee Hinckley
24 July 2007 @ 4am

It appears that if the OS was unable to get a traceback for the crash (which seems to be the case in a lot of my crashes), the exception code given is: 0×8badf00d.

Could be worse. I remember one company getting a confused call from a customer about a 0xdeadbeef crash.

Dealing with Globalization Differences in Windows Versions

Recently I was charged with leading an effort to localize an ASP.NET application to a few different locales, including The Netherlands and India.  I was reminded again how difficult it is to get this right.  There are those who argue that using the same view across all the cultures supported in your application is a bad idea.  For example, an RTL culture, e.g. Hebrew, when done right, requires a mirroring of the entire view layout: not an easy thing to accomplish without changing the view.

Regardless, the .NET Framework and ASP.NET provide many facilities for localizing your application around a single view: App_LocalResources, App_GlobalResources, CultureInfo, etc.  ASP.NET has a particularly helpful feature; you can set the CultureInfo used by the application in the web.config using the globalization element.

There are lots of different ways of representing a culture in Windows: culture name, culture identifier, locale identifier (LCID), and others.  Generally, though, the culture name is used, e.g. en-US, en-GB, and es-MX for English (US), English (Great Britain), and Spanish (Mexico), respectively.  As the world's second most populous country with many ancient and highly varied cultures, India have no less than nine culture names defined in the .NET Framework.  This is, however, a narrow view of India's diversity with its 28 states, 7 union territories, and literally hundreds of spoken languages.  Obviously, there isn't 100% coverage of this diversity in the cultures supported in .NET.

One particularly useful culture name in use in Windows is en-IN.  In India, the de facto language of the law and by extension government and business is English, due to both the historical influence of British colonization and the need for a lingua franca in such an amazingly diverse country.  The en-IN culture code codifies this, making it possible for an application developer to effectively gloss over this diversity in the Indian market.  Unfortunately, en-IN is not available in the core .NET Framework release.  As you can see from this list, Windows Vista supports this culture, as does Windows 2008.

Obviously, this is problematic for developers doing development on Vista but deploying to Windows 2003 R2.  Fortunately, Microsoft developers faced with the incredible diversity of the world's cultures provided a way to customize the available cultures on any Windows installation: the CultureAndRegionInfoBuilder (CARIB) class.  There is a standard how-to create custom cultures with this class, but we will take a slightly different approach in this entry.  We will export the en-IN culture from our Windows Vista development machine, and import it on our Windows 2003 R2 server.

We'll use PowerShell here, but the examples should be clear enough that you can write your own console or Windows application to execute these steps.  Let's begin with exporting the en-IN culture.  The CARIB class is in sysglobl.dll, so we need a "reference" to that assembly. We can load the assembly from the GAC in PowerShell.  To do so we use its strong name, obtained by using "gacutil /l sysglobl" from a Visual Studio command prompt. In PowerShell on the Vista machine,

PS> [System.Reflection.Assembly]::Load("sysglobl, Version=2.0.0.0, Culture=neutral, PublicKeyToken=b03f5f7f11d50a3a, processorArchitecture=MSIL")

Now that we can reference the class, let's export the culture into an industry standard format called Locale Data Markup Language (LDML) version 1.1 using the Save method.  We can import this later with the CreateFromLdml method.

PS> $enIN = New-Object System.Globalization.CultureAndRegionInfoBuilder("en-IN", "Replacement")
PS> $enIN.LoadDataFromCultureInfo((New-Object System.Globalization.CultureInfo("en-IN")))
PS> $enIN.LoadDataFromRegionInfo((New-Object System.Globalization.RegionInfo("IN")))
PS> $enIN.Save("enIN.ldml")

Now we can copy enIN.ldml to our server and import it.  There are three very important modification we must make to enIN.ldml, however.  The en-IN culture is defined in terms of some other Windows locale information that won't be found on Windows 2003 R2, specifically "text info", "sort", and "fallback".  If you open enIN.ldml, you'll find the following three elements.

<msLocale:textInfoName type="en-IN" />
<msLocale:sortName type="en-IN" />
...
<msLocale:consoleFallbackName type="en-IN" />

If we try to load a CARIB from this file as-is, we'll receive the following error.  For more information, see the section "Exporting Operating System-Specific Cultures" in this CodeProject on-line book.

Culture name 'en-in' is not supported.

We've got to change these to a sensible alternative that is supported on Windows 2003 R2.  I chose "en-US", though "en-GB" would've also been appropriate.  For other cultures, this may prove more difficult.  My changed LDML file contains these lines.

<msLocale:textInfoName type="en-US" />
<msLocale:sortName type="en-US" />
...
<msLocale:consoleFallbackName type="en-US" />

With that done, we can load and register the culture on the Windows 2003 server.

PS> [System.Reflection.Assembly]::Load("sysglobl, Version=2.0.0.0, Culture=neutral, PublicKeyToken=b03f5f7f11d50a3a, processorArchitecture=MSIL")
PS> $enIN = [System.Globalization.CultureAndRegionInfoBuilder]::CreateFromLdml("enIN.ldml")
PS> $enIN.Register()

The culture en-IN is now available to all applications running on your server.  To see this in action, you could now augment the web.config of you web application with a globalization element:

...
<system.web>
  <globalization culture="en-IN" uiCulture="en-IN" />
...

Create a file called i18n.aspx and add the following code:

<%@ Page Language="C#"%>
<% = (10.5).ToString("c") %>

Navigate to i18n.aspx and you should see the following:

Rs. 10.50

I hope this helps!

Using ASP.NET to Write Files to a Remote UNC Share

Scenario: Let's say you have an ASP.NET site on a public web server.  The server itself is in an un-trusted domain, e.g. a workgroup server, and the site needs to write files to a UNC share that is in the domain.  There are many reasons you may need to do this, but the difficulty is that you cannot specify NetworkCredentials for the DirectoryInfo class.  You cannot, therefore, authenticate against the UNC share programmatically, and since your application is running in an un-trusted domain, the ASP.NET process identity is of no help.  If possible, the easiest thing to do is write the file locally and have the system that needs the file pull from there via a UNC.  Of course, if you're attempting to share the file across web applications, you'd likely be in the same scenario.

Solution: The solution I have developed for a slightly more complex scenario utilizes a few relatively little known facilities:.  Basically, we'll use an ASP.NET FileUpload to receive a file, write it to a temporary location, perform any needed processing, and then use the WebClient class to perform an HTTP PUT to a local virtual directory that points to an UNC share.  Let's start with the page that receives the file.

Using the FileUpload control couldn't be easier.  Add it to your page and call its SaveAs(string) method to save the file locally.  Of course, that doesn't help us get that file to a remote UNC share, does it?  What we'll do is save that file to a temporary location on the web server, do any necessary processing, and then upload that file.  Here's the code to do that.

    WebClient wc = new WebClient();
    string tempFileName = Path.GetTempFileName();
    fileUpload1.SaveAs(tempFileName);
    wc.UploadFile(uploadUrl, "PUT", tempFileName);

Let's talk about that uploadUrl variable.  You are probably already familiar with GET and POST, but you may not have had occasion to use PUT and DELETE.  When specifying PUT in an HTTP request, the request URL is the location where the request's file payload should be stored by the web server.  IIS 6 supports HTTP PUT requests via its WebDAV module, but the functionality is disabled by default.  Turn it on the same way you turn on ASP.NET, by clicking Allow after selecting WebDAV in the Web Extensions in IIS manager.  Once it's turned on, the IIS server hosting your application will now accept HTTP PUT requests.  If you do not turn on WebDAV, PUT requests will result in 405 Not Implemented being returned by IIS.

Having enabled PUT, you now need a place to put the files.  Let's create a virtual directory in our site that points at the UNC path that is our final destination.  There are three key points here.  First, we need to ensure that the new virtual directory has Write access.  Second, we need to tell IIS to connect as an account with the same username and password as an account on the machine where the UNC share exists.  Finally, we have to allow Anonymous access to the virtual directory.  If the UploadFile call returns a 401 Unauthorized, one of these three things is wrong.  The account that authenticates to the UNC share should have the necessary permissions to to the share of course, including write access.

There you have it a few lines of code and a virtual directory.  You're not likely to find a simpler solution to this problem.

BizTalk Mapper: Mapping a the Value of a Node when Present, Otherwise Nil

If you have an optional node in your source schema (e.g. minOccurs="0") who value must map to a nillable node in your destination schema, this tidy little mapper construct is for you.

It occurs to me that a cookbook containing many of these patterns would be useful to folks just getting started with the BizTalk mapper.

Calling a WCF Service from a SQL Server 2005 CLR User-Defined Function

On my current project I developed a Membership Service that consolidates all user identities into a single authority, allowing for things like enterprise single sign-on, impersonation, and centralized auditing.  Now that we're ready to convert our users over from the previous system, we need to register them all through the service interface.  Since the existing user data will be staged to a SQL Server, it was appropriate to give that import access to the service.

Enter a user-defined function.  Adding a SQL Server Project to my Membership Service solution, I quickly wrapped the call to the RegisterUser web method in a SqlFunction, i.e. a method tagged with the Microsoft.SqlServer.Server.SqlFunction attribute.  David Hayden has a good post on the steps necessary to get this right.  Here's an even more detailed discussion to get you going.   In addition to these two posts, this article covers how to impersonate the principal in calling your function; it also discusses how you can modify the proxy class to not require the UNSAFE permission set.  The SQLCLR team also has a great post on doing this.

All of these authors used wsdl.exe to generate the proxy class for the web service.  This is a fine approach, but I prefer the ease of adding a Web Service to my project.

Both approaches also used the sgen utility to generate an XML Serialization Assembly for the classes in the web service proxy that was created with wsdl.exe or adding a Web Reference.  This knowledge base article explains why this is absolutely necessary when hosting your proxy in SQLCLR.

There is an addition consideration with using wsdl.exe and/or Web Reference generated proxies against a WCF Service that uses the wsHttpBinding, highlighted here.  These proxies only support the basicHttpBinding, that is they don't support WS-Addressing as required by the wsHttpBinding.  So, if you got your sql clr function or stored procedure calling your WCF web service, but you are getting a web service timeout, check to make sure it is using a compatible binding.  You may also notice the System.ServiceModel.ActionMismatchAddressingException in the service log.

XML Schema dateTime Primer for C# Developers

The XML Schema dateTime primitive data type represents the current date and time (June 10th, 2008 at 9:30am Eastern Daylight Savings at the time of this writing) in the following format:

2008-06-10T13:30:00Z

The above format represents the UTC date/time.  UTC, or coordinated universal time, is just Greenwich Mean Time (or Zulu time, hence the "Z").  UTC is the SI name for this zero time offset.  To get the UTC date/time for your local time, simply add your time zone offset.  In Indiana, where I'm from, our GMT offset is currently -04:00 (colloquially, "four hours behind").

Here's a C# one-liner to format the current time in the XML Schema dateTime format.

string xsDateTime = System.DateTime.Now.ToUniversalTime().ToString("o");

PowerShell: Convert Unix line-ending to Windows CrLf

function GetFiles
{
  foreach ($i in $input) {
   ? -inputObject $i -filterScript { $_.GetType().Name -eq "FileInfo" }
  }
}

function ConvertToCrLf
{
  param([string] $path)
  gci $path |
  GetFiles |
  % {
    $c = gc $_.FullName
    $c | % {
             if (([regex] "`r`n$").IsMatch($_) -eq $false) {
               $_ -replace "`n", "`r`n"
             } else {
               $_
             }
           } |
        set-content $path
  }
}

SafeExecute: A Functional Pattern for Cross-cutting Exception Handling

In some cases, you may find yourself implementing the exact same exception handling logic in several methods within a class, and your brain screams DRY!  Here's way to use C# 3.0 to put that exception handling logic in one place:

        public string Foo(string name, string greeting)
        {
            return SafeExecute<string>(() =>
                {
                    return greeting + " " + name;
                });
        }

        public int Bar(int i)
        {
            return SafeExecute<int>(() =>
                {
                    return i + 1;
                });
        }


        protected T SafeExecute<T>(Func<T> funcToExecute)
        {
            try
            {
                return funcToExecute.Invoke();
            }
            catch (Exception)
            {
                throw;
            }
            //if your error handling does not throw an exception
            //return default(T);
        }

The details of proper exception handling are elided above to allow the reader to focus on the functional aspects of the pattern.  This pattern is really only useful when you are using exactly the same exception handling logic.  This is often the case in classes due to common implications of SRP.

Actually, this pattern is more generalized by the common functional pattern of wrapping the execution of another function, but this provides a useful concrete example.

Learning New Tools

I sometimes wonder which is more complex, in the information theory sense: the functioning of a given vital organ or the functioning of a modern IDE.  In the case of Emacs, I would tend to favor the the IDE.

I learned vi in college; because, truthfully, it was the default editor for elm, and I wanted to send email.  Most other folks used pine, but I didn't hear about that for a while.  Anyway, that was how it began, and I came to love vi and later vim.  This loved flowered even after I found out Bill Joy wrote it, probably because he hated Emacs.

Now, there are a few flawed attempts to bring syntax highlighting and indenting for Erlang to my favorite little editor, but they're far from perfect.  There's even an aborted attempt to bring Erlang to Eclipse.  Alas, it too is seriously flawed.  It would seem that most of the Erlang programming universe writes code in Emacs.

I've never been a joiner, and I wore my iconoclastic editor as a badge of honor.  Now, however, I've resolved to follow the pack and learn Emacs.  As a side benefit, it would appear that I'll be learning a little Lisp along the way, well elisp at least, more out of necessity than desire.

What bugs me is that I don't really want to learn Emacs, I'd rather spend that time exploring OTP. But, c'est la vie!  It will just take some time to become proficient.

At work these days I'm learning the ins-and-outs of BizTalk.  This, too, is less than ideal.  BizTalk is really powerful, very enterprise-y message-oriented middleware.  Truthfully, I wouldn't mind it so much if its development tools had any notion of refactoring.  The whole thing just seems to brittle, and could there be a more miserable way to spend ones time mapping messages types?

Getting Erlang Going on a Vanilla Ubuntu Install

Before you are able to configure and make Erlang OTP from source, you're going to need to be sure your have the right dependencies installed.  For a vanilla Ubuntu installation, this means:
sudo apt-get install libc6-dev
sudo apt-get install libncurses6-dev
sudo apt-get install m4
sudo apt-get install libssl-dev
sudo apt-get install sun-java6-jdk

The last two aren't strictly necessary, but libssl-dev is the source files the OTP system needs to utilize OpenSSL.  Now, that last dependency on the JDK may seem a bit odd, but the standard makefile for the OTP system tries to build jinterface, an OTP application that enables running an Erlang node in Java.  (As an aside, there is a similar package called twotp that does the same thing for Python.)

Assuming all goes well, you should be able to cd into the source directory (wherever it is you extracted it to when you downloaded it) and execute the following commands in order:
./configure
make
sudo make install

Depending on the permissions to /usr/local/* you may not need elevated privileges, but again this is for a vanilla install.  Now, you should be able to run Erlang.  Next time, I'll have some notes on setting up vim and Emacs for Erlang.

The ALT.NET Times for May 24th, 2008

A bit of a quiet week on the list this week.  In the U.S. this coming Monday is Memorial Day, and we get the day off--a fact that compels many to plan their vacations around it.  Whatever the reason, there wasn't much traffic, and so there's not much to report.

Probably the most interesting messages of the week revolved around ALT programming languages.  The Boo programming language--which is a full-on CLR language in the style of Python--seemed to be a favorite of many on the list.  Oren Eini is a primary contributor and uses Boo for his Windsor configuration tool, Binsor.  There's a healthy community around the language, one which created VS2008 integration for it.

There was also some discussion of F#, a language that is something like a CLR implementation of OCaml, with some changes required to behave well with the runtime and other CLR languages.  Additionally, it is missing one quintessential OCaml feature: functors.  Nevertheless, F# delivers many of the familiar mainstays of a dynamic functional language--like currying, first-class functions, pattern matching, and tuples/records--while integrating with all the .NET libraries and providing strong typing through type inference.  It also works seamlessly when installed over Visual Studio 2008.  To learn more, a good place to start would be to RTM, or Ted Neward's F# Primer.  The place where the F# community gathers is called hubFS.

So, that's the short version (or at least the thematically relevant version) of what I learned from the alt.netters this week.  Have a great one!

VMWare Blues

I suspect it's my fault.  I let Vista update to SP1 while I had the VM paused then tried resuming.  I got this BSOD while VMWare was restoring the virtual machine's state.  Since Vista now shows 4GB of RAM instead of 3.5GB after the update, I'm guessing the memory manager changed, and that caused VMWare to choke on its old memory map.

The ALT.NET Times for May 17th, 2008

They say if you do something three times, it becomes a habit.  This is the second post in a series highlighting what I gleaned from the sharp minds in the ALT.NET scene over last week.

Early in the week, Harry McIntyre from London shared his process and custom code for managing change to DBML files, the XML that defines your classes in Linq to SQL.  Folks using Linq to SQL know the pain of managing change to these files.  You cannot regenerate them from your database without wiping out any customizations that you made.  The Linq to SQL designer is pretty good about capturing most of the idiosyncrasies of your tables, but you inevitably have to customize the generated DBML to cover the corner cases, such as having a default value on a non-nullable CreatedOn column.

Harry's project is called Linq to DBML Runner, and he has a post about the process he uses.  It's dependent on a couple of other projects, including Linq to XSD and in yet another case of trickle-down technology from Ruby: Migrator.NET.  If you're committed to effectively managing change to your DBML files, and you will be if you use it on greenfield projects involving more than a couple of developers, check out Linq to DBML Runner.

There was a lot of talk about MVC and MVP, along with specializations formalized by Fowler including Passive View.  A few astute alt.netters shared some exposition on the venerable MVC pattern as it was first conceived and developed in Smalltalk.  Among these posts, Derek Greer's extensive exposition of these patterns was linked up.  This is a fantastic, thorough, and cogent examination of the patterns and the origin, highly recommended.

You can also add another implementation to your MVP list: MVC#.  This looks very interesting, but I haven't had a chance to delve into it.

Also in the rich-client/WPF world, I heard the first rumblings about Prism this week.  Glenn Block has been a frequent poster to the mailing list in the past.  He's the Technical Product Planner for the Client User Experience (UX) program in Microsoft's Patterns & Practices (PnP) team.  Glenn posted about a code drop of a Prism reference implementation.  This is essentially an application that will bake-in all the concepts that will eventually be extracted, formalized, and generalized into the Prism framework for composite applications.  This is cool stuff, and it will be good to see a lot of the disparate PnP frameworks rolled up.

One ActionScript developer (now that is ALT) asked about dealing with nested asynchronous web service calls.  Two suggestions were given: Flow-based programming and continuation passing style.  The latter is familiar, I would imagine, to most developers, at least those with some exposure to functional programming, and it is now very easy to accomplish with C# and lambda expressions.  The former, Flow-based programming, is an unfamiliar programming style to me, but at first blush it appears to fit in very well with the current interest in SOA.

Our final topic is an appropriate one to this column, namely, how do we process all the technology out there? Asked by J.P. Hamilton on the list, the most interesting response was from Oren:

I don't.  I read some interesting blogs, but I don't go into technology unless I have a need for it.  I try to keep an eye for new ideas, but technology itself is not something that I even try to keep up.  I find that knowing he fundamentals helps immensely when you learn new stuff, so focusing on that is never a bad idea.

Have a great week!

Hpricot Ruby Script to Digest ISO Currency Codes

UPDATE: I fixed a couple of bugs in this and changed the XML Schema DataType namespace alias to “xs”.  You will likely want to remove some enumeration items because they aren’t particular useful for e-commerce applications, e.g. palladium troy ounce.

require 'hpricot'
require 'open-uri'
doc = Hpricot(open("http://en.wikipedia.org/wiki/ISO_4217"))
codetable = doc.search("//table[@class='wikitable sortable']")[0]
rows = codetable.search("//tr")
for i in 1..rows.length
    tds = rows[i].search("//td")
    unless rows[i] == nil
        puts '<xs:enumeration id="' + tds[3].search("//a[@title]").inner_html.inner_html.gsub(/\s/, '_') + '"  value="' + tds[0].inner_html + '" />'
    end
end

Also, here's a Powershell script to process the ISO 3166 country code list (semi-colon delimited):

gc countrycodes.txt | ? {$_ -match ';'} | % { $s0 = $_.split(';')[0]; $s1 = $_.split(';')[1]; "<xsd:enumeration id=`"$s0`" value=`"$s1`" />" }  | out-file codes.txt

The ALT.NET Times for May 10th, 2008

This is the inaugural post of a series I propose to do over Saturday morning coffee.  I hope to cherry-pick the posts on the ALT.NET mailing list, and record here for posterity (and my feeble, fallible brain) the best information of the week.  Think of it as an ALT.NET Lazy Web distilled.

So, what did we learn this week?  Well, if you're writing, thinking about writing, or desperately need an HTML parser, you should check out Hpricot.  Incidentally, if you're not a fan of Ruby, beware!  The usage syntax of this library might make you a convert.  If you're looking for a .NET library, SgmlReader is a great place to start.

Speaking of Ruby, Dave Newman let us know about his VS plug-in for syntax highlighting of Haml.  Haml is a templating language for creating views in RoR.

A topic that frequently comes up made another appearance this week: "TDD: Where to Start?"  Ah, a fine question and one the ALT.NET crowd answers rather well.  A resounding chorus of alt.netters always seem to respond with one book title in particular: Working Effectively with Legacy Code by Michael Feathers.  Starting out with TDD is hard work, says the crowd, and starting out with TDD on a brownfield project that doesn't utilize inversion of control is considerably harder.  Another popular suggestion is to see TDD in action.

The Managed Extensibility Framework got some pixels towards the beginning of the week.  To quote Krzysztof Cwalina, contributing author of ".NET Framework Design Guidelines" and PM of the Application Framework Core team at Microsoft:

MEF is a set of features referred in the academic community and in the industry as a Naming and Activation Service (returns an object given a “name”), Dependency Injection (DI) framework, and a Structural Type System (duck typing). These technologies (and other like System.AddIn) together are intended to enable the world of what we call Open and Dynamic Applications, i.e. make it easier and cheaper to build extensible applications and extensions.

This is exciting news for .NET developers.  Incorporating these features into the BCL means we don't have to get permission from our clients and project managers to use them.  We won't have to take dependencies on Unity, Windsor, Structure Map, AutoFac, or Spring.NET to get inversion of control goodness into our applications.

One classically "ALT" exchange about distributing configuration changes mentioned some technologies with which I was unfamiliar.  ActiveMQ is a huge, mature Apache project for Message Brokering and Enterprise Integration Patterns.  Under its umbrella are projects such as the .NET Messaging API which provides a common API for interacting with messaging providers (ActiveMQ, STOMP, MSMQ, and EMS).  IKVM is, to put it succinctly, Java running on Mono.  The OP was keen on using custom WCF extensions to make distributed configuration caching with Memcached transparent.  Oren Eini posted some time ago about using Memcached with .NET, and it is definitely something you should check out, should the need for a distributed object cache arise.

That's all I have to report this week.  Have a great weekend and to quote Joe Krutulis of Appirio, "Think & Enjoy!"

Using LINQ from .NET 2.0

A few months back when I was migrating a project to VS 2008, the PM was very concerned that .NET 3.5 would cause problems on our servers, interfering with existing applications or creating new bugs in the existing codebase.  I did my best to educate my PM on the nature of .NET 3.5, that it still ran on the .NET 2.0 CLR, that it was a bunch of new libraries, that it include SDK tools that compiled the new C# 3.0 language, that it wouldn't affect existing applications.  Ever the pragmatic fellow, he insisted on late night installs and system testing, nevertheless.

Now, I don't mind pragmatism, in fact, I applaud it; however, a different situation can arise than the one I just described.  A non-technical PM or a draconian operations manager might insist that you don't "use .NET 3.5" and stick with ".NET 2.0".  If you take this at face value, it means you can't use C# 3.0, LINQ, etc.  Well, first you must get them into a Slammer worm recovery group.  Next, you can still use some .NET 3.5 goodness without having to install it on the production server.

Here's a minimalist approach: include System.Core.dll in your .NET 2.0 project.  You may already know that you can build strictly for .NET 2.0 from VS 2008, so just set the reference, set it to copy local, and roll. You'll have to convince them to let you install .NET 2.0 SP1, though.  Another thing you could try is LINQBridge, a .NET 2.0 re-implementation of LINQ to Objects along with Action<T> and Func<T>.

At the end of the day, you should probably just stay within the environment's strictures.  If you can make the case that .NET 3.5 will save time and money, you'll be much more successful in changing minds than if you just think it is cool.

Take Ownership and Full Control in Vista

Sometimes you move a bunch of files from an old machine, in a different domain, and you want to modify those files in the new environment.  Generally, the process is to take ownership of the files, then grant yourself full control.  This can be a tedious process in Windows Vista, especially in light of LUA.  So, I present here some scripting you can use from PowerShell perform this burdensome task.

First, taking ownership is still best accomplished using the "takeown" command.  You can look the command syntax up, but if you wanted to take ownership of all the files in the current directory, you can do this from your PowerShell prompt:

gci | % { takeown /f $_}

Next, you want to grant yourself full control.  This is normally done with the cacls command, but in Windows Vista this has been deprecated and you should use the icacls command.  Here's how to grant yourself full control on all the files in the current directory, replacing your current permissions:

gci | % { icacls $_.FullName /grant:r your_domain\your_username:F }

Replace your_domain and your_username above with the information appropriate to your environment.

.NET 3.5 TDD Frameworks from the ALT.NET Scene

From the ALTNET mailing list this week, I've come across to very capable frameworks for enabling true test-driven development.  Both seem to be born out of a dissatisfaction with current implementations.

First up, I'll mention MoQ; pronounced "Maw-kyoo" or just "mawk", it is written alternatively as both moq and MoQ.  The tagline from the MoQ Google code site says it is "The simplest mocking library for .NET 3.5 with deep C# 3.0 integration."  From here, we can already say that his library isn't for everyone.  Folks working on greenfield projects or converting existing projects may be able to choose .NET 3.5, but many are working in situations where lambdas and LINQ are out-of-bounds.

Those of us lucky enough to be using Func and Action in our code will find moq to be an elegant approach to unit testing interfaces.  But, other Mocking frameworks support some of the new C# syntax, so why moq? According to Daniel Cazzulino (kzu), a developer on moq and a Microsoft XML MVP,

The value we think Moq brings to the community is simplicity through a more natural programming model.

So, what does kzu mean by "natural"?  Well, traditional mocking uses a record/playback model for setting expectations in TDD, and, due to a legacy that often extends back to .NET 1.0, they have "more than one way to do it", to use an oft invoked Perl-ism and a big reason why Perl is frequently referred to as "write once, read never".  Certainly, simpler APIs are to be preferred as long as they can get the job done, and APIs tend to become simpler and more natural over time as long as they aren't required to prevent breaking changes.  So, moq was meant to be a simpler mocking framework that leverages C# 3.0 language features.  And, so it does.

If you are just getting into TDD and are a little overwhelmed by the myriad mocking frameworks out there and their unfamiliar semantics, you should definitely look into MoQ.

Now, the next item on our agenda is Total Recall.  Okay, not Total Recall, but another story by Phillip K. Dick: Autofac; in any event, we're going to take a look at the eponymous Inversion of Control container.  Autofac is an MIT licensed project that has gotten some pixel time on the ALT.NET mailing list as of late.  The community around Autofac writes on Google code that:

Autofac was designed with modern .NET features and obsessive object-orientation in mind. It will change the way you approach dependency injection in .NET.

Well, if you aren't doing DI just yet, it will certainly change the way you do it.  If you're using many of the other .NET IoC containers out there, you're probably not leveraging lambda expressions and LINQ either, so Autofac would be a change.  Like MoQ, Autofac sheds some of the legacy cruft and fully embraces .NET 3.5 as a platform.  Also note that Autofac leverages LinqBridge to remain compatible with .NET 2.0 applications.

So, will I be doing my next greenfield project using DDD with moq, Autofac, and db4o?  Well, I don't think my clients are ready for that yet.