正如其他人所说的,只需在解决方案资源管理器中右键单击解决方案,选择添加>现有项目,然后浏览到常用项目.csproj文件,并将其从原始位置包含在解决方案中。
有两个问题但它可能会或可能不会是一个问题,这取决于你的团队规模:
1 - 常见的项目将包括在具有相对路径的每个解决方案,该解决方案文件(IE:... \ CommonProject \ Common.csproj)。这意味着所有开发人员必须具有相同的工作文件结构,否则当他们尝试打开主项目时会出错。
2 - 在该方案中有共同的项目是由多个项目引用(说两句 - A和B)和开发项目的工作必须作出修改,以共同的项目作为自己的任务的一部分。开发人员无法知道他们所做的更改是否会破坏项目B,而不会实际检出项目B并编译它。随着越来越多的项目引用共同项目,这种情况的风险会增加到难以管理的程度。
同样,其他的都表示,没有“正确”的方式做到这一点,但是我采取的方法如下:
1 - 使用持续集成,如巡航控制管理建设项目,并将通用项目作为独立项目放在服务器上。
2 - 创建您的源代码控制到房子下的目录内置常见的DLL。在构建机器上签出此目录,并且每当公共项目生成时,它将输出DLL复制到DLL文件夹中,并将这些更改提交到源代码管理。
3 - 所有开发人员的机器和构建服务器来控制公共DLL文件夹的位置和DLL的使用变量,而不是硬编码路径参考使用环境变量。 (IE:而不是C:\ Source \ MyCommonProjectDLLS \ Common.dll使用$(MyCommonLocation)\ Common.dll并将变量MyCommonLocation设置为C:\ Source \ MyCommonProjectDLLS)
4 - 对于任何引用常见的DLL,在生成服务器上为该项目设置一个CI触发器来观察常见的DLL文件夹。无论何时对其进行更改,构建服务器都应该构建所有正在使用的项目。
这立即让你知道,如果你犯下任何其他项目的重大更改。唯一的缺点是,在这个模型中,消耗项目一旦产生就会迫使更新通用DLL。另一种方法是从源代码管理版本生成Common DLL时对其进行版本化,并将每个版本放在常用DLL文件夹下的其自己的子目录中。所以,你最终会得到:
常见的DLL
-1.0.0.1234
-1.0.0.1235
-1.0.0.1236
等。这样做的好处是,每个项目都可以通过简单地引用新版本的代码来选择何时更新公共DLL。然而,这样做会削弱两种方式,因为这可能意味着某些项目的旧版本的通用代码会比他们应该做的时间更长,这可能会在最终引入这些更改时增加所涉及的工作。
希望这会有所帮助。
你的意思是像Visual Studio中的“添加文件作为链接”选项? http://support.microsoft.com/kb/306234(编辑:这是假设你根本不想使用共享项目?) –
只需在解决方案中包含不同的项目并添加一个引用该项目,而不是编译的.dll。我们的源代码库有一个包含共享代码的文件夹(主要是类库项目),我们在树的完全不同的区域引用来自解决方案的那些项目。难点在于弄清楚如何在源代码控制中安排代码,以便为您的团队做出这样的直觉。 (并且没有“正确”的方法来实现它,你如何设置它取决于很多因素,它可能需要一些时间才能正确地规划出来。) – David
http://msdn.microsoft.com/en-us /library/1xhzskbe.aspx – 2012-12-28 14:24:01