Freigeben über

Libraries and Dependencies

  • Artikel

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?

Comments

  • Anonymous
    January 25, 2005
    This is probably a dumb question, but will "Enterprise Library" work with .NET 2.0?
  • Anonymous
    January 25, 2005
    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.
  • Anonymous
    January 25, 2005
    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?
  • Anonymous
    January 25, 2005

    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.
  • Anonymous
    January 25, 2005
    The comment has been removed
  • Anonymous
    January 25, 2005
    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 ;)
  • Anonymous
    January 25, 2005
    We're planning to release this Friday, January 28th.
  • Anonymous
    January 25, 2005
    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
  • Anonymous
    January 25, 2005
    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.
  • Anonymous
    January 25, 2005
    Thoughts on Enterprise Library and its dependencies
  • Anonymous
    January 25, 2005
    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.
  • Anonymous
    January 25, 2005
    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.
  • Anonymous
    January 25, 2005
    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"
  • Anonymous
    January 27, 2005
    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.
  • Anonymous
    January 27, 2005
    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.
  • Anonymous
    January 27, 2005
    Gotdotnet is up again. But there is still nothing to see.
  • Anonymous
    January 28, 2005
    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.