Visual Studio中的版本控制和解决方案结构

我会坚持使用多种解决方案。你的Windows应用程序真的不需要(也不应该)知道你的Web应用程序中发生了什么。

我使用一个类似的设置,其中我们有多个Web应用程序,它们之间共享公共程序集。每天(或者如果你的构建时间足够快的话持续)构建会有很大帮助。我们使用Nant和CruiseControl,但可用的选项和意见一样丰富。

如果使用连续构建设置,则可以在共享库构建并通过单元测试后触发其他解决方案构建(Web应用程序等)。您仍然需要打开另一个解决方案,但是构建服务器可以告诉您是否需要。

就我个人而言,我喜欢更容易控制依赖关系的解决方案。我更担心的是破坏变化,而不是在同一版本中拥有物品。

我(个人)唯一关心版本的时间是我必须进行故障排除或修复错误。如果我必须修复bug,那么我最终将重新编译代码,并将得到最新的版本。老实说,如果有人在运行使用我开发的某个共享类库的旧版本的代码,那又是什么呢?如果它能用,如果是旧版本我该怎么办?可能是因为其他一些稍后编写的应用程序需要额外的功能。

当然,这假定您遵循“不应更改共享程序集”的戒律,这样更改会破坏现有代码。“添加一个新函数是可以的。修改一个函数,使它在内部的工作方式不同,但返回相同的结果是可以的。更改一个函数,使其适用于新软件,但破坏现有软件是不好的。那么,对版本控制的担忧就变成了一个没有问题的问题。

当然,这可能是因为我从来没有在一家商店工作过,那里有理由担心版本,所以我希望这个答案会受到惩罚,但即使是这样,我相信我会从评论中了解到为什么这个答案不好,这也是我喜欢这个网站的原因。