Enterprise Library Contrib Coding Guidelines
Contributors should check back to this page often as these guidelines will most likely evolve over time, based on customer input and team discussions.
All code in this project should live under the EntLibContrib
Extensions for a specific block should go in a namespace named for the block and provider type, for example
New application blocks or tools should go in their own namespace directly under EntLibContrib
, for example:
In order to minimize dependencies between assemblies, extensions for each application block should be in their own assembly, for example:
EntLib Contrib projects should reference Microsoft signed
copies of Enterprise Library assemblies for consistency. However it should be easy for consumers of the code to recompile against unsigned or custom signed copies of the assemblies.
All contributed code should have high unit test coverage, and the unit tests should be checked into the appropriate place in the code tree.
Documentation and Samples
All submitted extensions should include basic documentation explaining the intended usage scenarios, the available configuration options (if applicable) and the API (if applicable). The documentation should be posted on this CodePlex site in the Documentation
section. Samples or QuickStarts demonstrating the use of an extension can be checked into the Samples section of the source control if appropriate.
Extensions should be checked into a source code branch appropriate for the version of Enterprise Library core code that the extension references.
- EntLib core versions 1.1 and 2.0 are no longer supported.
- EntLib v3.1 extensions should go into the EnterpriseLibraryContrib source code branch
- EntLib v4.1 extensions should go into the EntLibContrib41Src source code branch
All installable releases are prepared, tested and published by coordinators only.