如何在iisexpress vs2015中设置具有相同端口和域但具有不同路径的多个应用程序

时间:2017-02-28 15:59:09

标签: visual-studio-2015 asp.net-core iis-express

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

  

www.originalApp.com

我将使用路径

访问每个较小的应用
  

www.originalApp.com/SplittedApp

我已经设法使用IIS在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文件中为这两个应用程序尝试了此设置的多种变体,这些应用程序出现了不同的问题。

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

{
  "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"
      }
    }
}

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

我发现很难相信使用IIS Express无法实现的目标,因为它可以与IIS一起使用。

我已经通过网络阅读了很多关于SO和博客的帖子,但是我找不到任何有同样问题的人,并且找不到类似问题的解决方案都没有对我有用,所以如果有人能指出我正确的方向它非常感谢。

感谢。

PS 我不确定我在问题中添加的标签是否正确所以请告诉我是否有更好的标签要添加。

2 个答案:

答案 0 :(得分:0)

不确定是否可行,因为每个IIS Express Web应用程序应该为每个应用程序和每个协议使用不同的端口。

我遇到了类似的问题,最终在本地随机端口上运行了.net核心应用程序,并在DEV服务器上设置了正确的域和虚拟目录。

答案 1 :(得分:0)

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

以下是一些可能的解决方案:

  1. 将子内容部署为父应用程序的子应用程序
  2. 在父部署期间将子内容部署为其他静态文件夹内容
  3. 将子内容部署为父级的构建依赖项
  4. 使用虚拟目录手动部署子内容
  5. 选择哪个?这是一个决策树:

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

    让我们匆匆走过这些:

    1。将子内容部署为父应用程序的子应用程序

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

    在这两种情况下,它都会在.vs\config\applicationhost.config文件中创建;但新的ASP.NET Core工具只在该工作站.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前缀合并到一起,为ASP.NET Core项目添加Visual Studio丢失的功能。单个中间XML <sites />片段文件,如果它们比片段更新,并将片段合并到applicationhost.config(甚至通过中间文件执行更改冲突)。如果我这样做,我会告诉你的。

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

    2。在父部署期间将子内容部署为其他静态文件夹内容。

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

    <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>
    

    虽然,请注意,之前IncludePluginFilesForMsdeployIncludePluginFilesForPackaging,现在在VS 2017中,DotnetPublishFiles实现了同一目标,如下所示:

    <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或类似方法将其应用到开发中的根应用程序中。现在有一个部署的应用程序在这里是pro和con。我将其留给由不同团队维护的非常松散耦合的包,或者必须为依赖项单独维护版本。

    4。使用虚拟目录手动部署子内容。

    在服务器上,如果我们不需要子应用程序,我们可能仍希望为此子内容设置外部文件夹层次结构。我们可以使用虚拟目录在父级下反映此内容,并包含部署标志<DeployAsIisApp>False</DeployAsIisApp>。或者,我们可以使用NPM,FTP或其他技术直接部署到服务器。在开发站,我们可以执行与上述相同的UseStaticFiles()想法。或者,我们可以再次破解.vs\config\applicationhost.config(与团队合作时的上述缺点)但是要创建一个额外的虚拟目录而不是其他应用程序。