Customizing SF - Which Code to Not Customize?

Topics: Service Factory Modeling Edition Forum
Oct 14, 2008 at 1:03 PM
The service factory source contains many types in namespaces starting with Microsoft.Practices.ServiceFactory. Clearly, when customizing the Service Factory, we may customize those types.

However, it also contains many types that are in other Microsoft.Practices.* namespaces. This suggests that other P&P components might depend on that code as well as the Service Factory. This would be an issue where both sets of components are deployed on a single machine.

Should we not be customizing types in the other namespaces?

Alternatively, should we be renaming the namespaces of code we customize to our own namespaces? This would prevent the collisions in the first place. In that case, should we also change the names of the assemblies?
Nov 11, 2008 at 6:04 PM
If it were me, it would be my preference to not change any namespaces or assembly names because the more you change, the more opportunity there is for a new bug. You should also consider the changes you'll likely have to make to the installer. I would try to not change any (even if that meant new files would get the same namespace). I think it's okay for namespaces and assembly names to represent the originator and not the current owner. I'm sure there is a more managable method to keep track of changes you've made to the factory if that is your motivation. Hope this helps.