Aspnetcore.docs: Non-web app scenario coverage (console apps, etc.)

Created on 26 Sep 2019  ยท  4Comments  ยท  Source: dotnet/AspNetCore.Docs

In a new ASP.NET Core 3 app, appsettings.json files are created by the template and are copied to output directory by default even though they are not in .csproj. In a .NET Core 3 console app, appsettings.json files have to be manually created and manually set to Content and Copy to Output Directory. After changing those properties on those appsettings files they show up in the .csproj. My application settings weren't loading until I made those property changes, which makes sense because ContentRoot is set to the executable's path (e.g. bin/Debug/netcoreapp3.0).


Document Details

โš  Do not edit this section. It is required for docs.microsoft.com โžŸ GitHub issue linking.

P2 Source - Docs.ms doc-enhancement needs-more-info

Most helpful comment

[@pholly, I generalized the issue title a bit. Great question! (I'd like to know, too! :smile:) btw - The behavior is because the Web SDK handles it, and your console app isn't based on that SDK.]

@pholly touches on larger, general issue for a web app-focused doc set (especially the "extensions" parts of this doc set, such as logging, configuration, etc.) trying to cover non-web app concepts and scenarios. This issue pertains to console apps, but it could be any type of .NET Core app going forward that doesn't use the Web SDK, is made from a template with non-web components, and interacts with API external to the ASP.NET Core engineering team.

Currently, the vast majority of our coverage in the extensions docs is focused on _web app development_. Just to remind everyone: When the config topic was a bunch of console apps, I received complaints from readers about it. Readers wanted web-app focused coverage with web app-focused examples/samples. I made it web app-focused, and web devs took the $$ bounty $$ off my head! ๐Ÿ’€:smile:

When I had a convo with David and Damien on this subject, their plan sounded great: Move the extensions content to the .NET Core doc set and either cross-link framework-specific content in each framework doc set or have the framework-specific docs, examples, and samples in the .NET Core doc set, too. To me, that seemed to compose better and seemed like it would be cheaper ๐Ÿ’ฐ and easier to maintain ๐Ÿ˜…. After that convo tho, a decision was made to go a different way ... a concern of mine. Oh, well ... win some ... lose some. However, the details of the plan are still murky.

Now that the decision has been made to keep the framework extensions docs here ...

  • What's the plan for the content of the extension docs? What are they going to cover in the way of non-web app scenarios, if anything?
  • If they will cover non-web-app scenarios, have any decisions been made on how that goal will be accomplished?

All 4 comments

[@pholly, I generalized the issue title a bit. Great question! (I'd like to know, too! :smile:) btw - The behavior is because the Web SDK handles it, and your console app isn't based on that SDK.]

@pholly touches on larger, general issue for a web app-focused doc set (especially the "extensions" parts of this doc set, such as logging, configuration, etc.) trying to cover non-web app concepts and scenarios. This issue pertains to console apps, but it could be any type of .NET Core app going forward that doesn't use the Web SDK, is made from a template with non-web components, and interacts with API external to the ASP.NET Core engineering team.

Currently, the vast majority of our coverage in the extensions docs is focused on _web app development_. Just to remind everyone: When the config topic was a bunch of console apps, I received complaints from readers about it. Readers wanted web-app focused coverage with web app-focused examples/samples. I made it web app-focused, and web devs took the $$ bounty $$ off my head! ๐Ÿ’€:smile:

When I had a convo with David and Damien on this subject, their plan sounded great: Move the extensions content to the .NET Core doc set and either cross-link framework-specific content in each framework doc set or have the framework-specific docs, examples, and samples in the .NET Core doc set, too. To me, that seemed to compose better and seemed like it would be cheaper ๐Ÿ’ฐ and easier to maintain ๐Ÿ˜…. After that convo tho, a decision was made to go a different way ... a concern of mine. Oh, well ... win some ... lose some. However, the details of the plan are still murky.

Now that the decision has been made to keep the framework extensions docs here ...

  • What's the plan for the content of the extension docs? What are they going to cover in the way of non-web app scenarios, if anything?
  • If they will cover non-web-app scenarios, have any decisions been made on how that goal will be accomplished?

Thanks for the great explanation / follow up! I also noticed I'm in "ASP.NET Core 3.0" documentation and not just ".NET Core 3.0." I like how ASP.NET core bits are now split (Generic Host + ConfigureWebHostDefaults vs Web Host) so it would be nice to have dedicated .NET Core documentation. Some things are just turned on for Web projects and it would be good if they were turned on for any .NET Core project. For example, adding DOTNET_ENVIRONMENT Development for console apps by default, like ASP.NET Core apps have ASPNETCORE_ENVIRONMENT set automatically (at least in Visual Studio).

@danroth27 @mkArtakMSFT @Rick-Anderson This issue isn't actionable without managerial guidance (and time ๐Ÿ•š given that it was assigned to me).

Side Note (maybe I'm beating a dead ๐Ÿด on this one): I'm still concerned about the Host coverage generally (e.g., @Legends remarks)]. I still think that one Host topic that covers the Generic Host with the inner Web Host (IWebHostBuilder) role is the way to go. I suggested that because in spite of all of the "Web Host is gone and not recommended" and "move to the Generic Host" language these days, the IWebHostBuilder is still present and configured (under the Generic Host) via guidance in the Web Host topic.

Anyway ... wrt this issue ... I'll re-assign to @Rick-Anderson given that this is a BIG issue, there isn't final guidance yet on what to do, and we're getting late in the second period ๐Ÿ‰.

Thanks for contacting us. We believe that the question you've raised have been answered. If you still feel a need to continue the discussion, feel free to reopen it and add your comments.

Was this page helpful?
0 / 5 - 0 ratings