weixin_39571219
weixin_39571219
2020-12-28 12:15

Call ".UseContentRoot(Directory.GetCurrentDirectory())" by default and remove it from the template

Couldn't .UseContentRoot(Directory.GetCurrentDirectory()) in Main() be set as the default in WebHostBuilder? That's the default for almost everybody anyway, isn't it? If people want to change this, they can still do by calling it explicitly with a different path.

This way, this line could be completely removed from the template.

该提问来源于开源项目:aspnet/Hosting

  • 点赞
  • 写回答
  • 关注问题
  • 收藏
  • 复制链接分享
  • 邀请回答

8条回答

  • weixin_39560207 weixin_39560207 4月前

    Nope. When you call dotnet run from your project folder without this line, the content root path is in your bin output folder.

    :smile: Ah ... that explains it then. I so seldom use dotnet run that I never noticed that behavior. I took the line out of my apps ages ago and never had a problem as my testing is all IIS-based, either local IIS or on a staging VM under IIS.

    点赞 评论 复制链接分享
  • weixin_39729837 weixin_39729837 4月前

    We didn't want to bake it into the framework because it's not always right. We use the default .dll directory (a very .NETty thing to do). Nothing in ASP.NET wants to assume CWD by default. It's in the template for that very reason. While it's not ideal, it's code in your template so the framework doesn't have to change anything because there's nothing to fix per se.

    if we would do this and someone wants the old behaviour, he would have to call .UseContentRoot(PlatformServices.Default.Application.ApplicationBasePath), right?

    If you remove the call altogether you'll get this behavior by default as stated.

    点赞 评论 复制链接分享
  • weixin_39571219 weixin_39571219 4月前

    Yes, my point is mostly a cosmetic one. Using a template is not required - if you create an app from scratch, thinking about this call is very unlikely. I guess it might also look weird to new users from other languages. It's also about percentages - why not make it the default if maybe >99% need it this way. (this is different to e.g. UseKestrel, which of course is required because it requires a separate assembly)

    The problem with dotnet run is that if you don't have this call and if you use content files like appsettings.json, it will not be able to load them because in the default project.json, these files are only included in publishOptions, not in buildOptions.

    yes, my proposed extension method would only be required, if you would change the default.

    点赞 评论 复制链接分享
  • weixin_39729837 weixin_39729837 4月前

    I guess it might also look weird to new users from other languages.

    we actually looked at what other languages do and nobody has solved this. You usually pass the full path into the specific component trying to do look for things (views/static files/configuration etc).

    The problem with dotnet run is that if you don't have this call and if you use content files like appsettings.json, it will not be able to load them because in the default project.json, these files are only included in publishOptions, not in buildOptions.

    Yes, that was the trade off that was made. We don't want to taint the API to make dotnet run work better without a line of code. It means that you'd have to turn it off in some cases which is harder to discover. It's the reason we print out the full path when things don't resolve so you can see where it's looking. We could do better and tell you which property to set.

    There's another approach you can take with other caveats: Copy the files you need on build to the output folder use the copyToOutput option. It means that you can't see changes until build though...

    点赞 评论 复制链接分享
  • weixin_39571219 weixin_39571219 4月前

    I agree, there's no correct solution!

    My only point is that the framework sets something as the default which doesn't reflect the true usage, so everyone has to override it in his app.

    A similar scenario would be to offer a XmlSerializer and a JsonSerializer, in which the framework sets the XmlSerializer as the default and the template overrides it with the JsonSerializer.

    Having it in the template just to show people that the ContentRoot feature exists, also isn't great. The documentation, IntelliSense and the console output (although this is not visible in IIS) should be enough to find the correct switch, if something must be changed. You also don't e.g. set a fixed serializer in the template just to tell people that they can change the serializer.

    This isn't very important and I don't want to take up too much of your time. Feel free to close this, if you don't see value in discussing/tracking it further!

    点赞 评论 复制链接分享
  • weixin_39560207 weixin_39560207 4月前

    It is. I was never clear on exactly why samples had it. It goes way back to when first had it in cli-samples. After that, it kind'a stuck around everywhere. But yeah ... it defaults to the app base path, so it isn't needed in the default case AFAICT ...

    https://github.com/aspnet/Hosting/blob/14557f01311a72f0cca9ac57e5063057297b3bb5/src/Microsoft.AspNetCore.Hosting/WebHostBuilder.cs#L151

    and

    https://github.com/aspnet/Hosting/blob/14557f01311a72f0cca9ac57e5063057297b3bb5/src/Microsoft.AspNetCore.Hosting/WebHostBuilder.cs#L229-L240

    点赞 评论 复制链接分享
  • weixin_39571219 weixin_39571219 4月前

    Nope. When you call dotnet run from your project folder without this line, the content root path is in your bin output folder.

    Example: Current folder: C:\temp\WebApp Without UseContentRoot(...): C:\temp\WebApp\bin\Debug\netcoreapp1.0 With UseContentRoot(...): C:\temp\WebApp

    So changing this would be a breaking change, but since this is in the default template, it might still be ok to do it?!

    点赞 评论 复制链接分享
  • weixin_39571219 weixin_39571219 4月前

    if we would do this and someone wants the old behaviour, he would have to call .UseContentRoot(PlatformServices.Default.Application.ApplicationBasePath), right?

    This seems a bit verbose/unintuitive, so maybe there could be an extension method for this case - e.g. UseApplicationBasePathAsContentRoot()?

    点赞 评论 复制链接分享

相关推荐