Introduction

Contributions to Autofac, whether new features or bug fixes, are deeply appreciated and benefit the whole user community.

The following guidelines help ensure the smooth running of the project, and keep a consistent standard across the codebase. They are guidelines only - should you feel a need to deviate from them it is probably for a good reason - but please adhere to them as closely as possible.

Process for having a contribution included

Features

If you have an idea for an Autofac feature, the first place to suggest it is on the discussion forum. This is a Google Group accessible by email (autofac@googlegroups.com) or from the web at http://groups.google.com/group/autofac.

Providing code, either via your blog or another distribution outlet, is a great way to get feedback and support from the broader Autofac community. Consider this if it is a possibility, even if it requires core changes. Distributing a modified Autofac.dll as a proof-of-concept is encouraged.

If your suggestion applies to a broad range of users and scenarios, it will be considered for inclusion in the core Autofac assemblies. It is likely however that if your suggested feature is experimental, we'll first seek to have it added to the AutofacContrib distribution (see below.)

Mercurial vs. Patches

Regardless of whether your contribution is accepted for the main or the contrib distributions, the preferred means of integrating the code is via Mercurial rather than a patch. Google Code offers the ability to create a public 'fork' of the Autofac repository in which you can commit changes to later be pulled into the main Autofac repository.

If you plan to have ongoing input into the project, ask on the discussion list to be added to the committers list. Setting this up will permit issues from the issue tracker to be assigned to you, which is convenient when maintaining code contributions.

Dependencies

The core Autofac assemblies depend on the .NET Base Class Libraries (BCL) only. This is a conscious decision to keep the project lightweight and easier to maintain.

AutofacContrib includes assemblies that depend on other Open Source (OSS) libraries. It is important when including new dependencies that:

1. The project can be built straight out of Subversion (no additional installation needs to take place on the developer's machine)
2. Any third-party libraries have licenses compatible with Autofac's (the GPL and licenses like it are incompatible - please ask on the discussion forum if you're unsure)

Build Process

Your contribution will need to be included in the Autofac.build or Autofac.contrib build scripts. This will ensure that the output binaries get included in the appropriate zip files.

Please ensure that your changes do not break any of the other target configurations (e.g. Silverlight) - for a description of these targets see BuildingFromSource.

Autofac core treats warnings as errors, and this includes XML documentation. Please don't check in changes that give build warnings.

Continuous integration for the project runs on the CodeBetter TeamCity server. When committing changes you must check or subscribe to the CI server to ensure that your changes do not break the build.

Unit tests

Changes to Autofac core must be accompanied by unit tests (NUnit) demonstrating the impact of the change. 100% test coverage for code changes is encouraged but not mandatory.

AutofacContrib does not have this requirement, however other developers are more likely to use and maintain your contribution if it is accompanied by unit tests.

Code review

All check-ins to the Autofac source code repository are subject to review by any other project member. Please consider it a compliment that the other developers here will spend time reading your code.

Code review is a great way to share knowledge of how Autofac's internals work, and to weed out possible issues before they get into a binary. If you'd like to contribute to the project by performing code reviews, please jump right in using the code review tools accessible from the commit log.

Documentation

It is strongly encouraged that you update the Autofac wiki when making changes. If your changes impact existing features, the wiki may be updated regardless of whether a binary distribution has been made that includes the changes. A note discussing the version in which behaviour changed can be included inline in the wiki, but don't leave obsolete documentation in place - the documentation on the wiki should remain current so it's not confusing to the reader.

For new features, consider adding an end-to-end example like the AggregateService or MefIntegration pages. This will help users get up to speed and correctly use your feature. There isn't much point contributing code that no one knows how to use :)

Announcement

Feel free to announce your changes (once they're built/working/checked in) on the Autofac discussion forum. Include a link to the wiki page and/or a blog post if these apply.

You should also add your name to the list of contributors on the Contributing wiki page (this will not be done for you.)

License

By contributing to Autofac, you assert that:

1. The contribution is your own original work
2. You have the right to assign the copyright for the work (it is not owned by your employer, or you have been given copyright assignment in writing)
3. You license it under the terms applied to the rest of the Autofac project

Coding standard

Normal .NET coding guidelines apply. See the Framework Design Guidelines for suggestions. If you have access to ReSharper, code should be 'green' - that is, have no ReSharper warnings or errors with the default settings.

Autofac source code uses four spaces for indents (rather than tabs.)

Bugs and code review issues

From time to time, issues relating to the work you've done on Autofac may be assigned to you via the issue tracker. Feel free to reassign these to the project owners if you're unable to address the issue.

Bug fixes

If you've fixed a bug in Autofac, the best thing you can do is attach either a) modified source files, if the scope of the change is small, or b) a patch created using Subversion, to the Issue Tracker. If there is no existing issue to match the fix, please create one.

Every effort is made to integrate patches quickly. If it seems like your patch has been sitting in the issue tracker for a prolonged period, the reason is probably limited time resources on the part of the project team. You should feel free to email the discussion group (see above) to check on the status of such a patch - your contribution is deeply valued and you won't cause offence by seeking some feedback on it.

The AutofacContrib distribution

AutofacContrib is a companion distribution alongside the main Autofac distribution. The contrib sub-project is distinguished by:

• Experimental features
• Integrations with other Open Source projects
• Alternatives to the 'typical' way of doing something in the core (e.g. a different configuration syntax)

In many cases, AutofacContrib is a way of testing alternatives and getting visibility for new ideas that could eventually end up in the core.

If your contribution is accepted to AutofacContrib it is unlikely that the rest of the project team will have the knowledge to maintain it, so please expect to have bug reports assigned to you for the area (which you may subsequently reassign if you're unable to action them.)