Welcome to MSDN Blogs Sign in | Join | Help

Libraries and Dependencies

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?

Published Tuesday, January 25, 2005 10:39 AM by tomholl

Comments

Tuesday, January 25, 2005 11:14 AM by Rick

# re: Libraries and Dependencies

This is probably a dumb question, but will "Enterprise Library" work with .NET 2.0?
Tuesday, January 25, 2005 11:20 AM by Tom

# re: Libraries and Dependencies

Not a dumb question at all. This version is designed and tested only against .NET 1.1. We'll follow up with a .NET 2.0 version later in the year. However since it's all just source code, you can test and modify the code as needed to get it running on .NET 2.0 yourself.
Tuesday, January 25, 2005 11:29 AM by Nicolas

# re: Libraries and Dependencies

Hi Tom.

Probably the same ol' question yo've been having for a long time:
Is there a release date already appointed for Enterprise library?
Tuesday, January 25, 2005 11:38 AM by Adwait Ullal

# re: Libraries and Dependencies


I would go with the "core" concept and a pluggable architecture where 3rd party or in-house libraries can be "activated" by configuring them in.
Tuesday, January 25, 2005 11:56 AM by Srdjan

# re: Libraries and Dependencies

How about 5) (the IOC approach)
Lets say that all parts of the library are refectored and can be hosted by container X.
Refectoring consists of the following three changes:

1) all library blocks support interface IPlugin, so that container can recognize and load them

2) library blocks support one or more additional interfaces that expose the real functionality.
For example: library block Logger inherits from ILogger in addition to IPlugin

3) each library block also contains zero, one or more ISocketXXX interfaces.
Presence of such interfaces signifies dependencies on other library blocks; XXX is replaced by the name of the required external library functionality.
For example:
librarySecurity {
ISocketLogger logger;
...
ISocketLogger simply contains a property that holds the reference to the container hosted instance of the required library block (service)

Container starts up, loads the library blocks and hooks up dependencies by matching IXXX and ISocketXXX interfaces.

Srdjan



Tuesday, January 25, 2005 11:58 AM by Robert

# re: Libraries and Dependencies

Just MHO.
I like option 4 and option 2 sounds like something that should be avoided. Option 1 is probably not a good option because not everyone will use all of the core functionality of the Enterprise Library and may in fact have their own code that does some of what the EL is intended for. It seems wierd to have a solution that contains unused code (and/or unused referenced assemblies) and two different options for doing the "exact" same things...

Please release this. I'll take it in beta, been waiting since September ;)
Tuesday, January 25, 2005 12:03 PM by Tom

# re: Libraries and Dependencies

We're planning to release this Friday, January 28th.
Tuesday, January 25, 2005 3:08 PM by David Boschmans' Weblog

# Thoughts on Enterprise Library and its dependencies

Thoughts on Enterprise Library and its dependencies
Tuesday, January 25, 2005 1:28 PM by Joachim Roppert

# re: Libraries and Dependencies

I like option 1. Why not having EL as a installation prerequisite for all the new blocks or block libraries. It's cheap ;-), should not waste too much diskspace and if you don't need to use the other included blocks (beside common and the config block), just leave them.

Joachim Roppert
Tuesday, January 25, 2005 3:02 PM by Keith J. Farmer

# re: Libraries and Dependencies

4 seems most reasonable, although Srdjan's plugin/provider model would be worth checking into. Moreso as ASP.NET 2.0 comes along and people get used to pluggable architectures being directly supported by the framework.

There's already a significant investment in interface design and the provider model has been gaining ground rapidly. I'd vote to continue the trend and see where it leads.
Tuesday, January 25, 2005 3:52 PM by Mario Cardinal

# re: Libraries and Dependencies

I like option 4 because it recognize the fact that there are 3 categories of block Library

1. Core mechanisms which are the configuration and extensibility features included with core library
2. Aspect mechanisms which are common recurring enterprise concerns that you often waste time solving over and over again such as logging, instrumentation, exception handling, caching, security and data access
3. Architecture mechanisms which are reusable fragment of application architecture such as smart client or Service oriented framework

I think it is important to split the deployment of Enterprise library according to these three categories. Architecture block will have dependency upon Core mechanism as well as upon some Aspect libraries while Aspect block will have dependency only upon Core mechanism.
Tuesday, January 25, 2005 5:54 PM by Serge Matsevilo

# re: Libraries and Dependencies

It would probably help if all core functions that are exposed to other blocks are exposed via interfaces, which are placed into its own assemblies. This will allow us to write our own implementations of the blocks if we have to without the need to rewrite all dependent classes. This would also allow you to update blocks independently. This is similar to what Srdjan said earlier.
Tuesday, January 25, 2005 11:49 PM by Ido Samuelson

# re: Libraries and Dependencies

How about Making the application block use a plug-in application blocks. this way I will be able to even change the configuration management since all plug-ins will receieve their "context"
Friday, January 28, 2005 5:53 AM by John Hidey

# re: Libraries and Dependencies

You stated that the Library should release on the 28th of January but gotdotnet appears to be down. I see nothing out there. All my workspaces are missing, search returns nothing, going to workspaces.gotdotnet.com/entlib returns you home page. I see they had maintenance on the 25th but it is not the 28th. What is going on? If you could provide any insite into this I would appreciate it.
Friday, January 28, 2005 7:44 AM by Tom

# re: Libraries and Dependencies

We said the 28th, we didn't say what time on the 28th. Patience! :-)

Gotdotnet has been having some problems this week, as you have noticed. However the release version of Enterprise Library will be published to http://microsoft.com/practices, not gotdotnet, so it will be OK.
Friday, January 28, 2005 7:46 AM by Joren Six

# re: Libraries and Dependencies

Gotdotnet is up again. But there is still nothing to see.
Friday, January 28, 2005 8:20 AM by Tom

# re: Libraries and Dependencies

We said the 28th, we didn't say what time on the 28th. Patience! :-)

Gotdotnet has been having some problems this week, as you have noticed. However the release version of Enterprise Library will be published to http://microsoft.com/practices, not gotdotnet, so it will be OK.
New Comments to this post are disabled
 
Page view tracker