Sources of Reusable Source Code

---

For too many developers, the process of creating a new application goes something like this:

1. Figure out what you’re going to build.

2. Figure out what the major components of the project are.

3. Pick one component, jump in, and start writing code.

You’ll notice I left out step 3, and that’s no accident. Before you start writing code for a new project, you should think about (and look for) all of the code that you don’t have to write. For a .NET application, that might amount to quite a bit of code. If you know where to look, there is an astonishing amount of free, reusable, high-quality .NET code out there.

The Framework and Friends

The first source of reusable code is as close as the computer where you have .NET installed: the .NET Framework Class Library (FCL). A huge amount of functionality is already packaged in the hundred or so namespaces, thousands of classes, and hundreds of thousands of members of the FCL. You’ll find the code for many common programming tasks in the FCL. Here are just a few of the many features available, together with their namespaces:

• Hashtables, queues, stacks, dictionaries, and other data structures (System.Collections)

• Event log and performance counter creation, reading, and writing (System.Diagnostics)

• Support for the COM+ services architecture (System.EnterpriseServices)

• Support for Windows Management Instrumentation (WMI) (System.Management)

• Symmetric and asymmetric cryptography (System.Security.Cryptography)

• Regular expressions (System.Text.RegularExpressions)

• Sending Simple Mail Transfer Protocol (SMTP) mail (System.Web.Mail)

• Support for Extensible Markup Language (XML), XPath, Extensible Stylesheet Language Transformations (XSLT), XML Schema Definition (XSD), and other XML standards (System.XML)

If you’ve never taken the time to sit down with the FCL documentation, you really ought to do so. I’ve seen developers waste a great deal of time writing code to perform functions that are already covered by the FCL. Not only does this take away from the time and energy you could have invested in your own custom work, but it’s unlikely that you’ll be able to test your own code under the many diverse circumstances that the FCL has been through.

For an overview of the FCL, you can start online at http://msdn.microsoft.com/library/en-us/cpref/html/cpref_start.asp. Unless you’ve got a speedy Internet connection, though, you’ll probably find it easier to browse the documentation locally; it’s installed when you install the .NET Framework Software Development Kit (SDK) or Visual Studio .NET. I recommend at least reading the top-level topic for each namespace. That will show you all of the classes in the FCL; when you can use one, with any luck you’ll remember its existence.

If you prefer written documentation, a number of books have been published that try to provide an overview of the FCL. One good reference is C# in a Nutshell, by Peter Drayton, Ben Albahari, and Ted Neward (O’Reilly, 2003).

If the FCL doesn’t contain the code that you need, check out some of the other .NET libraries that Microsoft has released. Today’s extension might well be a part of tomorrow’s Framework. Indeed, the System.Data.Odbc and System.Data.OracleClient namespaces started as downloadable extensions to version 1.0 of the FCL. Now they’re incorporated seamlessly in the 1.1 FCL.

Here are some of Microsoft’s other managed code packages:

• The Office Primary Interop Assemblies (PIAs) let you drive Microsoft Office applications from .NET code. For Office XP, you can download the PIAs from www.microsoft.com/downloads/details.aspx?FamilyId=C41BD61E-3060-4F71-A6B4-01FEBA508E52displaylang=en. For Office 2003, the PIAs are part of the retail distribution (though you’ll need to do a complete or custom installation, rather than a typical one, for them to end up on your hard drive).

