架构问题:共享相同类库的解决方案;项目推广;分叉解决方案

时间:2013-03-01 19:16:27

标签: c# visual-studio-2010 architecture

我非常需要了解如何使用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中的代码将开始更改。从现有解决方案创建新解决方案的正确方法是什么?
  4. 我知道我的问题听起来相当混乱,但问题来自于我试图在我和之前用过的C编译器/链接器循环的联合VS和C#使用模式之间进行的比较:编译代码以获取您的库然后链接到他们任何应用程序需要他们。周期。

3 个答案:

答案 0 :(得分:2)

当面临在多个解决方案之间共享代码的需求时,我倾向于将共享代码放入其自己的解决方案中,然后将其打包为nuget(请参阅here for how。)

然后,任何需要其设施的解决方案都可以引用nuget,这种解决方案具有版本化且易于同步/更新的方式(nugets can simply live in a local folder。)

答案 1 :(得分:1)

  

我想我应该创建一个新的类库解决方案,以便重用它的类

你猜对了。

  

我无法添加对其他解决方案的引用:我只能在当前解决方案中添加对程序集的引用

您只能在当前解决方案中添加对 projects 的引用。您可以添加对作为另一个解决方案的输出的构建程序集的引用。

  

如果我想从MyWinForm中提取b.dll怎么办

b.dll将独立于MyWinForm.exe进行部署 - 您无需“提取”它。

  

现在让我们说我需要分叉MyWinForm,以便我拥有MyWinFormLeft.sln和MyWinFormRight.sln; ...从现有解决方案创建新解决方案的正确方法是什么?

这取决于两个项目之间差异的严重程度。常见的非可视组件可以是共享类库中的类。常见的可视组件可以是相同或单独的类库中的用户控件。

答案 2 :(得分:1)

这与个人偏好一样重要。

您可以在多个解决方案中拥有项目。我个人认为这是等待发生的灾难,但确实有它的粉丝。我已经看到人们因此而陷入严重的混乱依赖。如果你来重构一些东西并且需要打破一些依赖关系,那么你可以在它的一端继续使用整个父解决方案。它需要一些严格的训练,但如果你分手了,你就不会意外地将自己射中脚。

你可以把所有东西放在一个解决方案中,这也是它的粉丝,并且如果我正在开发一些库同时进行+ prototye +单元测试,那么它确实可以节省很多切换。

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

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

你现在有一个超出解决方案的构建依赖性,与使用第三方dll没有什么不同。 因此,如果你想为common.dll添加另一个常用功能,你必须切换解决方案,添加它,构建它,切换解决方案(或者有两个VS的副本)

之后,这只是一个问题,你如何确定你引用的dll是你刚才构建的那个。这可以将构建路径设置为公共文件夹,也可以将构建后事件设置为将其复制到消费项目所期望的位置。如果你喜欢痛苦,你可以手动复制它......

有很多灵活性可以找到适合您需求的方式。