Libraries and Dependencies

  • Article

Enterprise Library will be the first instance of a new deliverable type for our team: the Block Library. A Block Library contains a bunch of application blocks that support the same scenarios and are likely to be used together. Enterprise Library is the first example of this - it is somewhat of a special library as it includes blocks that are broadly applicable across most scenarios. However we are thinking of building other scenario-specific libraries, for example a library for Smart Client applications or Service Oriented applications.

Once we have more than one library, the issue of dependency management is going to rear its ugly head. In fact it's going to hit even sooner, when customers and partners start building their own blocks that integrate with Enterprise Library. This is because all blocks have a dependency on our new Configuration Application Block (which includes our snazzy new configuration tool) and our Common assembly. Currently these are included in the Enterprise Library package. But as both Microsoft and the community start to build their own blocks and block libraries, we want to make it easy to manage this dependency, including allowing updates and versioning of the Config block.

There are a number of ways we could do this - all would work, and all have their pros and cons. These include:

  1. Make every new block or block library dependent on Enterprise Library. These blocks and libraries do not include the Configuration Application Block or Common assembly, so they will not work unless you install Enterprise Library first
  2. Include any dependencies (Config block and Common) with every new block and block library. Enterprise Library is not a prerequisite for any block or library, but it is possible that people will end up with multiple versions of the dependencies installed at once (possibly even different versions)
  3. Break out the Config block and Common out of Enterprise Library and ship them as a new "Core" library. The next version of Enterprise Library wouldn't include this core functionality. Every block and block library, including Enterprise Library, needs the core to work
  4. Same as #3, but we ship the core, as a separate MSI, with every deliverable. People can choose to install or not install the core, but they always get it zipped up with every block or library.

Which would you like to see? Can you think of any other options that may work well? Have you dealt with this issue on any of your own projects or open source projects?