如何构建代码以将 2 个 Web 应用部署到同一个 Azure 应用服务
How to structure code to have 2 web apps deployed to the same Azure App Service
我正在开始一个新项目（我们称它为 MyWebProject），它将有
- MyWebProject：带有 AspNet Core 的前端应用程序服务于 Angular2
的 SPA
- MyWebProjectAPI：AspNet Core 连接到数据库并公开 RESTful API[=46= 的后端应用程序]
它们没有相互依赖关系，因为 MyWebProject 仅通过 http 请求访问 MyWebProjectAPI。所以我们可以说它们是独立的。
我有一个域 www.mywebproject.com 链接到一个 Azure 应用程序服务 mywebproject.azurewebsites.net，我想要两个项目（前端和 RESTful API）部署在同一 Azure 应用下。
如果我使用网络浏览器访问 www.mywebproject.com 我想访问前端。我不介意 RESTful API 的部署位置（我猜是在同一个 App Service IIS 下的虚拟目录中？）
我还计划进行持续部署，将更改推送到 Git 存储库中的主分支会触发新部署（理想情况下，两个部署都是单独配置的，但我不太介意）
问题是：
如何构建我的 solution/projects 以及我应该遵循什么方法？
我正在考虑一个单一的解决方案，包含 2 个主要项目（前端和后端）以及后端项目所需的库项目，因此我假设它们都必须在同一个项目中Git 存储库？。那会有问题吗？还是将它们放在单独的 Git 存储库和单独的解决方案中更好？ （这个选项也可以）
部署到同一个 Azure 应用程序服务时应遵循什么方法？要使用虚拟目录，因为它们都是 Web 项目（都有 wwwroot）？
另一种选择可以是 RESTful API 和前端的单个项目，其中一个控制器仅服务于 SPA，而其他控制器充当 API 资源.这肯定会简化一切，但不知何故我想让这两个项目独立。
如有任何参考、文章或意见，我们将不胜感激。
我使用一个应用程序，我们有一个解决方案，用于两个不同的 Web 项目，它们都位于同一个域中，并且都使用持续部署进行部署。结果很好。它是这样工作的：
- 有一个Visual Studio解决方案
- 在该解决方案下有两个 web 项目
- 在您的应用服务的 Azure 应用程序设置中，滚动到底部 "Virtual applications and directories" 并为 MyWebProjectAPI 设置一个虚拟目录。虚拟目录为“/MyWebProjectAPI”，物理路径为 "site\wwwroot\MyWebProjectAPI"
- 创建 deploy.cmd 以在解决方案文件夹中进行持续部署，就像正常操作一样
- 编辑 deploy.cmd 以同时部署第二个 Web 项目。
您会找到第一个项目的一行，如下所示：
call :ExecuteCmd "%MSBUILD_PATH%" "%DEPLOYMENT_SOURCE%\MyWebProject\MyWebProject.csproj" /nologo /verbosity:m /t:Build /t:pipelinePreDeployCopyAllFilesToOneFolder /p:_PackageTempDir="%DEPLOYMENT_TEMP%";AutoParameterizationWebConfigConnectionStrings=false;Configuration=Release /p:SolutionDir="%DEPLOYMENT_SOURCE%\.\"
IF !ERRORLEVEL! NEQ 0 goto error
复制该代码并更新它以将 API 项目构建到虚拟目录中（注意第一个路径以及 PackageTempDir 已更改）：
call :ExecuteCmd "%MSBUILD_PATH%" "%DEPLOYMENT_SOURCE%\MyWebProjectAPI\MyWebProjectAPI.csproj" /nologo /verbosity:m /t:Build /t:pipelinePreDeployCopyAllFilesToOneFolder /p:_PackageTempDir="%DEPLOYMENT_TEMP%\MyWebProjectAPI";AutoParameterizationWebConfigConnectionStrings=false;Configuration=Release /p:SolutionDir="%DEPLOYMENT_SOURCE%\.\"
IF !ERRORLEVEL! NEQ 0 goto error
部署后，您的前端将位于 www.mywebproject.com，api 将位于 www.mywebproject。com/mywebprojectapi（当然您可以重命名所有内容）。
这是正确的方法吗？有利也有弊。在我们的案例中，我们需要这样做，因为第二个 Web 项目来自第三方并且必须位于同一域中。这是一个很大的好处——你可以避免任何可能的跨域问题。此外，您需要进行大量整合，只需担心一个 DNS 条目（包括 SSL 证书），并且只需关注一个应用服务。
不过，我可能会争辩说，最好让您的代码 运行 在两个应用程序中获得更明显的监控和可扩展性。你说你现在只想要一个应用程序服务，所以无论哪种方式你都无法扩展。但是，如果您将两个项目设置为不同的应用程序，如果您需要扩展一个而不是另一个，则最终可以将它们移动到单独的应用程序服务。
如果您确实想要两个具有不同 DNS 条目的独立应用程序，您仍然可以只有一个解决方案文件。我没有这样做的确切示例，但您可以让两个应用程序监视该分支。因此，当您推送时，构建将在两个应用程序中启动。但是你会在你的 Azure 应用程序设置中添加一个设置，说明应该构建哪个项目，然后你会修改 deploy.cmd 文件以查找此参数来构建正确的项目。
我正在开始一个新项目（我们称它为 MyWebProject），它将有
- MyWebProject：带有 AspNet Core 的前端应用程序服务于 Angular2 的 SPA
- MyWebProjectAPI：AspNet Core 连接到数据库并公开 RESTful API[=46= 的后端应用程序]
它们没有相互依赖关系，因为 MyWebProject 仅通过 http 请求访问 MyWebProjectAPI。所以我们可以说它们是独立的。
我有一个域 www.mywebproject.com 链接到一个 Azure 应用程序服务 mywebproject.azurewebsites.net，我想要两个项目（前端和 RESTful API）部署在同一 Azure 应用下。
如果我使用网络浏览器访问 www.mywebproject.com 我想访问前端。我不介意 RESTful API 的部署位置（我猜是在同一个 App Service IIS 下的虚拟目录中？）
我还计划进行持续部署，将更改推送到 Git 存储库中的主分支会触发新部署（理想情况下，两个部署都是单独配置的，但我不太介意）
问题是：
如何构建我的 solution/projects 以及我应该遵循什么方法？
我正在考虑一个单一的解决方案，包含 2 个主要项目（前端和后端）以及后端项目所需的库项目，因此我假设它们都必须在同一个项目中Git 存储库？。那会有问题吗？还是将它们放在单独的 Git 存储库和单独的解决方案中更好？ （这个选项也可以）
部署到同一个 Azure 应用程序服务时应遵循什么方法？要使用虚拟目录，因为它们都是 Web 项目（都有 wwwroot）？
另一种选择可以是 RESTful API 和前端的单个项目，其中一个控制器仅服务于 SPA，而其他控制器充当 API 资源.这肯定会简化一切，但不知何故我想让这两个项目独立。
如有任何参考、文章或意见，我们将不胜感激。
我使用一个应用程序，我们有一个解决方案，用于两个不同的 Web 项目，它们都位于同一个域中，并且都使用持续部署进行部署。结果很好。它是这样工作的：
- 有一个Visual Studio解决方案
- 在该解决方案下有两个 web 项目
- 在您的应用服务的 Azure 应用程序设置中，滚动到底部 "Virtual applications and directories" 并为 MyWebProjectAPI 设置一个虚拟目录。虚拟目录为“/MyWebProjectAPI”，物理路径为 "site\wwwroot\MyWebProjectAPI"
- 创建 deploy.cmd 以在解决方案文件夹中进行持续部署，就像正常操作一样
- 编辑 deploy.cmd 以同时部署第二个 Web 项目。
您会找到第一个项目的一行，如下所示：
call :ExecuteCmd "%MSBUILD_PATH%" "%DEPLOYMENT_SOURCE%\MyWebProject\MyWebProject.csproj" /nologo /verbosity:m /t:Build /t:pipelinePreDeployCopyAllFilesToOneFolder /p:_PackageTempDir="%DEPLOYMENT_TEMP%";AutoParameterizationWebConfigConnectionStrings=false;Configuration=Release /p:SolutionDir="%DEPLOYMENT_SOURCE%\.\"
IF !ERRORLEVEL! NEQ 0 goto error
复制该代码并更新它以将 API 项目构建到虚拟目录中（注意第一个路径以及 PackageTempDir 已更改）：
call :ExecuteCmd "%MSBUILD_PATH%" "%DEPLOYMENT_SOURCE%\MyWebProjectAPI\MyWebProjectAPI.csproj" /nologo /verbosity:m /t:Build /t:pipelinePreDeployCopyAllFilesToOneFolder /p:_PackageTempDir="%DEPLOYMENT_TEMP%\MyWebProjectAPI";AutoParameterizationWebConfigConnectionStrings=false;Configuration=Release /p:SolutionDir="%DEPLOYMENT_SOURCE%\.\"
IF !ERRORLEVEL! NEQ 0 goto error
部署后，您的前端将位于 www.mywebproject.com，api 将位于 www.mywebproject。com/mywebprojectapi（当然您可以重命名所有内容）。
这是正确的方法吗？有利也有弊。在我们的案例中，我们需要这样做，因为第二个 Web 项目来自第三方并且必须位于同一域中。这是一个很大的好处——你可以避免任何可能的跨域问题。此外，您需要进行大量整合，只需担心一个 DNS 条目（包括 SSL 证书），并且只需关注一个应用服务。
不过，我可能会争辩说，最好让您的代码 运行 在两个应用程序中获得更明显的监控和可扩展性。你说你现在只想要一个应用程序服务，所以无论哪种方式你都无法扩展。但是，如果您将两个项目设置为不同的应用程序，如果您需要扩展一个而不是另一个，则最终可以将它们移动到单独的应用程序服务。
如果您确实想要两个具有不同 DNS 条目的独立应用程序，您仍然可以只有一个解决方案文件。我没有这样做的确切示例，但您可以让两个应用程序监视该分支。因此，当您推送时，构建将在两个应用程序中启动。但是你会在你的 Azure 应用程序设置中添加一个设置，说明应该构建哪个项目，然后你会修改 deploy.cmd 文件以查找此参数来构建正确的项目。