如何在iisexpress vs2015中设置具有相同端口和域但路径不同的多个应用程序 [英] how to setup multiple apps with same port and domain but different paths in iisexpress vs2015

查看:11
本文介绍了如何在iisexpress vs2015中设置具有相同端口和域但路径不同的多个应用程序的处理方法,对大家解决问题具有一定的参考价值,需要的朋友们下面随着小编来一起学习吧!

问题描述

我目前正在将一个大的 asp.net 核心解决方案拆分为多个较小的解决方案,每个解决方案都有一个应用程序.为此,基础应用程序需要指向

Im currently splitting a big asp.net core solution into multiple smaller solutions, each with a single app. In order to do this, the base app needs to point at

www.originalApp.com

www.originalApp.com

并且我的每个较小的应用程序都将使用路径访问

and each of my smaller apps will be accessed using the path

www.originalApp.com/SplittedApp

www.originalApp.com/SplittedApp

我已经设法使用 IIS 在 applicationHost.config 中通过以下设置运行它

I have managed to get this running using IIS with the following setup in the applicationHost.config

        <site name="OriginalApp" id="3" serverAutoStart="true">
            <application path="/" applicationPool="OriginalAppPool">
                <virtualDirectory path="/" physicalPath="OriginalAppPath/>
            </application>
            <application path="/SplittedApp" applicationPool="splittedApp">
                <virtualDirectory path="/" physicalPath="splittedAppPath />
            </application>
            <bindings>
                <binding protocol="http" bindingInformation="*:82:" />
                <binding protocol="http" bindingInformation="IpAddress:originalApp" />
            </bindings>
            <applicationDefaults applicationPool="Fire.Frontend" />
        </site>

我在 IISExpress 的 applicationHost.config 文件中为这两个应用程序尝试了此设置的多种变体,但出现了不同的问题.

I have tried multiple variations of this setup in the applicationHost.config files for IISExpress for these 2 apps with different problems coming up.

我的应用程序launchSettings.json在拆分的应用程序中看起来像这样

my app launchSettings.json in the splitted app looks like this

