2012-12-28 156 views
6

这可能是之前发布的,但我不确定要查找哪些搜索条件!Visual Studio:如何管理项目之间共享的代码

快速说明。

我有几个项目之间共享的代码。此代码本身仍在进行中。问题是,无论什么时候我需要更新这段代码,我不想再做3次,这将成为一场噩梦。

有没有办法将它添加到项目中,没有将其复制到项目文件夹? 即我想要共享类被挂到我的3个项目,

C:\代码库\ sharedclass.cs NOT \ eachproject \ BIN \ sharedclass.cs

我一定要创建它,因为它是自己的图书馆项目?如果编译器可以将它编译为“外部”代码,那将会好得多。

干杯。

+0

你的意思是像Visual Studio中的“添加文件作为链接”选项? http://support.microsoft.com/kb/306234(编辑:这是假设你根本不想使用共享项目?) –

+1

只需在解决方案中包含不同的项目并添加一个引用该项目,而不是编译的.dll。我们的源代码库有一个包含共享代码的文件夹(主要是类库项目),我们在树的完全不同的区域引用来自解决方案的那些项目。难点在于弄清楚如何在源代码控制中安排代码,以便为您的团队做出这样的直觉。 (并且没有“正确”的方法来实现它,你如何设置它取决于很多因素,它可能需要一些时间才能正确地规划出来。) – David

+0

http://msdn.microsoft.com/en-us /library/1xhzskbe.aspx – 2012-12-28 14:24:01

回答

-1

这是更好地共同的部分提取到一个单独的项目库,并添加到所有的解决方案/依赖项目该项目的参考。

否则,您可以Add code/file/item as Link

+0

添加为链接在此特定实例中效果最佳。 –

+2

链接已损坏。 – benderto

5

是的。

您可以从任何地方您的硬盘驱动器上添加了一个项目,一个解决方案。因此,将共享代码放入类库中并将其添加到您的三个项目中。

+0

这也是我如何做的东西。我有一个通用工具库,其中包含我在几乎任何代码部分中使用的很多有用的东西,所以我将该项目添加到我正在处理的其他任何项目中。当您在那里修改代码时,将在使用此项目的任何其他应用程序中对其进行修改。当你需要发布的时候,有时候从DLL中获取工作并将其保存为“正确的版本”是一个好主意,因为有时当你在其他程序中工作一段时间时,可能会破坏事情的运行方式并因此而中断旧节目。如果你保持DLL的发布,它使事情变得更简单。 – Joe

2

微软一直支持它已内置到VS现在的一个开源项目,其所谓的NuGet,可以输出共享项目作为的NuGet文件,并使用它在你的其他项目。

它实际上将部署所有你在构建包指定的文件。

这就是.Net现在如何支持依赖关系。你会注意到,即使像EF这样的东西来自NuGet包。你甚至可以在MyGet.org这样的地方免费托管它,我使用它并且工作得很好。

http://nuget.org/

0

是,把需要在一个单独的类库项目中共享,构建它,并引用此创建的DLL建设成为你的其他项目的代码。

6

正如其他人所说的,只需在解决方案资源管理器中右键单击解决方案,选择添加>现有项目,然后浏览到常用项目.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。然而,这样做会削弱两种方式,因为这可能意味着某些项目的旧版本的通用代码会比他们应该做的时间更长,这可能会在最终引入这些更改时增加所涉及的工作。

希望这会有所帮助。

+0

感谢提示,我遇到了上述问题,您的回答非常有帮助! – QtRoS

0

我用git submodules实现这一目标。

  1. 为您想在解决方案之间共享的每个模块(项目)创建一个新的git存储库。我通常还在单独的项目中包含该项目的单元测试,但在同一个git存储库中。
  2. submodule添加到将使用共享代码的解决方案的git存储库中。添加子模块会创建指向外部存储库特定提交的链接。当子模块中的代码更新时,您将能够将更新提供给您的父解决方案,这与更新对子模块提交的引用基本相同。我发现使用像SourceTree这样的应用程序,该过程更容易可视化。
  3. 添加子模块并拖动最新提交将在父解决方案文件夹内创建共享项目的副本。通过右键单击解决方案并选择“添加现有项目”,将项目导入父级Visual Studio解决方案。
  4. 通过右键单击项目并选择“添加引用”并在“解决方案”选项卡中查找共享项目,在其他项目中添加对共享项目的引用。

既然共享项目包含在解决方案中,您将能够将更改推送到子模块,并将这些更改自动合并到解决方案中。您还将能够看到引用该子模块的其他git存储库中的更改。

相关问题