我应该如何引用来自另一个解决方案的程序集

自定义框架

手动复制自定义项目的输出程序集，除非可以将其源直接包含在解决方案中。

共享框架

我会随时使用nuget而不是GAC，因为你已经解决了任何版本控制问题，或者必须为框架创建一个单独的安装包（因为你是GAC）

创建一个私有的nuget服务器很容易。只需创建一个新的MVC3项目并安装nuget服务器包：http://docs.nuget.org/docs/creating-packages/hosting-your-own-nuget-feeds

将引用的程序集添加到其他项目中的库文件夹中并手动更新。如果经常更新，请考虑使用您自己的NuGet提要。

对我来说，这是一个经典的项目参考与二进制参考决策。把GAC排除在外。

在类似于您需求的拓扑结构中，我们使用以下内容：

|___$/3第三方/||__BaseFramework.dll||__CustomFramework.dll||__log4net.dll||__WPFToolkit.dll||___$/Sources/ProjectName/NormalProject.sln||||__[二进制引用]"../../3rdParty/BaseFramework.dll"||__[项目参考]||__[项目参考]||___$/Sources/Common/BaseFramework.sln||||__[项目参考]||__[项目参考]||__[项目参考]||__[项目参考]||___$/Sources/Custom/Acme/AcmeProject.sln||||__[二进制引用]"../../第三方/CustomFramework.dll"||__[项目参考]||__[项目参考]||___$/Sources/Custom/CustomFramework.sln||__【项目参考】|__【项目参考】|__【项目参考】|__【项目参考】

只有在需要时，才应通过将程序集安装到全局程序集缓存中来共享程序集。作为一般准则，除非明确要求共享程序集，否则应保持程序集依赖关系为私有，并在应用程序目录中定位程序集。此外，没有必要将程序集安装到全局程序集缓存中，以使COM互操作或非托管代码可以访问它们

由于上述原因，我将把第一个框架ddl放入GAC中。

我会将第二个框架放在TFS下的一个设计文件夹中，该文件夹由实例"Library"调用，您将在其中添加引用（您的所有团队都必须具有相同的文件夹结构以避免丢失引用）

那么#2自定义框架项目与#1是一样的，只是针对特定的客户端进行了自定义？

将自定义框架源代码作为普通框架源代码的一个分支，而不是将其作为一个实际的独立解决方案，这有意义吗？我想这将取决于差异有多大。

在我看来，将其作为分支的好处是，您应该能够更容易地合并两个分支之间的更改。想象一下，在#1中进行了错误修复或新功能，并且还需要应用于#2；如果TFS知道#2只是#1的一个分支，那么TFS应该能够让这变得更容易。

总之，为了达到你的问题，我当时的想法是，你的其他项目应该引用这些项目的输出程序集。

我会将Framework程序集复制到其他项目的解决方案文件夹下的文件夹中。我通常称我的为"依赖项"，但这并不重要。让您的项目添加对这些程序集文件的引用。我假设您的自定义框架程序集将与普通框架程序集具有相同的名称，因此您有望根据需要轻松地交换这些文件（或为使用自定义框架的项目创建单独的分支）。

我不建议将程序集放入GAC，因为如果您忘记从GAC卸载程序集的旧版本，那么在开发过程中很容易出错。