It's standard practice for developers to group and compile common functions into a single component (e.g., a DLL) that different applications can share and reuse. The Windows .NET Framework itself can be thought of as a large library of reusable components. Our compression wrapper is also a great candidate for reusability—either on its own or as part of a set of custom file utilities.
In Visual Studio 2005 (VS), you can reuse a component by adding a reference to a project. You just right-click a project and select the Add Reference menu command. Potential references can be built-in .NET components, third-party and custom .NET components, and even legacy COM components. SQL Server projects, however, are much more restrictive in the references that you can leverage: Only .NET assemblies that have already been created in SQL Server 2005 can be added as a reference. Furthermore, in terms of built-in .NET functionality, only a few assemblies (e.g., System, System.Data, System.Security, System.Transactions, System.Web.Services, System.XML) have been “pre-created.” If you try to create an assembly in SQL Server 2005 that references another built-in .NET assembly (e.g., System.Windows.Forms.dll), you'll receive an error message.
This doesn't mean you can't create and reference your own custom .NET assemblies in SQL Server projects. But it does mean that your custom assemblies are limited to a subset of the .NET Framework. These restrictions require you to carefully consider and plan both the deployment order and .NET logic you want to take advantage of.