Regular expressions provide a powerful means to harness the capabilities of text. Deeply ingrained in the heart of .NET is a vast and powerful regular expression toolkit found in the System.Text.RegularExpressions namespace. This is a well-known fact. Many developers, myself included have been using them for years and years because they provide unparallelled control over interpreting, parsing, extracting, replacing, and manipulating strings.
I'm not going to bore anyone by further explaining the benefits of regular expressions nor will I go into explaining how they are constructed and how they work. Every single developer, IMHO, should have on his desk the fantastic book “Mastering Regular Expressions” by Jeffrey Friedl. It is a MUST read. It's a MUST read many times. I absolutely love it. Alright, enough evangelism.
When creating regular expressions in .NET you have the opportunity to establish how the regular expression will be used to process your text by a RegexOptions enumeration. By default, the regular expressions that you create are interpreted and evaluated at runtime. There is nothing particularly wrong with that. If your regex is used infrequently then that can be perfectly adequate. However, suppose your regular expression needs to be utilized much more frequently. It is quite possible that your application's performance may begin to degrade because of such frequent interpretation of the regex.
One of the RegexOptions enumeration values is Compiled. When you apply the Compiled option to the regular expression you are telling the .NET runtime that you don't want the regex interpreted, but rather that you want it to be compiled. Ultimately, this will usually have the benefit of being more efficient. However, there is a cost. The compilation happens at runtime. When the execution path hit the regex flagged for compilation the .NET runtime will dynamically generate an assembly, load it, and execute it. So there's an initial hit.
This might be fine and dandy...but it's going to happen once for every compiled regular expression. In other words, if you have 25 compiled regular expressions in your code, you'll end up with 25 dynamically generated DLLs in memory. That doesn't sound good to me.
The wonderful thing is you can take this hit up front entirely and generate a single assembly that contains as many pre-compiled regular expressions as you desire. This is accomplished through code - there's no built-in IDE support. The added benefit of a pre-compiled regex assembly is that you can fine tune your regular expressions out-of-band with your application. You don't have to recompile your application(s) to get the updated regular expressions. Instead, you reference your regex library and you have access to them.
This magic is accomplished via the Regex.CompileToAssembly() method.
Over the past couple of days I created a little application that I call the “Regular Expression Assembly Builder”. This tool provides you with the ability to gather your regular expressions, organize them, and ultimately compile them into a DLL. Essentially, with this tool you can:
- Open and edit existing assemblies containing regular expressions (via Reflection).
- Create brand new assemblies.
- Organize your regular expressions into hierarchical namespaces.
- Strongly name (even Delay Sign) your resulting assembly with a key file.
- Apply several attributes to your target assembly.
- ...and much more
Here are a few screen shots of the application in action:
The application plus source can be downloaded directly here or from the link on the main blog page.
Enjoy!
NOTE: I didn't know a tool like this existed already, but when I was just about done with the project I stumbled upon a similar, yet distinct, project that you might also be interested in. It looks like Brian Delahunty took the initiative to create this well before I did. Good job!