Web 应用程序结构和部署答案

【问题标题】：Web Application Structure and DeploymentWeb 应用程序结构和部署
【发布时间】：2011-12-06 20:23:38
【问题描述】：

我们的产品是一个 ASP.Net Web 应用程序。目前，我们在 Visual Studio 中使用网站项目，但很长一段时间以来一直在研究使用 Web 应用程序项目。我目前正在研究它们，希望我们可以改进我们的部署过程。

我们有一个在不同客户之间共享和通用的基础网站，然后我们在客户网站项目中使用客户特定的功能对其进行扩展。客户项目扩展了基础，因此依赖于其内容。为了构建完整的产品，我们首先部署基础网站，然后将其与来自客户端项目的内容叠加。

在考虑在 Visual Studio 中转换为 Web 应用程序项目时，我们希望能够创建基础项目，然后创建客户端项目并设置对基础的引用。这种结构似乎工作正常，但是当我们尝试使用 MSDeploy 从客户端项目部署应用程序时，只会发布来自基本网站的 dll。这对于某些事情来说很好，引用已编译的代码很有用，但还有其他项目，如图像、js 页面、htm 等，它们仍然是客户端应用程序运行所需的源。我们需要的不仅仅是来自我们基础网站的编译代码。

说了这么多，我可以在这里想到几个选项：

分两步继续部署。首先是基础网站，然后是构建完整产品的客户端网站。
修改部署过程，从基础项目中复制所需的源文件
重新构建我们的模型，以不同的方式支持这种基础-客户关系。不太确定这将如何工作，并且将是最不可行的选择。
??

我是否缺少其他选项？我设置项目的方式有问题吗？除了共享编译代码之外，让一个 Web 应用程序引用另一个 Web 应用程序还有更多的方法吗？如果是这样，你为什么不直接使用共享类库呢？或者我在 MS Deploy 过程中遗漏了什么？

我对这里的建议持开放态度，因为我觉得我错过了一些东西。我不认为我们的网络应用模型太独特了。

更新：双重部署过程确实有效，但感觉有点笨拙。还有其他输入吗？

【问题讨论】：

顺便说一句，是的，你的模型不寻常。但无论如何都要远离网站“项目”。它们是独一无二的，而且不是很好。
是的，我们早就知道网站项目是……嗯，在很多方面都是“特殊的”。有时很难修复没有损坏的东西。是什么让我们的结构如此独特？另一个可能的选择是让每个项目都包含应用程序的完整源代码并设置某种源分支。不过，我们以前也这样做过，但要维护更改变得非常困难。
我以前没有想过在这种情况下使用分支，但仅供参考，TFS 2010 中的分支比过去更容易使用。值得一看。我还建议您仔细地将应用程序的特定于客户端的部分与公共部分分开和隔离。在应用程序中创建特定的可扩展性和自定义点。这将使您更容易了解如何最好地部署它。您还可以使用 MSDEPLOY 玩一些有趣的技巧。见amazon.com/Inside-Microsoft-Build-Engine-Foundation/dp/…
让我们的产品与众不同的部分原因是客户可以拥有独一无二的页面，并且根本不包含在我们的基础网站中。因此，除了扩展现有应用程序之外，它实际上是对它的补充。这就是我对您关于我们拥有独特内容的可扩展点的建议感到困惑的地方。
你读过aspnet_merge.exe msdn.microsoft.com/en-us/library/aa479044.aspx

标签： asp.net web-applications deployment msdeploy web-application-project

【解决方案1】：

通过使用程序集 WebResource，您可以添加 CSS/JS/其他文件作为参考以及代码，即您的基础项目 DLL。

如果是正确的，您可以在基础项目中添加此 WebResource，然后通过以下链接。

http://support.microsoft.com/kb/910442

像这样，大多数第三方工具都会访问他们的 CSS 和 JS 文件。

试试这个。希望它会有所帮助。

【讨论】：

【解决方案2】：

网站如何在客户之间“共享”？每个客户最终会获得不同的站点（IP 地址等），还是他们登录到同一个站点但获得不同的功能？您可能希望考虑将所有功能添加到单个项目中，然后通过设置启用/禁用功能。

【讨论】：

【解决方案3】：

如果我正确理解了您的问题，您还想发布未编译的项目（htm、JS、图像等）。

因此，解决方案资源管理器选项卡中的每个文件都有自己的属性（通过 F4 键访问），可让您选择构建操作（例如，编译 -> 如果适用，将在 DLL 中注入项目，内容 -> 将复制文件“原样”到输出目录）。

我认为构建操作“内容”，选项“复制到输出目录”设置为“如果较新则复制”，可能是您正在寻找的解决方案。

【讨论】：

【解决方案4】：

我会仔细分析您在项目之间共享的内容以及共享方式。

如果是编译代码，正确的方法是将这些类提取到它们自己的命名空间和程序集中，并跨项目共享 DLL。确保在重构时遵循 OO 和 SOLID 原则。

如果您共享的是内容（js、htm、图像、css），您可以在这里选择一些。您可以为内容创建一个单独的虚拟目录，并使用绝对 URL 引用您的内容。这很有帮助，因为以后如果您想在 IIS 中将项目分离到其自己的网站中，则不必更改内容 URL。您还可以拥有所谓的基础网站中的所有内容，然后使用相对于基础网站的相对路径引用其他项目中的内容。

另一方面，如果您想共享 ASP.NET 用户控件或 ASP.NET MVC 视图，最好在每个项目中创建一个单独的项目。这并不一定意味着该路径中有单独的物理文件 - 您还可以在 Visual Studio 的 .NET 项目中添加仅作为参考链接的项目。

关于部署过程，我认为网站项目本身没有任何问题。网站项目的目的与 Web 应用程序项目不同，主要是您不必在每次部署代码时都编译您的类（前提是它们位于正确的应用程序文件夹中）。我建议坚持使用网站项目的两步部署过程。

我还会查看在 IIS 中创建的网站（虚拟目录），如果有意义的话，我会考虑嵌套它们。并且审查应用程序池（无论是单独的还是共享的）也不会造成损害。

最后，这是一个老问题。如果您已经实施了成功的策略，请分享。

【讨论】：