As an WiX extension developer I can develop an extension such that it is clear which APIs I should be using in my extension.
As a WiX developer I consider the implications of the code I am modifying such that extension developers are not inadvertently impacted.
wix.dll houses all the WiX Toolset's data access objects, extensibility interfaces and processing. The exposed programming surface area is very large and varied. It is difficult to understand what subset of objects are necessary to accomplish a task.
wix.dll also makes it easier for WiX developers to inadvertently create dependencies between objects that should remain isolated for extensibility purposes.
This proposal suggests breaking the single
wix.dll into five assemblies to layer the programmatic surface area of the WiX toolset.
- Specialized Processing - WixToolset.Core.Burn.dll & WixToolset.Core.WindowsInstaller.dll
- Common Processing - WixToolset.Core.dll
- Extensibility - WixToolset.Extensibility.dll
- Data - WixToolset.Data.dll
Objects in higher layers may access objects in lower layers but not vice versa. Similarly, objects in the same layer may not access each other. Thus the
WixToolset.Data.dll must stand alone but
WixToolset.Extensibility.dll references the data assembly. This will help WiX developers from inadvertently creating improper dependencies up the layers.
Tools, such as
wix.exe, sit above the specialized processing layer and can access objects in both of these assemblies and those below. WiX extension assemblies, such as
WixToolset.Util.wixext.dll, sit above the extensibility layer and can access objects in
WixToolset.Extensibility.dll but not
WixToolset.Core.dll (and above).
WixToolset.Data.dll should provide enough functionality to interpret the WiX toolset output file formats such as .wixobj and .wixpdb. Care must be taken to not introduce any extra dependencies.