Web应用程序结构和部署
我们的产品是一个 ASP.Net Web 应用程序。目前，我们在 Visual Studio 中使用网站项目，但研究使用 Web 应用程序项目已经有一段时间了。我目前正在研究它们，以便我们能够改进我们的部署过程。
我们有一个在不同客户之间共享和公用的基本网站，然后我们在客户网站项目中使用客户特定的功能来扩展该网站。客户项目扩展了基础，因此依赖于其内容。为了构建完整的产品，我们首先部署基础网站，然后将其与客户端项目的内容覆盖。
在考虑在 Visual Studio 中转换为 Web 应用程序项目时，我们希望能够创建基础项目，然后创建客户端项目并设置对基础项目的引用。此结构似乎工作正常，但当我们尝试使用 MSDeploy 从客户端项目部署应用程序时，仅发布基础网站中的 dll。这对于某些事情来说很好，引用编译的代码很有用，但是还有其他项目（例如图像、js 页面、htm 等）仍然是客户端应用程序运行所需的源代码。我们需要的不仅仅是来自我们的基础网站的已编译代码。
综上所述，我可以在这里想到几个选项：
- 继续分两步部署。首先是基础网站，然后是客户端网站以构建完整的产品。
- 修改部署过程以从基础项目复制所需的源文件
- 重新构建我们的模型以以不同的方式支持这种基础-客户端关系。不太确定这将如何运作，并且将是最不可行的选择。
- ??
我缺少其他选择吗？我设置项目的方式是否有问题？除了共享编译代码之外，还有其他方法可以使 Web 应用程序引用另一个 Web 应用程序吗？如果是这样的话，为什么不直接使用共享类库呢？或者也许我在 MS 部署过程中遗漏了一些东西？
我愿意接受这里的建议，因为我觉得我错过了一些东西。我不认为我们的网络应用程序模型太独特。
更新：双重部署过程确实有效，但感觉有点混乱。还有其他输入吗？
Our product is an ASP.Net web application. Currently, we use Web Site Projects in Visual Studio, but have been looking into using Web Application Projects for quite some time. I am currently researching them so that we can hopefully improve our deployment process.
We have a base web site that is shared and common between different clients, and then we extend that with client-specific functionality in client Web Site Projects. The client projects extend base, and therefore rely on its contents. To build the full product, we first deploy the base web site, and then overlay it with the content from the client project.
In looking at converting to Web Application Projects in Visual Studio, we were hoping to be able to create the base project, then create client projects and set up references to base. This structure seems to work OK, but when we are attempting to deploy the application from the client project using MSDeploy, only the dll from the base web site is being published. This is fine for some things, referencing the compiled code is useful, but there are other items like images, js pages, htm, etc that is still source that is required for the client application to function. We need more than the compiled code from our base web site.
That all being said, I can think of a few options here:
- Continue to deploy in 2 steps. First the base web site, then the client web site to build the full product.
- Modify the deployment process to copy the required source files from the base project
- Re-architect our model to support this base-client relationship in a different manner. Not quite sure how this would work, and would be the least-viable option.
- ??
Is there a different option that I am missing? Am I doing something wrong with the way I am setting up my projects? Is there more to making a Web Application reference another Web Application beyond sharing compiled code? If that's the case, why wouldn't you just use a shared class library? Or maybe I am missing something with the MS Deploy process?
I am open to suggestions here as I feel like I am missing something. I don't think our model for our web applications is too unique.
Update: The dual-deploy process does work, but feels a little kludgey. Any other input?
如果你对这篇内容有疑问，欢迎到本站社区发帖提问 参与讨论，获取更多帮助，或者扫码二维码加入 Web 技术交流群。
绑定邮箱获取回复消息
由于您还没有绑定你的真实邮箱，如果其他用户或者作者回复了您的评论，将不能在第一时间通知您！
发布评论
评论（4）
通过使用程序集 WebResource，您可以添加 CSS/JS/其他文件作为参考以及代码，即您的基础项目 DLL。
如果我是对的，您可以在您的基础项目中添加此 WebResource，然后访问以下链接。
http://support.microsoft.com/kb/910442
这样，大多数第三个party工具将访问他们的CSS和JS文件。
试试这个。希望它会有所帮助。
By using assembly WebResource you can Add CSS/JS/Some other File as Reference along with the Code i.e, your Base Project DLL.
If am right you can Add this WebResource in your base project then go through the below link.
http://support.microsoft.com/kb/910442
Like this way, most of the third party tools will access their CSS and JS files.
Try this. Hope it will help.
网站如何在客户之间“共享”？每个客户端最终是否会获得不同的站点（IP 地址等），或者他们是否登录到同一站点但获得不同的功能？您可能希望考虑将所有功能添加到单个项目中，然后通过设置启用/禁用功能。
How is the site "shared" between clients? Does each client ultimately get a different site (ip address, etc) or are they logging into the same site but getting different functionality? You may want to looking into adding ALL the functionality into a single project and then enabling/disabling feature via settings.
如果我正确理解了你的问题，你还想发布未编译的项目（htm、JS、图像等）。
因此，“解决方案资源管理器”选项卡中的每个文件都有自己的属性（通过 F4 键访问），可让您选择构建操作（例如，编译 -> 将在适用的情况下将项目注入 DLL，内容 -> 将复制文件“按原样”保存到输出目录）。
我认为构建操作“内容”，并将选项“复制到输出目录”设置为“如果较新则复制”，可能是您正在寻找的解决方案。
If i have correctly understood your question, you'd like to publish also items which aren't compiled (htm, JS, images, etc..).
So, each file in your Solution Explorer tab has its own properties (accessed by F4 key) which let you choose the build action (eg. compile -> will inject the item in the DLL if applicable, content -> will copy the file "as is" to output directory).
I think the build action "content", with the option "copy to output directory" set to "copy if newer", may be the solution you're looking for.
我会仔细分析您在项目之间共享的内容以及如何共享它们。
如果它是编译代码，正确的方法是将这些类提取到它们自己的命名空间和程序集中，并在项目之间共享 DLL。确保在重构时遵循 OO 和 SOLID 原则。
如果您共享的是内容（js、htm、图像、css），则这里有几个选项。您可以为内容创建单独的虚拟目录，并使用绝对 URL 引用您的内容。这很有帮助，因为以后如果您想在 IIS 中将项目分离到其自己的网站中，则无需更改内容 URL。您还可以将所有内容放在所谓的基础网站中，然后使用相对于基础网站的相对路径引用其他项目中的内容。
另一方面，如果您想要共享 ASP.NET 用户控件或 ASP.NET MVC 视图，则最好在每个项目中创建单独的项目。这并不一定意味着该路径中有一个单独的物理文件 - 您还可以在 Visual Studio 的 .NET 项目中添加仅作为参考链接的项目。
关于部署过程，我不认为网站项目本身有什么问题。网站项目的用途与 Web 应用程序项目不同，主要是您不必在每次部署代码时都编译您的类（只要它们位于正确的应用程序文件夹中）。
我建议对网站项目坚持两步部署过程。
我还会查看在 IIS 中创建的网站（虚拟目录），并考虑在有意义的情况下嵌套它们。对应用程序池（无论是单独的还是共享的）进行审查也不会造成损害。
最后，这是一个老问题了。如果您已经实施了成功的策略，请分享。
I would carefully analyze what you are sharing between projects and how you share them.
If it is compiled code, the correct way is to extract those classes out into their own namespace and assembly and share the DLL across projects. Ensure you follow OO and SOLID principles while refactoring.
If it is content (js, htm, images, css) that you share, you have a few options here. You can create a separate virtual directory for the content and reference your content with an absolute URL. This helps because later down the line if you ever want to separate out a project into its own website in IIS, you don't have to change the content URLs. You can also have all the content in your so-called base website and then reference the content in the other projects using a relative path relative to the base website.
On the other hand, if it is ASP.NET user controls or ASP.NET MVC views that you would like to share, it is best to create an individual item in each project. This does not necessarily mean there is a separate physical file in that path - you can also add items in a .NET project in Visual Studio that are only reference links.
Regarding the deployment process, I don't think there is anything wrong with the web site projects per se. Web site projects have a purpose that is different than Web application projects, the main being that you do not have to compile your classes every time you deploy code (provided they are in the correct application folders).
I would suggest sticking to the 2 step deployment process with Web site projects.
I would also review the web sites (virtual directories) created in IIS and consider nesting them if it makes sense. And a review of the application pools (whether separate or shared) would not harm either.
Lastly, this is an old question. Please share if you have already implemented a successful strategy.