{
  "iisSettings": {
    "windowsAuthentication": false,
    "anonymousAuthentication": true,
    "iisExpress": {
      "applicationUrl": "http://localhost:9345/splitted app",
      "sslPort": 0
    }
  },
  "profiles": {
    "IIS Express": {
      "commandName": "IISExpress",
      "launchBrowser": true,
      "environmentVariables": {
        "ASPNETCORE_ENVIRONMENT": "Development"
      }
    }
}

和原来的应用程序

{
  "iisSettings": {
    "windowsAuthentication": false,
    "anonymousAuthentication": true,
    "iisExpress": {
      "applicationUrl": "http://localhost:9345",
      "sslPort": 0
    }
  },
  "profiles": {
    "IIS Express": {
      "commandName": "IISExpress",
      "launchBrowser": true,
      "environmentVariables": {
        "ASPNETCORE_ENVIRONMENT": "Development"
      }
    }
}

当前设置无法加载第二个应用程序,因为正在使用相同的端口,但是我需要使用相同的端口,以便我可以附加路径并有效地导航两个应用程序之间的页面.

the current setup fails to load the second app because the same port is in use, however i need to use the same port so i can then append the path and effectively navidate the pages between the 2 applications.

我很难相信使用 IIS Express 无法实现我试图实现的目标,因为它与 IIS 一起工作得很好.

I find it hard to believe that what im trying to achieve is not possible using IIS Express since it works fine with IIS.

我已经在网络上阅读了很多关于 SO 和博客的帖子,但我找不到任何有相同问题的人,而且似乎没有类似问题的解决方案对我有用,所以如果有人能指出我正确的方向将不胜感激.

Ive read a lot of post on SO and blogs over the web but i cant find anyone with the same issue and none of the solutions to issues that seemed similar worked for me, so if anyone can point me in the right direction it would be most appreciated.

谢谢.

附注我不确定我在问题中添加的标签是否正确,所以如果有更好的标签要添加,请告诉我.

PS im not sure about the tags i added in the question are correct so let me know if there are better tags to add.

推荐答案

在我们的构建过程中,我们选择继续打包/发布"到安装了 .NET Core 处理程序的 IIS 服务器.因此,我们的选择有些限制,因为必须有某种方法在 Web 发布工具支持的开发和生产部署之间提供对称性.

In our build process, we choose continue to "Package/Publish" to an IIS server, with .NET Core handler installed. Therefore, our options are somewhat restrictive in that there must be some means to provide symmetry between development and production deployment that is supported by the Web Publish tooling.

  1. 将子内容部署为父应用的子应用
  2. 在父部署期间将子内容部署为额外的静态文件夹内容
  3. 将子内容部署为父内容的构建依赖项
  4. 使用虚拟目录手动部署子内容

选择哪个?这是一个决策树:

Which to choose? Here's a decision tree:

  • 子路径是否是要部署的应用程序/程序集(例如 WebAPI)?如果是,请选择选项 1.
  • 子路径是松散耦合的包,单独版本控制还是由另一个团队构建?如果是,请选择选项 3.
  • 在备份/恢复、部署和安全操作期间,路径是否在服务器的单个单元中得到最佳维护?如果是,请选择选项 4.
  • 否则,请选择选项 2.

让我们快速浏览每一个:

Let's rush through each of these:

这在 IIS 部署目标(例如公共 Web 服务器)上很容易.在发布目标服务器上使用相同的旧工具或手动创建子应用程序.然而,这在开发工作站上更难.在下图中,顶部显示了 .NET Core 应用程序的配置方式,而底部显示了 .NET Framework 应用程序在 Visual Studio UI 中的显示方式:

This is easy enough on the IIS Deployment target (e.g. public web server). A sub-application is created using the same old tools, or manually, on the publish target server. However, this is harder at the development workstation. In the following image, the top shows how a .NET Core application is configured, while the bottom shows how a .NET Framework application is presented in the Visual Studio UI:

在这两种情况下,它都会在 .vsconfigapplicationhost.config 文件中创建这些;但新的 ASP.NET Core 工具仅在该工作站 .config 文件中创建根应用程序(而不是子应用程序).我们可以为每个开发人员手动编辑它,但不幸的是我们通常不想检入这些文件,因为它们具有本地机器路径.无论如何,如果您尝试使用旧的多项目启动属性方法,最终会导致多个站点尝试在同一端口上运行失败.您想要的是一个具有多个应用程序的站点.这是此类(手动编辑)工作配置的示例:

In both cases, it creates these in the .vsconfigapplicationhost.config file; but the new ASP.NET Core tooling only creates root applications (not sub-applications) in that workstation .config file. We can edit this manually per-developer, but unfortunately we usually don't want to check these files in, because they have local machine paths. At any rate, if you try to use the old multi-project-startup property method, you'll end up with multiple sites attempting unsuccessfully to run at the same port. What you want instead is one site with multiple applications. Here's an example of such a (manually edited) working config:

<site name="MyNamespace.RootWeb" id="5">
  <application path="/" applicationPool="Clr4IntegratedAppPool">
    <virtualDirectory path="/" physicalPath="E:DevelopmentMySolutionMyProject" />
  </application>
  <application path="/assets" applicationPool="Clr4IntegratedAppPool">
    <virtualDirectory path="/" physicalPath="E:DevelopmentMySolutionMyProject.Assets" />
  </application>
  <bindings>
              <binding protocol="http" bindingInformation="*:55519:localhost" />
  </bindings>
</site>

另一种方法可能是创建一个 .target 文件,通过扫描您的项目 launchsettings.json 来添加 Visual Studio 在 ASP.NET Core 项目中丢失的功能文件,并在任何比片段更新时将所有项目 URL 前缀合并到单个中间 XML 片段文件中,并将片段合并到 applicationhost.config(甚至通过中间文件执行更改冲突).如果我这样做,我会告诉你的.

Another approach might be to create a .target file to add the capability that Visual Studio has lost for ASP.NET Core projects, by scanning your projects launchsettings.json files, and merging all project URL Prefixes into a single intermediate XML <sites /> fragment file when any are newer than the fragment, and merging the fragment into the applicationhost.config (even performing change conflict via the intermediate file). I'll let you know if I do this.

最后,您可以更改项目 Web 启动应用程序.不要投影",因为 Kestrel 也不能在同一个端口上托管多个应用程序.但是,WebListener 可以,可以接受完成此操作所需的所有命令行参数.

Lastly, you could change the project web start application. Not to "project", because Kestrel can't host multiple applications on the same port either. However, WebListener can, can can accept all the command line parameters you need to accomplish this.

如果我们实际上没有正在构建的相关程序集,我们可以在单个应用程序中运行.在开发工作站上,我们可以使用 if (env.IsDevelopment()) IApplicationBuilder.UseStaticFiles(); 有条件地重定向子内容的路径.我们仍然需要让内容在服务器上运行.为此,我们将使用 IncludePluginFilesForMsdeploy 部署指令,类似于:

We can run in a single application, if we don't actually have relevant assemblies we are building. On the development workstation, we can conditionally redirect a path for the child content, using if (env.IsDevelopment()) IApplicationBuilder.UseStaticFiles();. We'll still need to get the content running on the server. To that end we'll use the IncludePluginFilesForMsdeploy deployment directive, similar to this:

<PropertyGroup>
  <PipelineCopyAllFilesToOneFolderForMsdeployDependsOn>
    IncludePluginFilesForMsdeploy;
    $(PipelineCopyAllFilesToOneFolderForMsdeployDependsOn);
  </PipelineCopyAllFilesToOneFolderForMsdeployDependsOn>
</PropertyGroup>
<Target Name="IncludePluginFilesForMsdeploy">
  <ItemGroup>
    <FileWrites Include="$(MSBuildProjectDirectory)in***" />
    <_CustomFiles Include="$(MSBuildProjectDirectory)in***" />
    <FilesForPackagingFromProject Include="%(_CustomFiles.Identity)">
      <DestinationRelativePath>bin\%(RecursiveDir)%(Filename)%(Extension)</DestinationRelativePath>
    </FilesForPackagingFromProject>
  </ItemGroup>
</Target>

虽然,请注意以前的 IncludePluginFilesForMsdeployIncludePluginFilesForPackaging,现在在 VS 2017 中使用 DotnetPublishFiles 实现了相同的目标,如下所示:

Although, note that previously IncludePluginFilesForMsdeploy was IncludePluginFilesForPackaging, and now in VS 2017 the same target is implemented with DotnetPublishFiles, as shown below:

<Project ToolsVersion="12.0" xmlns="http://schemas.microsoft.com/developer/msbuild/2003">
    <Target Name="CustomCollectFiles" BeforeTargets="BeforePublish">
        <Message Text="Custom Collect Before Publish" Importance="high" />
        <ItemGroup>
            <_CustomFiles Include="$(MSBuildProjectDirectory)/../MyProject/compiled/**/*" />
            <DotnetPublishFiles Include="@(_CustomFiles)">
                <DestinationRelativePath>wwwroot/MyProject/compiled/%(RecursiveDir)%(Filename)%(Extension)</DestinationRelativePath>
            </DotnetPublishFiles>
        </ItemGroup>
    </Target>
</Project>

3.将子内容部署为父项的构建依赖项.

同样,对于静态内容(例如浏览器应用程序),我们可能会考虑将该应用程序构建到一个包中,并使用 NuGet、NPM 或类似方法将其构建到我们的开发中的根应用程序中.现在只需要部署一个应用程序这一事实在此有利也有弊.我会将其留给由不同团队维护的非常松散耦合的包,或者必须为依赖项单独维护版本控制.

3. Deploy child content as a build dependency of parent.

Again, for static content such as a browser application, we might consider building that application into a package, and requiring it into our root application in development, using NuGet, NPM, or similar. The fact that now there is a single application to deploy is both pro and con here. I'd leave this for very loosely coupled packages maintained by separate teams, or where versioning must be maintained separately for the dependencies.

在服务器上,如果我们不需要子应用程序,我们可能仍然希望为这个子内容有一个外部文件夹层次结构.我们可以使用虚拟目录在父目录下反映此内容,并包含部署标志 False.或者,我们可以使用 NPM、FTP 或其他一些技术直接部署到服务器.在开发站上,我们可以按照上面的UseStaticFiles()思路来做.或者,我们可以再次破解 .vsconfigapplicationhost.config(与团队合作时的缺点与上述相同),但要创建一个额外的虚拟目录,而不是一个额外的应用程序.

On the server, if we don't need a sub-application, we might still wish to have an external folder hierarchy for this child content. We could reflect this content under the parent using a virtual directory and include the deployment flag <DeployAsIisApp>False</DeployAsIisApp>. Alternately, we might deploy directly to the server using NPM, FTP, or some other technology. On the development station, we can do the same UseStaticFiles() idea as above. Alternately, we could hack the .vsconfigapplicationhost.config again (same downsides as above when working with a team) but to create an additional virtual directory rather than an additional application.

这篇关于如何在iisexpress vs2015中设置具有相同端口和域但路径不同的多个应用程序的文章就介绍到这了,希望我们推荐的答案对大家有所帮助,也希望大家多多支持IT屋!

查看全文
登录 关闭
扫码关注1秒登录
发送“验证码”获取 | 15天全站免登陆