我的解决方案中有一个“类库”，我的“ WebService ”正在使用它。此网站服务由外部客户端使用。 （我现在有2个项目在我的解决方案下）
最近，类库有一些增强功能。我想在这个库上实现Versioning（不太清楚如何做到这一点。）。
假设我当前的“类库v1 ”应该仍然有效，因为我们的一些使用“ Web服务”的客户仍然需要“类库v1 “实施。但对于少数新客户，我的“ Web服务”应该实现“ Class Library v2 ”逻辑。
我开始复制我的“ Class Library v1 ”并在我的解决方案“ Class Library v2 ”中创建新项目，并在我的“ Web服务< / strong>“基于请求来源的项目。 （我现在在我的解决方案下有3个项目）
出于某种原因，我觉得这是非常业余的实施方式。任何人都可以指导我做正确的版本库版本并适当地调用它们。
答案 0 :(得分：2)
通常这是使用版本控制分支实现的。
有一个主分支，它代表最新的代码（以及独立于产品版本或里程碑而发展的分支）。
如果要发布新版本或修订版，第一步是使用版本标记标记源代码管理版本项。例如：＆＃34;我的产品2.2＆＃34;。
此外，如果整个产品版本或修订版本将与新版本并行维护，则需要创建版本/修订版分支，因此特定的修补程序，修复程序或功能将是在那里实现而不影响新版本或旧版本。如果要在不同分支中共享功能，则需要合并整个changset。这个问题的主要问题是有时旧版本的代码库不支持合并，但您需要为特定版本再次开发修复程序...
可能会发生子，子，子子分支。例如，您可能有2.x分支，以及2.1.x，2.2.x的子分支......这完全取决于您如何处理版本控制和产品发布。
每个分支都是不同的Visual Studio解决方案。你不应该在同一个解决方案中混合卫星库。使用特定的代码文件版本在他们自己的解决方案中单独管理它们。
在一天结束时，您将所有代码分支放在单独的源代码管理存储库中，并且您单独开发每个版本，然后合并更改（或实现特定版本的更改）。
现在您需要选择一个源控件提供程序。您有很多选择：
源代码管理提供商的比较超出了本Q＆amp; A的范围，并且它非常注重意见，这不符合StackOverflow惯例，但是您可以自行查看他们中的一些甚至可以找到其他人！
在为您的消费者提供多个版本的Web服务提供服务方面，您可能需要考虑一个基本URI包含Web服务版本的URI方案：
/api/v1/resourceA /api/v2/resourceA /api/v2.2/resourceA [...]我更有兴趣知道你给出的答案的最后部分 Web服务API的示例网址。让我们说我保持不同的结局 对于所有客户，诸如v1，v2和v2之类的点，现在我的困惑是 当请求来自v1 URL和V2 url时，我应该调用我的单个 类库或两个不同的类库。
正如我在上面的答案中所指出的，您需要单独维护解决方案的每个版本，并且您需要将每个版本部署为不同的IIS应用程序。
也许您需要稍微学习 WebDeploy 来轻松部署解决方案。
如果您使用一个解决方案和v1，v2，v3类库方法，您将来会遇到很多问题，因为您将修改一些代码这将在最新版本中工作，这可能不适用于以前的版本。
想象一下，你的v1 API适用于.NET 3.5，v2适用于.NET 4.x和v3 .NET vNext（5？）。您无法将Web服务解决方案构建/编译到单个应用程序中，该应用程序可以在同一个IIS应用程序中使用多个.NET CLR（*这是可能的问题之一，我们可以继续下一个那些; P！）