• The SQLXML library (http://msdn.microsoft.com/sqlxml/) contains a great deal of add-on XML functionality for Microsoft SQL Server 2000. One of the things you’ll find here is a set of .NET classes for directly retrieving SQL Server data as XML from your .NET applications.

• The Web Services Enhancements (WSE) are a set of implementations of web services specifications such as WS-Security, WS-Routing, and WS-Referral. I expect that most of these will show up in future versions of the FCL, but for now you can download the add-on library from http://msdn.microsoft.com/webservices/building/wse/default.aspx.

In general, Microsoft is committed to .NET as its development model for the foreseeable future. As Microsoft products are released in the next several years, I expect to see most of them include their own libraries for working with .NET code.

The Microsoft Application Blocks

As I mentioned in Chapter 2, “Organizing Your Project,” Microsoft also has an increasingly active Patterns & Practices group. These people are putting out an immense amount of guidance on how to use .NET and other Microsoft products effectively in your own applications. The products of the Patterns & Practices group include a series of application blocks—libraries of reusable .NET code for common purposes. The list of application blocks will probably be longer by the time you read this book, but it currently includes these libraries:

• The Aggregation application block, for aggregating and transforming information from multiple sources (http://msdn.microsoft.com/library/en-us/dnpag/html/ServiceAgg.asp).

• The Asynchronous Invocation application block, for agent-based asynchronous processing (http://msdn.microsoft.com/library/en-us/dnpag/html/PAIBlock.asp).

• The Caching application block, for caching information in distributed applications. Note that for pure ASP.NET applications you should probably use the ASP.NET cache instead (http://msdn.microsoft.com/library/en-us/dnpag/html/CachingBlock.asp).

• The Configuration Management application block, for securely reading and writing configuration information from a variety of sources (http://msdn.microsoft.com/library/en-us/dnbda/html/cmab.asp).

• The Data Access application block, to simplify ADO.NET data access (http://msdn.microsoft.com/library/en-us/dnbda/html/daab-rm.asp).

• The Exception Management application block, which provides an extensible framework for handling exceptions (http://msdn.microsoft.com/library/en-us/dnbda/html/emab-rm.asp).

• The Logging application block, to enable distributed and asynchronous logging across an entire application (http://msdn.microsoft.com/library/en-us/dnpag/html/Logging.asp). For more details on this particular application block, see Chapter 10, “Logging Application Activity.”

• The Updater application block, which provides a “pull model” for updating desktop applications over a network (http://msdn.microsoft.com/library/en-us/dnbda/html/updater.asp).

• The User Interface Process application block, a model for writing user interface (UI) and workflow processes as a distinct layer (http://msdn.microsoft.com/library/en-us/dnbda/html/uip.asp).

TECHNOLOGY TRAP: The Iceberg of Code

After a look at the list of application blocks, you may be tempted to incorporate most or all of them in your application. If you’re writing a small utility or vertical market application, this might well be a mistake. Load in all the thousands of lines of code from the application blocks, and seven-eighths of your application will be Microsoft code, lurking beneath the visible tip of your own work. You can end up spending much of your testing time trying to figure out how all of the application blocks fit together, instead of exercising the code that you’re getting paid to write.

When thinking about the application blocks, or other bits of reusable code, you need to keep costs and benefits in mind. You could, for example, incorporate the Logging application block into just about any application. But before you do, figure out what benefits you hope to gain from a distributed, asynchronous logging framework. If you can’t think of any benefits, don’t incorporate the code. Even if you can think of benefits, you need to balance them against the costs: the time spent to read and understand the documentation for the application block and the effort required to use it from your code.

Logidex .NET Library

With all of the content available on the Patterns & Practices and Microsoft Developers’ Network (MSDN) websites, it can be hard to locate the samples that you need for a particular purpose. That’s where Logidex .NET Library (http://lab.msdn.microsoft.com/logiclibrary/logiclibrary.aspx) can come in handy. Logidex is a commercial Software Development Asset (SDA) management tool. The Logidex .NET Library is a stripped-down version that is made available for free to .NET developers. It works as a Visual Studio .NET add-in, letting you locate and download .NET patterns and sample code from within Visual Studio .NET.

To use Logidex, you start with the main Logidex Explorer window. This window connects over the Internet to the Logidex repository at MSDN (in the commercial version, you can also have local repositories). After connecting, you can go to the Search Result window to search for SDAs. Searching for assets with the string “log*,” for example, turns up 176 assets as I’m writing this. Double-clicking an asset retrieves its details to the Information window, as shown in Figure 7.8.

Figure 7.8: Information on a Logidex SDA

In the Information window, you can read about the asset, and then click over to a list of its artifacts. These might include a list of requirements, a usage guide, and sample code. You can easily download any of these artifacts to your machine to explore further, or to incorporate directly into a solution.

The final piece of Logidex is the Reference Models window. A reference model provides a sort of clickable picture of a group of assets—for example, the major Framework classes, or patterns based on tiers. Drilling into the picture with your mouse ultimately results in an asset search.

The free MSDN version is essentially a read-only subset of the full Logidex product. With the free version, you can search for SDAs, but you can’t add to the database. The full version lets you put your own SDAs into a library so that other developers can search for them and reuse them in their own projects. The capture process is well integrated with Visual Studio .NET. For example, suppose you’ve created a new .NET class library that you want to add to the SDA library for your organization. Right-click in Solution Explorer and select Capture Project to launch the Asset Creation wizard (assuming you have rights to add to the library; there’s role-based security in place). This works you through the steps of documenting your asset and then lets you edit it in depth, still within Visual Studio .NET. Logidex makes good use of the IDE, letting you link assets by drag and drop, or add them to reference models the same way.

There are other capture modes as well. If you want, you can even set up a rule-driven system that looks at check-ins to your source code control system and automatically pushes them into a library for reuse. There’s also a browser-based interface for times when you don’t have Visual Studio .NET loaded.

The full version of Logidex is out of the reach of most independent software developers. Expect to pay from $30,000 to $50,000 to set up a 10-user pilot program. But that’s no reason not to try the free version as a good way to locate sample code and patterns on MSDN.

Other Sources of Free Code

Of course, not all .NET sample code comes from Redmond. When you consider that Microsoft handed out beta copies of Visual Studio .NET to every man, woman, child, and dog with the slightest interest in programming, it would be amazing if you couldn’t find a lot of .NET source code out there. Indeed, there are dozens of websites containing freely downloadable source code. Of these, I think two in particular are worth bookmarking:

• The Code Project (www.codeproject.com/)

• GotDotNet User Samples (www.gotdotnet.com/Community/UserSamples/)

Between them, these two sites have thousands of code samples that you can search by topic or keyword. The quality is a bit uneven; this code doesn’t go through the rigorous review process that Microsoft uses internally. But you can find quite a few gems lurking here.

Tip

Google is your friend when it comes to finding source code. But there’s a trick: Don’t use “.NET” as a search term, because it’s too common in other contexts. For example, “queue .NET” turns up many hits that have nothing to do with .NET programming at all. Instead, use “C#” as a search term; “queue C#” will give you a much more focused set of results.

---