[英]Starting ASP.NET Core from Visual Studio doesn't start from build folder
When you start an ASP.NET Core project from Visual Studio (2017) it assumes the working directory is where the source code is located, not where the built files are actually placed.当您从 Visual Studio (2017) 启动 ASP.NET Core 项目时,它假定工作目录是源代码所在的位置,而不是实际放置构建文件的位置。
Which means that when I run my project it reads the config file from C:\\Path\\To\\My\\Project\\appsettings.json
, and not from C:\\Path\\To\\My\\Project\\bin\\Debug\\appsettings.json
.这意味着当我运行我的项目时,它从C:\\Path\\To\\My\\Project\\appsettings.json
读取配置文件,而不是从C:\\Path\\To\\My\\Project\\bin\\Debug\\appsettings.json
.
I can see that this is the case when I debug this code:我可以看到当我调试这段代码时就是这种情况:
WebHost.CreateDefaultBuilder(args)
.UseStartup<Startup>()
.ConfigureAppConfiguration((context, config) => {
config.SetBasePath(context.HostingEnvironment.ContentRootPath);
config.AddJsonFile("appsettings.json", true, false);
});
Where ContentRootPath
points to the project folder, not where the built files are placed. ContentRootPath
指向项目文件夹的位置,而不是放置构建文件的位置。
I could probably fix this by setting the Working Directory
in Project Properties > Debug
, but seeing as we're also using configuration transforms (SlowCheetah), each developer will have their own build configuration for debug output ( bin\\Debug[CustomConfiguration]
), and changing .csproj
for one developer breaks it for all the other developers.我可以通过在Project Properties > Debug
设置Working Directory
来解决这个问题,但是看到我们也在使用配置转换(SlowCheetah),每个开发人员都有自己的调试输出构建配置( bin\\Debug[CustomConfiguration]
),并为一位开发人员更改.csproj
会破坏所有其他开发人员的工作。
Is there any way of having ASP.NET Core read the config files from where the built files are placed instead of the project folder, without having to change the Working Directory
, yet still working for multiple "Build Configurations"?有没有什么方法可以让 ASP.NET Core 从构建文件所在的位置而不是项目文件夹中读取配置文件,而无需更改Working Directory
,但仍然适用于多个“构建配置”?
If I understand the problem correctly, every developer has a different output folder with respect to their username.如果我正确理解了这个问题,那么每个开发人员的用户名都有不同的输出文件夹。 So, if you make up something like this,所以,如果你编造这样的东西,
var debug = string.Empty;
#if DEBUG
debug = "Debug";
#else
debug = "Release";
#endif
var userNameVariable = System.Environment.GetEnvironmentVariable("USER");
debug += $"[{userNameVariable}]";
var path = System.IO.Path.Combine(env.ContentRootPath, "bin", debug);
var builder = new ConfigurationBuilder()
.SetBasePath(path) //env.ContentRootPath
.AddJsonFile("appsettings.json", optional: false, reloadOnChange: true)
.AddEnvironmentVariables();
I have tested this on Mac OS and result is我已经在 Mac OS 上测试过了,结果是
/Users/johndoe/Documents/Temp/contentasp/bin/Debug[johndoe]
Other solution.其他解决方案。
In visual studio you have pre-build and post-build scripts.在 Visual Studio 中,您有预构建和后构建脚本。 In Visual Studio you can get the OutputFolder and set the path into a environment variable on pre-build script.在 Visual Studio 中,您可以获取 OutputFolder 并将路径设置为预构建脚本上的环境变量。 For example:例如:
powershell.exe -ExecutionPolicy Bypass -File "$(ProjectDir)outputscript.ps1" -OutputFolder $(OutputPath)
And in the powershell script ( outputscript.ps1
)并在 powershell 脚本( outputscript.ps1
)
Param(
[Parameter(Mandatory = $true, Position = 1)]
[string]$OutputFolder
)
$env:OutputFolder = $OutputFolder
And you can get the value on the startup with你可以在启动时获得价值
var outputFolder = System.Environment.GetEnvironmentVariable("OutputFolder");
var builder = new ConfigurationBuilder()
.SetBasePath(outputFolder) //env.ContentRootPath
也许这将有助于通过以下方式将目录设置为应用程序工作目录:
Directory.SetCurrentDirectory(context.HostingEnvironment.ContentRootPath);
Config files are read from the place that you configure via SetBasePath
.从您通过SetBasePath
配置的位置读取配置文件。 What happens in Development mode is that when you use WebHost.CreateDefaultBuilder
it sets BasePath
to source code folder which is logical for most developer cases.在开发模式下发生的事情是,当您使用WebHost.CreateDefaultBuilder
它将BasePath
设置为源代码文件夹,这对于大多数开发人员来说是合乎逻辑的。
It actually does not work out of the box for Console applications eg, so I specifically do the same in there.它实际上不适用于控制台应用程序,例如,所以我专门在那里做同样的事情。
There are probably few ways you can fix this:可能有几种方法可以解决此问题:
Using the existing system as it is quite convenient by default.默认情况下使用现有系统非常方便。 Perhaps you can explain in more details why does it not work for you?也许您可以更详细地解释为什么它对您不起作用?
Not using CreateDefaultBuilder
and creating the builder yourself, then you'll be able to configure it exactly as you want.不使用CreateDefaultBuilder
并自己创建构建器,然后您就可以完全按照自己的意愿配置它。
Override SetBasePath
with the value you want afterwards. SetBasePath
用您想要的值覆盖SetBasePath
。 I assume that eg AppContext.BaseDirectory
or Directory.GetCurrentDirectory()
will return the path that you are looking for我假设例如AppContext.BaseDirectory
或Directory.GetCurrentDirectory()
将返回您正在寻找的路径
Not using name "Development" for your environment will probably do the trick as well, though you will have some other consequences that you need to consider.不为您的环境使用名称“Development”也可能会起作用,尽管您会产生一些需要考虑的其他后果。
PS Why would you use slowcheetah at all to do the old styled transformation when you can use agile config? PS 当您可以使用敏捷配置时,为什么要使用slowcheetah 进行旧式转换? You can read config from multiple files and the last one in order always win, so it will be the same effect as from using slowcheetah in practice.您可以从多个文件中读取配置,最后一个总是获胜,因此与实际使用slowcheetah的效果相同。
声明:本站的技术帖子网页,遵循CC BY-SA 4.0协议,如果您需要转载,请注明本站网址或者原文地址。任何问题请咨询:yoyou2525@163.com.