Managing loosely coupled assembly references incurred through usage of the 'Designer' attribute

We build a lot of components, WinForms, Workflow activities etc, and something that we use a lot is the 'Designer' attribute. The general practice during initial development is, the Designer attribute is used with the [Designer(typeof(DesignerType))] style to get things working - then later, this is converted to [Designer("AssemblyQualifiedTypeName")], which allows the designer DLL to be removed from the component's reference list - this removes the need f开发者_如何学JAVAor the component consumer to have to deploy the designer DLL with their product. This practice of splitting the design-time, and run-time code into two seperate DLLs is common practice, and one that I am a proponent of.

A negative side effect, is the 'assembly qualified type name' will include the assembly version of the designer dll, so when the version is incremented, one must perform a 'search and replace' across the product to ensure they have updated all the 'loose references' to this designer.

Finally, my question: Can anyone reccomend a best practice that doesnt rely on 'search and replace', which can manage all these references, to ensure they are always up to date? We often get a lazy developer forgetting to update the reference string, resulting in a new version of the component linking to the previous version of the designer DLL - which of course doesnt get deployed, so design-time support is lost. Perhaps some form of pragmas, macros, build script, magic attributes, I dont know, but there must be a better way of doing this.

Anyone? (thanks)

---

Why not create a single designer that uses something like the Managed Addin Framework or Activator.CreateInstance internally to pick and show a designer? With this technique, the Designer attribute would never have to change...

---

Do it like Microsoft does. Take a look at AssemblyRef class (System.Windows.Forms.dll) in Reflector.