Visual Studio 中的版本控制和解决方案结构
我的系统包含三个应用程序（一个 Windows 应用程序和两个 Web 应用程序）。这些应用程序都共享两个公共程序集。因此，我总共有5个项目。过去，我为每个项目都有一个单独的解决方案。这使我能够在源代码管理中单独对每个程序集进行版本控制。但是，这会产生很大的开销，因为我必须单独打开每个解决方案，以查看对公共程序集之一所做的更改是否会破坏任何应用程序。
我考虑过转向一种结构，其中一个解决方案包含所有项目。这使我可以立即看到所做的任何更改的影响，但它会导致版本控制问题。如果我只更改通用程序集，或者只更改其中一个应用程序，则每个项目/程序集很快就会处于不同的版本级别。在源代码控制中，由于整个解决方案是在一起的，因此我没有可以在项目存储库中使用的单个版本号。
我读过的每一个讨论似乎都解决了一个或另一个问题。可以使用多个解决方案来更轻松地进行版本控制，也可以使用单个解决方案来更轻松地进行依赖性控制。
人们对构建解决方案/项目有什么建议，同时能够适当地对程序集进行版本控制？
I have a system that has three applications (one windows application and two web applications). These applications all share two assemblies in common. Therefore, I have 5 projects in total. In the past, I have had a separate solution for each project. This allowed me to version each assembly individually in source control. However, this has significant overhead because I have to open each solution separately to see if a change I made to one of the common assemblies broke any of the applications.
I have thought about moving to a structure in which one solution contains all of the projects. This allows me to immediately see the impact of any changes I make, but it leads to versioning problems. If I only change the common assembly, or only change one of the applications, each project / assembly is soon at a different version level. In source control, since the entire solution is together, I don't have a single version number to use within my project repository.
Each discussion that I have read seems to solve one problem or the other. Either multiple solutions for easier versioning or a single solution for easier dependency control.
What suggestions do people have to structure solutions / projects while being able to version the assemblies appropriately?
如果你对这篇内容有疑问，欢迎到本站社区发帖提问 参与讨论，获取更多帮助，或者扫码二维码加入 Web 技术交流群。
绑定邮箱获取回复消息
由于您还没有绑定你的真实邮箱，如果其他用户或者作者回复了您的评论，将不能在第一时间通知您！
发布评论
评论（2）
我会坚持使用多种解决方案。您的 Windows 应用程序确实不需要（也不应该）需要知道您的 Web 应用程序中发生了什么。
我使用类似的设置，其中我们有多个 Web 应用程序，并且它们之间共享公共程序集。每日（或连续，如果您的构建时间足够快）构建会很有帮助。我们使用 NAnt 和 CruiseControl，但可用的选项和意见一样丰富。
如果您采用连续构建设置，则可以在共享库构建并通过其单元测试后触发其他解决方案构建（Web 应用程序等）。您仍然需要打开其他解决方案，但构建服务器可以告诉您是否需要。
I would stick with multiple solutions. Your windows app really doesn't (and shouldn't) need to know what's going on in your web applications.
I work with a similar setup where we have multiple web apps with common assemblies shared between them. Having a daily (or continuous if your build times are fast enough) build helps greatly. We use NAnt and CruiseControl, but the available options are as plentiful as opinions.
If you go with a continuous build setup you can have the other solution builds (web apps etc) trigger after your shared libraries build and pass their unit tests. You'd still have to open the other solution but the build server can tell you if you need to.
就我个人而言，我喜欢有利于更轻松的依赖控制的解决方案。我更担心破坏性的变化，而不是拥有相同版本的项目#。
我（个人）唯一担心版本 # 的时候是当我必须排除故障或修复错误时。如果我必须修复错误，那么我最终将重新编译代码，并获得最新版本。老实说，如果有人运行的代码使用了我开发的某些共享类库的旧版本，那又怎样呢？如果它有效，我关心它是否是旧版本。存在较新版本的唯一原因可能是后来编写的某些其他应用程序需要附加功能。
当然，这是假设您遵循“您不得更改共享程序集，否则更改会破坏现有代码”。添加新功能就OK了。修改一个函数，使其内部工作方式不同，但返回相同的结果是可以的。更改功能使其适用于新软件但会破坏现有软件是不行的。那么担心版本控制就不再是问题了。
当然，这可能是因为我从来没有在一家有理由担心版本的商店工作过，所以我预计会因为这个答案而受到打击，但即使我是，我确信我我将从评论中了解为什么这是一个糟糕的答案，这就是我喜欢这个网站的原因。
Personally, I like the solution that favors easier dependency control. I'm much more worried about breaking changes than I am about having items at the same version #.
The only time I (personally) would be concerned about the version # is when I have to troubleshoot or do a bug fix. And if I have to do a bug fix, then I'm eventually going to recompile the code, and will have the most recent version. In all honesty, if there is someone out there running code that uses an older version of some shared class library I've developed, so what? If it works, what do I care if it's at an older version. It's likely the only reason there is a newer version is that some OTHER application written later needed additional functionality.
This, of course, assumes you're following the commandment "thou shalt not change shared assemblies is such a way that the change breaks existing code." Adding a new function is OK. Modifying a function so that it works differently internally, but returns the same result is OK. Changing a function so that it works for the new software but breaks existing software is NOT OK. Then worrying about versioning becomes a non-issue.
Of course, this could be because I've never worked in a shop where there is a reason for worrying about the version, so I'm expecting to be beat up for this answer, but even if I am, I'm sure I'll learn from the comments about why this is a bad answer, which is why I like this site anyway.