Así # 2 el proyecto de marco personalizado es lo mismo que # 1, pero personalizado para un cliente en particular?
¿Tendría sentido hacer que el código fuente del Framework personalizado sea una rama del código fuente normal del Framework, en lugar de mantenerlo como una solución real separada? Supongo que dependerá de cuán extensas sean las diferencias.
Como yo lo veo, la ventaja de convertirlo en una sucursal es que usted debería poder fusionar más fácilmente los cambios entre las dos ramas. Imagine que se ha corregido un error o una nueva característica en el n. ° 1 y también se debe aplicar al n. ° 2; TFS debería poder hacer esto más fácil, siempre que TFS sepa que # 2 es solo una rama de # 1.
De todos modos, para llegar al punto de su pregunta, mi pensamiento es que sus otros proyectos deben hacer referencia a los conjuntos de salida de estos proyectos.
Copiaría los ensamblados de Framework en una carpeta debajo de la carpeta de la solución de sus otros proyectos. Generalmente llamo a la mía "Dependencias", pero realmente no importa. Haga que sus proyectos agreguen una referencia a esos archivos de ensamblaje. Supongo que sus ensamblajes de Framework personalizados tendrán el mismo nombre que los ensamblajes de Framework normales, por lo que puede fácilmente intercambiar esos archivos según sea necesario (o crear ramas separadas de sus proyectos que usen el Framework personalizado).
No recomendaría poner los ensambles en el GAC, porque es fácil tropezarse durante el desarrollo si olvida desinstalar una versión anterior del ensamblaje del GAC.
Si bien esto puede no ser valioso para su situación, si estuviera utilizando la subversión, svn: externos habría sido una solución bastante simple de esta situación. – Candide