Update the certificate loader to support the following scenarios:

{
    "Authentication": {
        "Identity": {
            "SigningCertificates": { // Multiple inline
                "MySigningCert1": {
                    "Source": "File",
                    "Path": "cert1.pfx",
                    "Password": "*****"
                },
                "MySigningCert1": {
                    "Source": "File",
                    "Path": "cert2.pfx",
                    "Password": "*****"
                }
            }
        }
    }
}

{
    "Authentication": {
        "Identity": {
            "SigningCertificates": { // Single inline
                "Source": "File",
                "Path": "cert1.pfx",
                "Password": "*****"
            }
        }
    }
}

{
    "Certificates": {
        "MySigningCert1": {
            "Source": "File",
            "Path": "cert1.pfx",
            "Password": "*****"
        },
    },
    "Authentication": {
        "Identity": {
            "SigningCertificates": "MySigningCert1" // Single referenced
        }
    }
}

{
    "Certificates": {
        "MySigningCert1": {
            "Source": "File",
            "Path": "cert1.pfx",
            "Password": "*****"
        },
        "MySigningCert2": {
            "Source": "File",
            "Path": "cert2.pfx",
            "Password": "*****"
        }
    },
    "Authentication": {
        "Identity": {
            "SigningCertificates": "MySigningCert1 MySigningCert2" // Multiple referenced, space separated
        }
    }
}

When unnetcoreappifying our libraries we didn't also enable our SHA256.Create() implementations to work under the desktop framework. To do this you need to change SHA256.Create() the to the following:

public static SHA256 CreateSHA256()
{
	SHA256 sha256;

	try
	{
		sha256 = SHA256.Create();
	}
	// SHA256.Create is documented to throw this exception on FIPS compliant machines.
	// See: https://msdn.microsoft.com/en-us/library/z08hz7ad%28v=vs.110%29.aspx?f=255&MSPPError=-2147217396
	catch (System.Reflection.TargetInvocationException)
	{
		// Fallback to a FIPS compliant SHA256 algorithm.
		sha256 = new SHA256CryptoServiceProvider();
	}

	return sha256;
}

@JunTaoLuo for the one location that uses SHA256.Create() is this a problem? If not, feel free to close this issue.

Workaround dotnet/sdk#1166.

We should set PrivateAssets=Build on our reference to SQLitePCLRaw.bundle_green

cc @bricelam @Eilon

The templates are going to enable SSL via config in dev and production. They need to set up the rest of the endpoints when they do this. #44 added the ability to bind to IPs and ports, but that makes for a poor user experience. In dev the templates want localhost, but will have to specify 127.0.0.1 (and ::1) if they want IPv6 support. In production they'll need to specify a public IP (0.0.0.0 and ::0).

Config should allow localhost that binds to 127.0.0.1 and ::1, and * that binds to 0.0.0.0 and ::0, using the same logic that kestrel applies to UseUrls values. Even better, implement this in Kestrel with a Listen that takes the string ip/host so you don't have to duplicate all of the logic.

In #55, we are now trimming by all manifests. This is due to a few limitations:

1. dotnet sdk publish targets resolves manifest files as a global item group so we need to set the TargetManifestFiles property in a global property group to ensure it is used. The dotnet sdk should be resolving the list of manifest files in the targets which uses them (will file a bug for this).
2. There is no cross-platform backwards compatible way of determining the os and platform outside of an MSBuild target.

Though in theory, trimming by all manifests should be correct, we may want to be more specific with which manifest to trim by in the future. If we decide to keep this behaviour, we should at least consolidate all manifests into a singular file.

Bump up the dependencies that we're releasing as part of this patch release.

cc @Eilon @DamianEdwards

Microsoft.AspNetCore.dll should not be in the package.

@pranavkm @davidfowl @BrennanConroy

Repro

<Project Sdk="Microsoft.NET.Sdk.Web">
  <PropertyGroup>
    <TargetFramework>netcoreapp2.0</TargetFramework>
  </PropertyGroup>
  <ItemGroup>
    <PackageReference Include="Microsoft.AspNetCore.All" Version="2.0.0-preview1-24785" />
  </ItemGroup>
</Project>

dotnet restore
dotnet publish

Expected
Publish works.

Actual
Publish fails.

