c# - 建筑问题: solutions sharing same class libraries; project promotion; forking solutions

Question

我非常需要了解如何使用 Visual Studio 2010 在 c# 中管理一些非常基本的体系结构问题，而且我在教科书和网站上寻找解决方案时遇到了一些困难。假设我有一个 MyWinForm.sln 解决方案，它基于:MyWinForm.cs 和两个类库，比方说:a.dll、b.dll 我的目标:我想重构我编写的应用程序，以便按顺序学习 C#拥有一个体面的应用程序架构。

1. 我希望设计一个必须包含通用方法的 c.dll，以便在不同的应用程序中重用它:MyWinForm 和比方说 yawfs.sln(又一个 Windows 窗体解决方案)，这样我就可以从两个解决方案中创建对 c.dll 的引用。我想我应该创建一个新的类库解决方案 以便重用它的类。但是，据我所知，我无法添加对不同解决方案的引用:我只能添加对当前解决方案中的程序集(当前解决方案中的不同项目)或 .Net 程序集的引用。我应该使用导航面板来选择 a.dll 程序集以添加对它的引用吗？也许有一种方法可以将现有程序集包含到当前解决方案中，使其与相应解决方案中执行的更改保持同步？不明白。

2. 如果我想从 MyWinForm 中提取 b.dll 以达到与 c.dll 相同的目的，该怎么办？如何将其作为新解决方案进行推广？

3. 现在假设我需要派生 MyWinForm 以便我将拥有 MyWinFormLeft.sln 和 MyWinFormRight.sln；两者都将以不同于共同共享代码的方式发展。他们将使用(并共享)完全相同的 a.dll 和 b.dll 程序集(相同版本)，但 MyWinForm.cs 中的代码将开始更改。从现有解决方案创建新解决方案的正确方法是什么？

我知道我的问题听起来很困惑，但问题来自于我尝试在 VS 和 C# 联合使用模式与我之前使用的 C 编译器/链接器周期之间进行的比较:编译代码以获取你的库然后链接到它们，无论应用程序需要它们。期间。

Answer 1

这与个人喜好一样重要。

您可以在多个解决方案中拥有一个项目。我个人认为这是等待发生的灾难，但它确实有它的粉丝。我已经看到人们对此产生了严重的依赖性。如果您开始重构事物并需要打破某些依赖关系，您可以拉动它的一端，然后将整个父解决方案放在膝上。它需要一些严格的纪律，但如果你把事情搞砸了，你就不能那样不小心搬起石头砸自己的脚。

你可以把所有东西都放在一个解决方案中，它也有它的粉丝，老实说，如果我同时开发许多库 + 原型(prototype) + 单元测试，它确实节省了很多转换。

我认为你说你想去的方式以及我们倾向于这样做的方式。

首先，您可以添加对从其他解决方案中的项目构建的 dll 的引用只需进入添加引用，其中一个选项卡是浏览，选择文件夹，选择 dll。

事情是你现在有一个构建依赖性在你的解决方案之外，与使用第 3 方 dll 没有什么不同。所以如果你想在common.dll中添加另一个常用功能，你必须切换解决方案，添加它，构建它，切换解决方案(或者有两个VS走)

之后就是如何确保您引用的 dll 是您刚刚构建的 dll 的问题。这可以将构建路径设置为公共(public)文件夹，或者将构建后事件复制到使用项目期望的位置。如果你喜欢痛苦，你可以手动复制它......

在找到适合您需求的方式时，有很多灵 active 。