我有两种情况:
公司有一个框架项目,对于我们将要使用此框架的所有项目。
有一个特定于客户端的自定义框架项目,只有公司中的某些人才需要使用此DLL。
两个框架都存储在TFS上的独立解决方案中。
如何使用其他项目的引用?我应该将这两个程序集放在GAC上吗?我应该手动复制输出组件吗?推荐什么,为什么以及如何使用它?
答案 0 :(得分:6)
自定义框架
手动复制自定义项目的输出程序集,除非您可以直接在解决方案中包含它的源。
共享框架
我会随时使用nuget而不是GAC,因为你摆脱了任何版本问题或者必须为框架创建一个单独的安装包(因为你是GAC)
创建私有nuget服务器很容易。只需创建一个新的MVC3项目并安装nuget服务器包:http://docs.nuget.org/docs/creating-packages/hosting-your-own-nuget-feeds
答案 1 :(得分:5)
将引用的程序集添加到其他项目中的库文件夹并手动更新它。 如果经常更新,请考虑使用您自己的NuGet Feed。
答案 2 :(得分:4)
听起来是一个经典的项目参考与二元参考决策。将GAC排除在外。
在类似于您的要求的拓扑中,我们使用以下内容:
|___$/3rdParty/ | |__BaseFramework.dll | |__CustomFramework.dll | |__log4net.dll | |__WPFToolkit.dll | |___$/Sources/ProjectName/NormalProject.sln | | | |__[Binary Reference] "../../3rdParty/BaseFramework.dll" | |__[Project Reference] | |__[Project Reference] | |___$/Sources/Common/BaseFramework.sln | | | |__[Project Reference] | |__[Project Reference] | |__[Project Reference] | |__[Project Reference] | |___$/Sources/Custom/Acme/AcmeProject.sln | | | |__[Binary Reference] "../../../3rd-party/CustomFramework.dll" | |__[Project Reference] | |__[Project Reference] | |___$/Sources/Custom/CustomFramework.sln | |__[Project Reference] |__[Project Reference] |__[Project Reference] |__[Project Reference]
答案 3 :(得分:1)
只有在需要时,才应通过将程序集安装到全局程序集缓存中来共享程序集。作为一般准则,将程序集依赖项保持为私有,并在应用程序目录中查找程序集,除非明确要求共享程序集。此外,没有必要将程序集安装到全局程序集缓存中,以使它们可以访问COM互操作或非托管代码
由于上述原因,我会将第一个框架ddl放入GAC。
我会将第二个框架放到你的TFS下的一个设计文件夹中,由实例“Library”调用,你将在其中添加一个引用(你的所有团队必须具有相同的文件夹结构以避免错过引用)
答案 4 :(得分:1)
所以#2自定义框架项目与#1相同,但是为特定客户端定制?
将自定义框架源代码作为常规Framework源代码的一个分支,而不是将其保留为实际的单独解决方案是否有意义?我想这取决于差异有多大。
正如我所看到的,将其作为分支的优势在于您应该能够更轻松地合并两个分支之间的更改。想象一下,错误修复或新功能在#1中进行,并且还需要应用于#2;如果TFS意识到#2只是#1的一个分支,TFS应该能够使这更容易。
无论如何,为了解决你的问题,我的想法是你的其他项目应该引用这些项目的输出程序集。
我会将Framework程序集复制到其他项目的solution文件夹下的文件夹中。我一般称之为“依赖”,但这无关紧要。让您的项目添加对这些程序集文件的引用。我假设您的自定义框架程序集与普通的Framework程序集具有相同的名称,因此您可以根据需要轻松地交换这些文件(或者创建使用自定义框架的项目的单独分支)。
我不鼓励将程序集放入GAC,因为如果您忘记从GAC卸载旧版本的程序集,在开发过程中很容易绊倒。