/usr/share/dotnet/sdk/2.0.0-preview2-005905/Sdks/Microsoft.NET.Sdk/build/Microsoft.NET.Publish.targets(252,5): error MSB4018: The "ResolvePublishAssemblies" task failed unexpectedly. [/app/app1
493666299.csproj]
/usr/share/dotnet/sdk/2.0.0-preview2-005905/Sdks/Microsoft.NET.Sdk/build/Microsoft.NET.Publish.targets(252,5): error MSB4018: System.IO.FileNotFoundException: Could not find file '/root/.nuget/
packages/microsoft.aspnetcore.all/2.0.0-preview1-24785/build/manifest.win-x64.xml'. [/app/app1493666299.csproj]
/usr/share/dotnet/sdk/2.0.0-preview2-005905/Sdks/Microsoft.NET.Sdk/build/Microsoft.NET.Publish.targets(252,5): error MSB4018: File name: '/root/.nuget/packages/microsoft.aspnetcore.all/2.0.0-pr
eview1-24785/build/manifest.win-x64.xml' [/app/app1493666299.csproj]

Currently only building package cache for win7-x64

• Create a new Microsoft.AspNetCore.Configuration that will contain all of our default config schema/setup which lives only in the meta package.
• It will provide a single services.ConfigureAspNetDefaults() [naming TBD] which will add all of the default config conventions, none of the existing AddXyz() methods will use IConfiguration (and we should potentially remove any overloads that exist today)
• Implementation detail: a ConfigureAspNet that implements IConfigureOptions for all things we want to configure by default
• For preview 2, this will consist of whatever is being configured in the templates today (Authentication, IdentityService, Kestrel)
• Longer term: Have intellense/schema for the important config settings.
• The structure of the config will be nested: example using today’s indidual Auth template

  "Microsoft": {
    "Logging": {
      "IncludeScopes": false,
      "Debug": {
        "LogLevel": {
          "Default": "Warning"
        }
      },
      "Console": {
        "LogLevel": {
          "Default": "Warning"
        }
      }
    },
    "AspNetCore": {
      "Authentication": {
        "IdentityService": {
          "ClientId": "C06ACE17-3212-454B-84AB-14DDB2FC58E0",
          "TokenRedirectUrn": "urn:self:aspnet:identity:integrated"
        }
      },
      "Hosting": {
        "Kestrel": { // https://github.com/aspnet/MetaPackages/blob/dev/src/Microsoft.AspNetCore/KestrelServerOptionsSetup.cs
          "Endpoints": {
            "Localhost": {
              "Address": "127.0.0.1",
              "Port": "5000"
            },
            "LocalhostWithHttps": {
              "Address": "127.0.0.1",
              "Port": "44333",
              "Certificate": {
                "Source": "Store",
                "StoreLocation": "LocalMachine",
                "StoreName": "My",
                "Subject": "CN=localhost"
              }
            }
          }
        }

Currently if you have a kestrel endpoint configured with a named certificate that isn't configured for the current environment you get an exception telling you that the certificate is missing. We should handle this exception and provide a reasonable error message to the user.

Current behavior:

~\Desktop\templates2\mvc-individual> $env:ASPNETCORE_ENVIRONMENT=""
~\Desktop\templates2\mvc-individual> dotnet run

Unhandled Exception: System.InvalidOperationException: No certificate named HTTPS found in configuration
   at Microsoft.AspNetCore.KestrelServerOptionsSetup.<>c__DisplayClass4_0.<BindEndPoint>b__0(ListenOptions listenOptions)
   at Microsoft.AspNetCore.Server.Kestrel.Core.KestrelServerOptions.Listen(IPEndPoint endPoint, Action`1 configure)
   at Microsoft.AspNetCore.KestrelServerOptionsSetup.BindEndPoint(KestrelServerOptions options, IConfigurationSection endPoint, Dictionary`2 certificates)
   at Microsoft.AspNetCore.KestrelServerOptionsSetup.BindConfiguration(KestrelServerOptions options)
   at Microsoft.Extensions.Options.LegacyOptionsCache`1.CreateOptions()
   at System.Threading.LazyInitializer.EnsureInitializedCore[T](T& target, Boolean& initialized, Object& syncLock, Func`1 valueFactory)
   at Microsoft.Extensions.Options.LegacyOptionsCache`1.get_Value()
   at Microsoft.AspNetCore.Server.Kestrel.Core.KestrelServer.CreateServiceContext(IOptions`1 options, ILoggerFactory loggerFactory)
   at Microsoft.AspNetCore.Server.Kestrel.Core.KestrelServer..ctor(IOptions`1 options, ITransportFactory transportFactory, ILoggerFactory loggerFactory)
--- End of stack trace from previous location where exception was thrown ---
   at System.Runtime.ExceptionServices.ExceptionDispatchInfo.Throw()
   at Microsoft.Extensions.DependencyInjection.ServiceLookup.CallSiteRuntimeResolver.VisitConstructor(ConstructorCallSite constructorCallSite, ServiceProvider provider)
   at Microsoft.Extensions.DependencyInjection.ServiceLookup.CallSiteRuntimeResolver.VisitScoped(ScopedCallSite scopedCallSite, ServiceProvider provider)
   at Microsoft.Extensions.DependencyInjection.ServiceProviderServiceExtensions.GetRequiredService(IServiceProvider provider, Type serviceType)
   at Microsoft.Extensions.DependencyInjection.ServiceProviderServiceExtensions.GetRequiredService[T](IServiceProvider provider)
   at Microsoft.AspNetCore.Hosting.Internal.WebHost.EnsureServer()
   at Microsoft.AspNetCore.Hosting.Internal.WebHost.BuildApplication()
   at Microsoft.AspNetCore.Hosting.WebHostBuilder.Build()
   at mvc_individual.Program.BuildWebHost(String[] args)
   at mvc_individual.Program.Main(String[] args)

Proposed behavior:

~\Desktop\templates2\mvc-individual> $env:ASPNETCORE_ENVIRONMENT=""
~\Desktop\templates2\mvc-individual> dotnet run

No certificate named HTTPS found in configuration for the current environment (Production). For information on configuring HTTPS see https://go.microsoft.com/fwlink/?linkid=848054.

The check-in went in, but we didn't validate it yet.

Repro:

• Clone MusicStore
• change directory to samples\MusicStore
• Change the samples\MusicStore.csproj tfms to only have net46
• dotnet restore
• dotnet build

Expected:
build succeeds

Actual:
build fails

Models\ManageViewModels.cs(2,29): error CS0234: The type or namespace name 'DataAnnotations' does not exist in the namespace 'System.ComponentModel' (are you missing an assembly reference?) [C:\github\musicstore\samples\MusicStore\MusicStore.csproj]
Models\ManageViewModels.cs(3,17): error CS0234: The type or namespace name 'AspNetCore' does not exist in the namespace 'Microsoft' (are you missing an assembly reference?) [C:\github\musicstore\samples\MusicStore\MusicStore.csproj]
Models\ManageViewModels.cs(4,17): error CS0234: The type or namespace name 'AspNetCore' does not exist in the namespace 'Microsoft' (are you missing an assembly reference?) [C:\github\musicstore\samples\MusicStore\MusicStore.csproj]
Models\ManageViewModels.cs(5,17): error CS0234: The type or namespace name 'AspNetCore' does not exist in the namespace 'Microsoft' (are you missing an assembly reference?) [C:\github\musicstore\samples\MusicStore\MusicStore.csproj]
Models\MusicStoreContext.cs(1,17): error CS0234: The type or namespace name 'AspNetCore' does not exist in the namespace 'Microsoft' (are you missing an assembly reference?) [C:\github\musicstore\samples\MusicStore\MusicStore.csproj]
Models\MusicStoreContext.cs(2,17): error CS0234: The type or namespace name 'EntityFrameworkCore' does not exist in the namespace 'Microsoft' (are you missing an assembly reference?) [C:\github\musicstore\samples\MusicStore\MusicStore.csproj]
Models\Order.cs(2,29): error CS0234: The type or namespace name 'DataAnnotations' does not exist in the namespace 'System.ComponentModel' (are you missing an assembly reference?) [C:\github\musicstore\samples\MusicStore\MusicStore.csproj]
Models\Order.cs(3,17): error CS0234: The type or namespace name 'AspNetCore' does not exist in the namespace 'Microsoft' (are you missing an assembly reference?) [C:\github\musicstore\samples\MusicStore\MusicStore.csproj]
Models\SampleData.cs(6,17): error CS0234: The type or namespace name 'AspNetCore' does not exist in the namespace 'Microsoft' (are you missing an assembly reference?) [C:\github\musicstore\samples\MusicStore\MusicStore.csproj]
Models\SampleData.cs(7,17): error CS0234: The type or namespace name 'AspNetCore' does not exist in the namespace 'Microsoft' (are you missing an assembly reference?) [C:\github\musicstore\samples\MusicStore\MusicStore.csproj]
Models\SampleData.cs(8,17): error CS0234: The type or namespace name 'EntityFrameworkCore' does not exist in the namespace 'Microsoft' (are you missing an assembly reference?) [C:\github\musicstore\samples\MusicStore\MusicStore.csproj]
Models\SampleData.cs(9,17): error CS0234: The type or namespace name 'Extensions' does not exist in the namespace 'Microsoft' (are you missing an assembly reference?) [C:\github\musicstore\samples\MusicStore\MusicStore.csproj]
Models\SampleData.cs(10,17): error CS0234: The type or namespace name 'Extensions' does not exist in the namespace 'Microsoft' (are you missing an assembly reference?) [C:\github\musicstore\samples\MusicStore\MusicStore.csproj]

@JunTaoLuo

I created a 1.1.1 template and upgraded to 2.0 and used the new API the got this error:

It's pretty awful that this throws like that by default. Is there any way to avoid this exception and have it noop (like the other config providers do) if the application isn't configured for user secrets?

/cc @natemcmaster

Instead of doing it in templates, we're going to do it in WebHost.CreateDefaultBuilder

cc @DamianEdwards

Need to find out why we are running into the error

Unable to load Microsoft.DiaSymReader.Native.amd64.dll.  Please ensure that Microsoft.DiaSymReader.Native.amd64.dll is on the path.  Error='126'
Error generating PDB for 'C:\gh\MetaPackages2\src\Microsoft.AspNetCore.RuntimeStore\bin\work\Build.RuntimeStore.References_2.0.0-preview2--\runtimopt\SQLitePCLRaw.core.dll': The specified module could not be found. (Exception from HRESULT: 0x8007007E)

and revert #134

These are clones of the tool from the dotnet/cli builds. We should be consuming their tools or build ours periodically in case we need updates. These tools do not belong in the metapackages repo and we should remove them.

cc @anurse

[Microsoft.AspNetCore.Tests.WebHostFunctionalTests.BindsKestrelHttpsEndPointFromConfiguration_ReferencedCertificateFile]
System.PlatformNotSupportedException : This platform does not support loading with EphemeralKeySet. Remove the flag to allow keys to be temporarily created on disk.

[Microsoft.AspNetCore.Tests.WebHostFunctionalTests.BindsKestrelHttpsEndPointFromConfiguration_InlineCertificateFile]
System.PlatformNotSupportedException : This platform does not support loading with EphemeralKeySet. Remove the flag to allow keys to be temporarily created on disk.

http://aspnetci/viewLog.html?buildId=214187&buildTypeId=XPlat_Mac_MacUniverseCoreCLR&tab=buildLog&filter=err#_focus=358135

Add new static API WebHost to support creating opinionated instances of IWebHost and IWebHostBuilder which default the following over and above the usual defaults:

• Server to Kestrel
• Content root to working directory
• Other ideas for defaults (in ascending order of craziness):
  • Log to console
  • Add cmd line and environment variable configuration providers, maybe even JSON for appsettings.json and appsettings.[environment].json too
  • Add the developer exception page middleware via an IStartupFilter by default when IHostingEnvironment.IsDevelopment()

There would be methods that allow building and starting an IWebHost with one call, and another that allows creating an IWebHostBuilder for more advanced scenarios, e.g. setting up configuration, logging, etc.

namespace Microsoft.AspNetCore
{
    public static class WebHost
    {
        public static IWebHost Start(RequestDelegate app) { }

        public static IWebHost Start(string url, RequestDelegate app) { }

        public static IWebHost StartWith(Action<IApplicationBuilder> app) { }

        public static IWebHost StartWith(string url, Action<IApplicationBuilder> app) { }
        
        public static IWebHostBuilder CreateBuilder() { }
    }
}

They would be used like so:

namespace MyApp
{
    public static class Program
    {
        public static void Main(string[] args)
        {
            // Hello, World!
            var host1 = WebHost.Start(context => context.Response.WriteAsync("Hello, World!"));
            host1.WaitForShutdown();

            // Hello, World! + middleware
            var host2 = WebHost.StartWith(app =>
            {
                var env = app.ApplicationServices.GetService<IHostingEnvironment>();
                if (env.IsDevelopment())
                {
                    app.UseDeveloperExceptionPage()
                }
                
                app.Run(context => context.Response.WriteAsync("Hello, World!"))
            );
            host2.WaitForShutdown();

            // Getting a builder to do something more complex, the templates would do this
            var host3 = WebHost.CreateBuilder()
                .UseLogging(logging => logging
                    .AddConsole()
                    .AddDebug()
                )
                .UseStartup<Startup>()
                .Build();
            host3.Run();
        }
   }
}

Some slightly more audacious ideas

Add overloads that allow easy creation of an app that uses a single routed middleware:

public static IWebHost Start(Action<IRouteBuilder> routes) { }
public static IWebHost Start(string url, Action<IRouteBuilder> routes) { }

Used like so:

namespace MyApp
{
    public static class Program
    {
        public static void Main(string[] args)
        {
            // Routed middleware
            var host = WebHost.Start(router => router
                .MapGet("/hello/{name}", (req, res, data) => res.WriteAsync($"Hello, {data["name"]}))
                .MapGet("/goodbye/{name}", (req, res, data) => res.WriteAsync($"Goodbye, {data["name"]}))
                .MapGet("/{greeting}/{name}", (req, res, data) => res.WriteAsync($"{greeting}, {data["name"]}))
                .MapGet("/", (req, res, data) => res.WriteAsync($"Hello, World!"))
           );
            host.WaitForShutdown();
        }
   }
}

@davidfowl @glennc
aspnet/Hosting#991

Tracking issues regarding inclusion of our packages in the metapackage:

• aspnet/AzureIntegration#20. This doesn't block the inclusion of the affected package in the cache but we will be cross-gen'ing the 1.0.0 and 2.0.0 versions of Hosting and a few other packages until the dependency is updated
• Azure/azure-sdk-for-net#3003. Blocking inclusion of Microsoft.Extensions.Configuration.AzureKeyVault
• aspnet/DataProtection#217. Blocking inclusion of Microsoft.AspNetCore.DataProtection.AzureStorage
• Coherence needs to pass after AzureIntegration renames. Blocking inclusion of AzureIntegration packages.

HttpClientSlim was copied from Kestrel to unblock the CI. The proper fix is to move it to Testing and have both Kestrel and MetaPackages consume it from there.

Currently WebHost uses the CertificateLoader to aggressively load all certificates in the Certificate section when setting up an HTTPS endpoint. It should only load the certificate needed.

The manifest file included in the Microsoft.AspNetCore.All that is used by default during publish doesn't currently have a descriptive name. The file name is displayed as part of the error message the dotnet host displays in the case an application is published using a manifest and then when run and can't find an assembly, so this name should be descriptive to make it easier for customers to determine the issue.

Let's rename them in accordance with the new component naming & versioning spec, e.g.: aspnetcore-store-2.0.0-preview1-final-win7-x64.xml

Handle "ASP.NET/2.0.0" TargetManifest values from the project file, and map them to the path of the corresponding manifest file.

Proposal: Microsoft.Extensions.Configuration.Certificates

Bump up the dependencies that we're releasing as part of this patch release.

cc @Eilon @DamianEdwards

We also need to create script for Linux users to bring these installers down to the user's machines.

• Make the LTS version: 1.0.1 and depend on latest LTS packages (this is already the case in rel/1.0.1 I believe)
• Make the FTS version: 1.1.0, and we'll RTM with the rest of the packages in 1.1.0 RTM
• Remove NetCoreApp stuff from FTS
• Update aspnet/coherence/packages/packages.csv to mark this as "shipping"
• Update musicstore to use the metapackage

After the target was added in #20. It is not currently trimming the publish output.

Listing out bugs as I find them setting up another e2e.

• HostingStartup.Template is being included in the lightup deps file.
• Microsoft.CSharp 4.3.0 is being resolved and cannot be found.

@muratg

Repro Steps:

1. Create new .NET Console Core app
2. Change target framework to net461
3. Add reference to Microsoft.AspNetCore.All
4. Restore

Expected behavior: Error of some kind

Actual behavior: It references the package "successfully" but silently fails to bring in any types.

We have a build\PublishWithAspNetCoreTargetManifest.targets file, which means NuGet thinks the package is supported by all frameworks (with a special targets file for netcoreapp2.0). We should put that file in build\netcoreapp2.0 so NuGet will see that there are no assets for any other framework.

Also, we need to verify that NuGet does actually disallow installing it in that circumstance. It's possible it won't disallow it, just won't reference the targets files. In that case, we could put a fallback targets file with an error message.

From @danroth27 on April 17, 2017 20:5

Since config is in DI now by default we should support binding the Kestrel options to config by default (for UseKestrel()).

  "Kestrel": {
    "Endpoints": [ // Order matters!
      {
        "Address": "localhost",
        "Port": "44316",
        "Certificate": { // Implies HTTPS
          "Subject": "danroth27.com", // Pick the cert that matches the subject name with the latest expiry
          "StoreName": "My",
          "StoreLocation": "CurrentUser"
        }
      },
      {
        "Address": "localhost",
        "Port": "8080"
      },
      {
        "Address": "localhost",
        "Port": "44317",
        "Certificate": {
          "Path": "./mysslcert.pfx",
          "Password": "abc!123" // In user secrets: Kestrel:Endpoints:2:Certificate:Password
        }
      }
    ]
  }

Copied from original issue: aspnet/KestrelHttpServer#1703

Only the packages Microsoft.AspNetCore and Microsoft.AspNetCore.All belong in this folder since they are shipping packages. The rest are use for builds or are tools and we should move them out of src/.

Our docker images don't have unzip installed. If we produce a tarball instead, then we can use tar to extract the package cache.

cc @JunTaoLuo

Is there any reason KestrelServerOptionsSetup is internal, not public?

Currently, if you wish to tweak the setup made by ConfigureDefaultBuilder, you can copy and paste the whole method into your own app, with the exception of the final call on the IWebHostBuilder:

.ConfigureServices(services =>
                {
                    services.AddTransient<IConfigureOptions<KestrelServerOptions>, KestrelServerOptionsSetup>();
                });

Just making KestrelServerOptionsSetup public would make copy-paste feasible. I can't see any reason why it would be a problem?

I didn't see this mentioned anywhere here or over in the Logging repo. Looks like the new WebHost.CreateDefaultBuilder method adds a console logger... but for production scenarios isn't the console logger really slow? I know the logger was improved to use a background thread, but the perf metrics mentioned over in the logging repo here don't seem to indicate a speedup.

Am I missing something? Thanks!

@glennc said we may or may not need to do this...

Currently the package runtime store build is set up to run the build package store target as part of the entire build lifecycle. However, this step is unrelated to the rest of the build steps. It could save some time and resources by just

Right now it gets the certificate by subject name, and chooses the one whose expiry is furthest in the future. However it doesn't check the purposes, or EKU so you could end up with a certificate which, whilst still valid in terms of expiry, is not valid for HTTPS binding.

In addition the setup, with the current Individual Auth templates, breaks Update-Database through the package manager window because this runs in a production environment, and there is not production config. So, when Update-Database attempts to run through whatever initialization it uses it hits the kestrel certificate setup, can't find any configuration and throws

System.InvalidOperationException: Unable to configure HTTPS endpoint. For information on configuring HTTPS see https://go.microsoft.com/fwlink/?linkid=848054. ---> 
System.Collections.Generic.KeyNotFoundException: No certificate named 'HTTPS' found in configuration for the current environment (Production).

Even when you manually copy the development config to production.config to get your database created you end up with another error from data protection.

PM> Update-Database 
rosoft.AspNetCore.DataProtection.KeyManagement.XmlKeyManager[0]
Update-Database : Exception calling "Substring" with "1" argument(s): "StartIndex cannot be less than zero.
Parameter name: startIndex"
At line:1 char:1
+ Update-Database
+ ~~~~~~~~~~~~~~~
    + CategoryInfo          : NotSpecified: (:) [Update-Database], MethodInvocationException
    + FullyQualifiedErrorId : ArgumentOutOfRangeException,Update-Database

So right now a new user is going to be blocked when starting a new project.

Once we release the WebHost static APIs, we should generate an API baseline.

Most of the information from M.A.All comes from the packages.csv so to reduce duplication, we should generate the project file from it.

We basically need to add a call to logging.AddConfiguration(hostingContext.Configuration.GetSection("Logging")); at https://github.com/aspnet/MetaPackages/blob/dev/src/Microsoft.AspNetCore/WebHost.cs#L167

@glennc @JunTaoLuo @BrennanConroy

Follow up to #61

We should split the build into Coherence-PackageCache win-x86 and Coherence-PackageCache win-x64 to parallelize the build on the CI. Currently this configuration takes 45 mins which is much too long compared to linux and osx which take about 12 mins.

All of our templates create the default builder and then call UseStartup<Startup>. We should consider just making this a one-liner

Follow up to #154 (comment). Currently this depends on Coherence-Signed, we want to be able to run this locally with unsigned bits when building from source.

aspnet/AzureIntegration#54
Microsoft.AspNetCore.ApplicationInsights.HostingStartup
Microsoft.AspNetCore.AzureAppServices.HostingStartup

Should be added to Microsoft.AspNetCore.All. This will reduce the likelyhood of version conflicts.

Should it use PrivateAssets=compile?