Libraries and Dependencies

Tom Hollander

24 Jan 2005 7:39 PM

Comments 17

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:

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
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)
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
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?

Comments

Rick

25 Jan 2005 11:14 AM

This is probably a dumb question, but will "Enterprise Library" work with .NET 2.0?
Tom

25 Jan 2005 11:20 AM

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.
Nicolas

25 Jan 2005 11:29 AM

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?
Adwait Ullal

25 Jan 2005 11:38 AM

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.
Srdjan

25 Jan 2005 11:56 AM

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
Robert

25 Jan 2005 11:58 AM

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 ;)
Tom

25 Jan 2005 12:03 PM

We're planning to release this Friday, January 28th.
Joachim Roppert

25 Jan 2005 1:28 PM

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
Keith J. Farmer

25 Jan 2005 3:02 PM

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.
David Boschmans' Weblog

25 Jan 2005 3:08 PM

Thoughts on Enterprise Library and its dependencies
Mario Cardinal

25 Jan 2005 3:52 PM

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.
Serge Matsevilo

25 Jan 2005 5:54 PM

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.
Ido Samuelson

25 Jan 2005 11:49 PM

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"
John Hidey

28 Jan 2005 5:53 AM

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.
Tom

28 Jan 2005 7:44 AM

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.

Tom Hollander's blog

Libraries and Dependencies

Libraries and Dependencies