如何在iisexpress vs2015中使用相同的端口和域设置不同路径的多个应用 [英] how to setup multiple apps with same port and domain but different paths in 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 我不确定我在问题中添加的标签是否正确，所以请告诉我是否有更好的标签要添加.

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应用程序，而底部显示了如何在Visual Studio UI中显示.NET Framework应用程序:

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:

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

In both cases, it creates these in the .vs\config\applicationhost.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:\Development\MySolution\MyProject" />
  </application>
  <application path="/assets" applicationPool="Clr4IntegratedAppPool">
    <virtualDirectory path="/" physicalPath="E:\Development\MySolution\MyProject.Assets" />
  </application>
  <bindings>
              <binding protocol="http" bindingInformation="*:55519:localhost" />
  </bindings>
</site>

另一种方法可能是创建一个.target文件，以通过扫描项目launchsettings.json文件并将所有项目URL前缀合并到单个中间XML中来添加Visual Studio失去的ASP.NET Core项目功能. <sites />片段文件(如果有的话)比该片段新，并且将该片段合并到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 Start应用程序.不要投影"，因为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)\bin\**\*" />
    <_CustomFiles Include="$(MSBuildProjectDirectory)\bin\**\*" />
    <FilesForPackagingFromProject Include="%(_CustomFiles.Identity)">
      <DestinationRelativePath>bin\%(RecursiveDir)%(Filename)%(Extension)</DestinationRelativePath>
    </FilesForPackagingFromProject>
  </ItemGroup>
</Target>

但是，请注意，以前的IncludePluginFilesForMsdeploy是IncludePluginFilesForPackaging，现在在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.

在服务器上，如果不需要子应用程序，我们可能仍希望为此子内容使用外部文件夹层次结构.我们可以使用虚拟目录在父项下反映此内容，并包含部署标志<DeployAsIisApp>False</DeployAsIisApp>.或者，我们可以使用NPM，FTP或其他某种技术直接部署到服务器.在开发站上，我们可以执行与上述相同的UseStaticFiles()想法.或者，我们可以再次破解.vs\config\applicationhost.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 .vs\config\applicationhost.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屋！