1. Starting up the web application with dotnet run
• there are CLI parameters that you can use to set environment, port etc.
• uses Kestrel to host the application
• windows authentication cannot be turned on with dotnet run
• can configure default behavior from within Visual Studio project properties
• Debug, select Launch “Project” then you can set the App Url, default page, etc.
• Hitting debug F5 within Visual Studio when the {Project Name} profile is selected hosts the application on Kestrel similar to dotnet run
• dotnet run –e development will set the environment variable to ‘production’ (
• in the following image you can see that I set the default environment for Kestrel runs to Development
  
  ASPNETCORE_ENVIRONMENT Development
  
  

1. JSON properties are now lower case in asp.net core (i.e. when return json from a method Json({object here}) would have all properties changed to lower case)
• use the following code to avoid camel case names by default 
  services.AddControllersWithViews()
         .AddJsonOptions(options => options.SerializerSettings.ContractResolver = new DefaultContractResolver());
  
  {"Id":9000,"FullName":"John Smith"} would be serialized to {"id":9000,"fullName":"John Smith"}       
2. Debug ASP.NET Core apps in Visual Studio IIS/IISExpress etc. reference here        
3. After setting a application within IIS, setting authentication to windows, selecting application pool with no managed code – you may get the following…
   The in process request handler, Microsoft.AspNetCore.Server.IIS, was not referenced in the application.
   
4. Host ASP.NET Core on Windows with IIS
5. In order to ready http request bodies in a synchronous manner I had to add following service configuration
   
   https://stackoverflow.com/questions/47735133/asp-net-core-synchronous-operations-are-disallowed-call-writeasync-or-set-all
   // If using Kestrel:
   //services.Configure<KestrelServerOptions>(options =>
   //{
   //    options.AllowSynchronousIO = true;
   //});
   
   // If using IIS:
   services.Configure<IISServerOptions>(options =>
   {
       options.AllowSynchronousIO = true;
   })
6. dotnet – info
   
   Shows what versions are installed on your workstation (Reference Rick Strahl)
   
   
7. This looks really interesting but I have yet to install/try it out Live Reload using dotnet watch https://weblog.west-wind.com/posts/2019/Jun/03/Building-Live-Reload-Middleware-for-ASPNET-Core
8. IHostBuilder vs IWebHostBuilder – ASP.NET Core is used to build http endpoints using Kestrel web server. 
   IWebHostbuilder remains for backward compatibility only, and was used to encapsulate DI, Logging and configuration.  This was used in earlier versions of ASP.NET Core 3 for http workloads.
   
   The default .NET Core 3 ASP.NET Core template sets up by default in the program.cs IHostBuilder, which is the recommended for all app types.  Documentation can be found at docs.microsoft.com.  A host can encapsulates dependency injection, logging, configuration, IHostedService implementations.  Hosting is no longer bound to Kestrel and no longer bound to ASP.NET Core (oddly, this means you can start a host that doesn’t require Kestrel and doesn’t even need the ASP.NET Core Framework)
   
   CreateHostBuilder has the following defaults
   - Sets the content root to the path returned by GetCurrentDirectory.
   - Loads host configuration from:
   ----- Environment variables prefixed with "DOTNET_".
   ----- Command-line arguments.

   - Loads app configuration from:
   ----- appsettings.json.
   ----- appsettings.{Environment}.json.
   ----- Secret Manager when the app runs in the Development environment.
   ----- Environment variables.
   ----- Command-line arguments.

   - Adds the following logging providers:
   ----- Console
   ----- Debug
   ----- EventSource
   ----- EventLog (only when running on Windows)

   - Enables scope validation and dependency validation when the environment is Development.

   
   ConfigureWebHostDefaults
   - Loads host configuration from environment variables prefixed with "ASPNETCORE_".
   - Sets Kestrel server as the web server and configures it using the app's hosting configuration providers. For the Kestrel server's default options, see Kestrel web server implementation in ASP.NET Core.
   - Adds Host Filtering middleware.
   - Adds Forwarded Headers middleware if ASPNETCORE_FORWARDEDHEADERS_ENABLED=true.
   - Enables IIS integration. For the IIS default options, see Host ASP.NET Core on Windows with IIS.
   - Configuration for Framework-provided services can be found here (any host lifetime, environment etc.)
9. Unable to resolve service for type 'Microsoft.Extensions.Logging.ILoggerFactory' while attempting to activate 'Web.Startup'. – Exception
   - the startup constructor use to look like public Startup(IConfiguration configuration, ILoggerFactory loggerFactory)
   - new to ASP.NET Core 3 it is no longer possible to inject ILogger in Startup.cs and Program.cs (Reference: Github)
   - Another reference to this change specifically calls this out
10. Changes with ASP.NET Core 3 to Program.cs / Startup.cs
    Reference: Andrew Lock
    

I was trying to determine why my asp.net core application as so slow during startup (F5 w/debugging).  I believe I found one of the reasons.
By default a new asp.net core application has an appsettings.Development.json file.  Within this file there are several settings to set the default log level.  Typically, you will see something like the following

{
  "Logging": {
    "LogLevel": {
       "Default": "Debug",
      "System": "Information",
      "Microsoft": "Information"
    }
  }
}

Keep in mind the order of settings are as follows going from very verbose to turned off.

Trace (Very Verbose)
Debug
Information
Warning
Error
Critical
None

I found that setting my development log settings to anything above Warning improved startup up time significantly!

After I figured out above I did come across a Rick Strahl post.  If you don’t follow Rick do.