如何为多个 Xamarin 应用程序构建项目答案

【问题标题】：How to Structure Projects for Multiple Xamarin Apps如何为多个 Xamarin 应用程序构建项目
【发布时间】：2020-08-21 22:24:20
【问题描述】：

我的团队正致力于将多个旧版移动应用程序转换为 Xamarin Forms 应用程序。目前，每个应用程序都有自己的解决方案，当涉及到它们都使用一组通用的后端软件库这一事实时，这并不理想。我们计划将所有较小的解决方案整合到一个解决方案中，其中包含应用程序和公共库。

但是，我的一位队友提出了一个有效的担忧，即如何使用单个 Xamarin Forms 应用程序生成多个项目（核心、Android、iOS 等），最终导致一个通常笨拙的解决方案。我同意他的观点，即当前的设置可能无法很好地扩展，因为我们添加了更多的应用程序——即使我们将项目分组到解决方案文件夹中，在解决方案中存在一定数量的项目后，Visual Studio 最终也会慢下来。

因此，我们正在考虑让每个应用程序都包含在自己的解决方案中，每个解决方案都包含该应用程序的几个 Xamarin Forms 项目，如上所述。但这又让我们回到了如何合理管理共享库代码的问题上。我目前的想法是只为库使用共享项目，或者将它们组装到应用解决方案将使用的 NuGet 包中。我在这里走对了吗，或者有人知道更好的方法吗？

【问题讨论】：

您好，想知道您对此的体验如何。可能面临相同的场景，即多个应用可能使用相同的代码、视图、视图模型，并考虑是否可以在相同的解决方案中适应这些情况。

标签： visual-studio xamarin shared-libraries solution ms-project

【解决方案1】：

使用子树、子模块、NuGet 包等管理共享代码项目有多种不同的方法。每种方法各有利弊，因此最好根据该项目的预期用例来决定。

子树本质上是获取远程仓库的副本并将其拉入父仓库。这使得从远程存储库中提取更改变得容易，但如果预计更改会被推迟，则可能会更加困难，因为它不了解远程存储库。虽然可以将更改推回，但可能需要很长时间才能完成，具体取决于 repos 的历史记录量。

子模块类似于子树，不同之处在于它不是获取副本，而是根据指向的特定提交跟踪远程仓库。这基本上可以被认为是父级内部的另一个 repo，它使得将更改推送回远程 repo 变得更加容易，但代价是从中提取/更新变得更加困难。

NuGet 包非常便于安装、更新和发布给其他人，而无需公开源代码，但这需要更多的初始设置来生成每个包版本，并且代价是使其变得更加困难调试比使用实际的源代码。如果共享代码库将分发给其他人，这是一个特别好的选择。

对于大多数项目，如果预计可能会对共享项目从消费项目进行更改，我建议为每个项目创建一个 repo，并将共享项目设置为每个项目的子模块。确实需要一些学习才能习惯签出和更新子模块的不同过程，但实际上并不是那么困难，值得学习一些所需的 git 命令。 docs 提供了一个很好的例子来说明如何开始使用子模块。

【讨论】：

我还没有真正考虑过子树，但这是一个有用的总结。我们可能会在界面的两侧做一些工作，所以可能不是我们的最佳选择。
我考虑过子模块。我认为它们是一个不错的选择，但我的团队刚刚开始接触 git，我认为现在使用更高级的功能并不是一个好主意。
NuGet 包是我倾向于的。我已经做了一些初步的可行性演示，它似乎可以与我们的设置一起使用。显然，实际上可以将调试符号放入其中，这样会有所帮助。我可能会从“添加现有项目”开始到解决方案路线，它具有大致相同的解决方案/项目布局，然后切换到 NuGet。
是的，如果您的团队开始学习 git，我可能会从 NuGet 包开始，然后可能首先自己学习如何使用子模块，以便能够教授您的团队。一种 sln 方法并不是最糟糕的选择，但这肯定会变得非常麻烦。他们最近推出了sourcelink 来帮助调试 NuGet 包，我还没有尝试过，但如果它运行良好，它可能会使调试包变得如此简单，可能不值得切换到子模块。