When use PublishSingleFile invalidates IWebHostBuilder.UseUrls method

[cnzhnet]

All attempts to set the web listening address fail when publishing with PublishSingleFile in a project. The program always run on the default address: http://localhost:5000. However, things work fine when PublishSingleFile is set to false.

[swaroop-sridhar]

@cnzhnet can you please provide repro instructions for this issue?

I tried the following on a template ASP .Net Core empty project (dotnet new web), and it seems to work fine.

D:\test\web>dotnet publish -r win-x86 -o 1exe /p:PublishSingleFile=true
Microsoft (R) Build Engine version 16.3.0+0f4c62fea for .NET Core
Copyright (C) Microsoft Corporation. All rights reserved.

  Restore completed in 14.57 ms for D:\test\web\web.csproj.
  web -> D:\test\web\bin\Debug\netcoreapp3.0\win-x86\web.dll
  web -> D:\test\web\1exe\

D:\test\web>D:\test\web\bin\Debug\netcoreapp3.0\win-x86\publish\web.exe  --urls=http://localhost:5003
info: Microsoft.Hosting.Lifetime[0]
      Now listening on: http://localhost:5003
info: Microsoft.Hosting.Lifetime[0]
      Application started. Press Ctrl+C to shut down.
info: Microsoft.Hosting.Lifetime[0]
      Hosting environment: Production
info: Microsoft.Hosting.Lifetime[0]
      Content root path: D:\test\web
info: Microsoft.Hosting.Lifetime[0]
      Application is shutting down...

[cnzhnet]

发送自 Windows 10 版邮件https://go.microsoft.com/fwlink/?LinkId=550986应用

发件人: Swaroop Sridharmailto:notifications@github.com 发送时间: 2020年1月4日 06:12 收件人: dotnet/runtimemailto:runtime@noreply.github.com 抄送: 巽翎君mailto:cnzhnet@hotmail.com; Mentionmailto:mention@noreply.github.com 主题: Re: [dotnet/runtime] When use PublishSingleFile invalidates IWebHostBuilder.UseUrls method (#1286)

Please read the “read me.docx”

[cnzhnet]

OK, I've replied to you an email with the project source code and detailed documentation that reproduces the bug

[cnzhnet]

I think the problem is that PublishSingleFile actually presses the all dependencies into a separate executable file. When you run this executable file, it is unzipped to the user's temporary directory and the application's real code is executed in that directory. This has led to changes to the working directory, So when I use AppContext.BaseDirectory or AppDomain.CurrentDomain.BaseDirectory to get the current directory, the path is incorrect, so the program can't find my configuration information for urls, even wwwroot or other Files in any subdirectory will not be properly accessible.

[swaroop-sridhar]

@cnzhnet In the current version, we simply extract the contents of the bundle to a directory on the disk, and declare that directory as the base-directory. This choice aims to preserve compatibility for apps that assume that Appcontext.basedirectory contains the app.dll. In the current version, we'll need to use Process.GetCurrentProcess().MainModule.FileName or native APIs such as GetModuleFileName() to get the path of the native AppHost.

In subsequent versions, once the app.dll is processed directly from the bundle, the design doc discusses options to set AppContext.BaseDirectory. The current proposal is to set it to the location of the AppHost.

This is a dup of dotnet/core-setup#7491