WixSharp API evolution

Historically, WixSharp implementation approach for developing support for specific WiX features involved the following steps:

1. Creating new WixSharp types that represent WIX entities.
   1. Creating new classes and enums
   2. Adding new collection member to the WixSharp.Project to store new types
   3. Adding extension methods (WixSharp.CommonTasks) for modifying WixSharp.Project new collection members
2. Extending WixSharp.Compiler with
   1. XML serialization routines for the new types.
   2. WXS generation routines for the new types serializated XML
   3. WiX compilers adjustments to accommodate the new WixSharp/WiX types
3. Composing code samples demonstrating the usage of new WixSharp types

The model above required WixSharp.Compiler being fully aware about the nature of the new feature and WixSharp types associated with it.

Despite being an obvious anti-pattern this approach had its merits as it was an adequate measure for breaking the controversial WiX/MSI authoring paradigm, which is based on MSI tables instead of deployment requirements.

However WixSharp core has matured and the majority of the new features fit the simple "convert to XML" development use-case. Meaning that in most of the cases if you want to add a new WiX feature to WixSharp you only need to perform two steps #1.a and #3. The rest will be handled by WixSharp compiler automatically.

1. Creating new WixSharp types that represent WIX entities.

   1. Creating new classes and enums
      Needs to be done by the developer. Need to create new class that implements IGenericEntity interface and mark all serializable members with the XML attribute

   2. Adding new collection member to the WixSharp.Project to store new types
      No need for development.
      WixSharp already has collections for the new types in all expected 'parent' entities- WixSharp.Project.GenericItems, WixSharp.Bundle.GenericItems, WixSharp.Dir.GenericItems and WixSharp.File.GenericItems
      

   3. Adding extension methods (WixSharp.CommonTasks) for modifying WixSharp.Project new collection members
      Not need for development. The corresponding methods already exist.

2. Extending WixSharp.Compiler with

   1. XML serialization routines for the new types.
      No need for development. Done automatically by compiler.

   2. WXS generation routines for the new types serializated XML
      No need for development. Done automatically by compiler

   3. WiX compilers adjustments to accommodate the new WixSharp/WiX types
      No need for development. Done automatically by compiler.

3. Composing code samples demonstrating the usage of new WixSharp types
   Needs to be done by the developer.

The perfect example of the streamlined development model is the EventSource class.