Using the overload where the HostBuilderContext is available to support common usage scenarios such as accessing the environment and configuration whilst registering services.
* Updates Identity server dependency for preview4
* Infrastructure improvements.
* Updates react versions.
* Updates migrations.
* Makes templates show up in Visual Studio
* Set CSharpLangVersion during runtime compilation
* Pass CSharpLangVersion inferred by the CSharpCompiler to RazorEngine
* Set GenerateRazorHostingAssemblyInfo in Razor.RuntimeCompilation
targets
* Unskip failing test
Fixes https://github.com/aspnet/AspNetCore/issues/8996
VS 16.1 tooling does not support RazorConfigurations with no extensions
Working around this by treating Blazor templates as using MVC configuration
until we can resolve the issue in tooling
Workaround for https://github.com/aspnet/AspNetCore/issues/9119
* Chain coherent dependencies up through Extensions to EF Core packages
- should reduce incoherent PRs we get from `darc`
- react to AspNetCore-Tooling breaking changes
- use C# Preview version in Blazor integration tests
- update `EnsureOptions_ConfiguresDefaultParseOptions` test to match new C# version default
- react to new newline encoding behavior; thanx @ajaybhargavb!
- update product code and tests to use new GetItem API; thanx @NTaylorMullen!
- RazorProjectFileSystem breaking change
- update ref assemblies
- react to EF Core breaking changes
- react to EF Core method rename
- react to aspnet/EntityFrameworkCore@ccfc5edbc7
- react to aspnet/EntityFrameworkCore@6cb41531df breaking change
- disable new analyzer in `ScratchDatabaseFixture`
- skip `MvcTemplate_NoAuthImplAsync(...)` test for F#
- #8996
- exclude some runtime assemblies from crossgen; thanx @BrennanConroy!
- add direct references to Mvc in AzureAD samples
- unclear why the reference is no longer pulled in transitively
* Run `darc` to grab the latest
- CoreFx packages with version 4.6.0-preview4.19204.1 to ensure coherency
- core-setup packages with version 3.0.0-preview4-27604-05 to ensure coherency
- Extensions packages with verisn 3.0.0-preview4.19204.2 to ensure coherency
- EntityFrameworkCore packages with version 3.0.0-preview4.19204.7 from build 20190404.7
- AspNetCore-Tooling packages with version 3.0.0-preview4.19204.2 from build 20190404.2
* Move contents of Microsoft.AspNetCore.Components.Services namespace to Microsoft.AspNetCore.Components
* Rename Components to Blazor
* Make Blazor server-side part of the shared framework.
* Rename Host.cshtml to _Host.cshtml
* In Startup.cs, specify root component and selector explicitly so you can easily disable prerendering if desired
* Remove unneccesary dependency on NewtonsoftJson package
* Remove unnecessary MapRazorPages and make blank lines consistent
* Rename "Services" subdirectory to "Data"
* Remove favicon.ico (no longer needed since we switched to MapFallbackToPage
* Revert MapComponentHub change due to reasons
* [MVC][Components] Prerendering + Robust reconnect
* Relayers prerendering support on a separate package on top of MVC and
components.
* Implements robust reconects with acknowledgements from the client.
* Improves interactive prerendering with the ability to reconnect to
prerendered components.
* Removes the need to register components statically when prerendering
them.
* Removes the need of using an element selector when prerendering an
interactive component.
* Updates the templates to use the new fallback routing pattern and
reenables the components test.
* Adds eslint to the Typescript project to help maintain a consistent
style.
* Adds logging to support better debugging based on the pattern used by
signalr.
* Fixes exception handling on the server to always report exceptions correctly to the client.
These are *new style* for configuring MVC in services. We're adding these to make
things feel a bit more tailored to those particular scenarios.
----
The main reason for this is that we've had repeated community asks for an
*API-optimized* way of configuring MVC. I don't think that using AddMvcCore
is a suitable building block, because it has too many options that you want.
I've think I've identified the reasonable set of features that should be part
of the default experience for APIs. All of these things are already pay-for-play
and are activated by the presence of attributes. The only additional cost is
loading of assemblies and a few additional inspections of the attributes
(cached).
----
Additionally the AddControllers experience is composible. You can add views
to it, or add pages and get the whole thing.
AddRazorPages is basically an alias for what AddMvc does today. We don't
currently have a way to add pages without controllers (the opposite is true).
Based on feedback we could specialize this more.
----
Branding and perception are important, and we've users ask for more flexibility
in what gets added. The plan is to update the templates to use this experience
in preview4, and see what kind of feedback we get.
* Make endpoint middleware explicit
This change makes the endpoint middleware explicit again, and updates
all of the templates.
The other change here is make UseEndpoints be the place where you
register endpoints. This is vital because it puts your code visually at
the point of the pipeline where it executes.
Lastly, I removed support for UseMvc with endpoint routing. This is
causing issues for some security features, and we're moving in the
direction of trying to make the middleware heavy implementation required
in 3.0. There are some issues we won't be able to fix in MVC if we can't
unambiguously know if UseMvc was used or the middleware.
John Luo
Ryan Brandenburg
Howard Richards
Mikael Mengistu
Nate McMaster
Neil Bostrom
Steve Gordon
Javier Calvarro Nelson
James Newton-King
Artak Mkrtchyan
Pranav K
Steve Sanderson
Doug Bunting
Artak
Justin Kotalik
Ryan Nowak
Adrian Wright