* Spruce up async handling in OnNavigateAsync
* Apply suggestions from code review
Co-authored-by: Günther Foidl <gue@korporal.at>
* Ensure previous task awaited before starting next one
* Apply suggestions from code review
Co-authored-by: Pranav K <prkrishn@hotmail.com>
* Validate no exceptions throw on multiple invocations
* Address feedback from peer review
Co-authored-by: Günther Foidl <gue@korporal.at>
Co-authored-by: Pranav K <prkrishn@hotmail.com>
* Add sharedfx and targeting pack tests (#23045)
* Add test for assembly versions
* Add test for framework list
* Add some hardcoded lists for sharedfx and targeting pack content
* Fix failing tests
* Fix targeting pack tests
* Feedback
* Move to latest NuGet.exe
- 5.3.0 -> 5.6.0
- should improve performance and may improve reliability
* Also switch from NuGet.Build.Tasks to NuGet.Packaging
- move to 5.6.0 version here too
- reduce transitive dependencies; we don't need them all
* Migrated protected browser storage.
* Added E2E tests.
* Added safeguard against using ProtectedBrowserStorage in wasm.
* Added TryGetValue.
* Added Microsoft.AspNetCore.Components.Web.Extensions
* Minor cleanup
* Moved ProtectedBrowserStorage out of Web.JS.
* Delete Microsoft.AspNetCore.Components.Web.Extensions.netcoreapp.cs
* Updated ProjectReferences.props
* Improvements and cleanup.
* Update Microsoft.AspNetCore.Components.Web.Extensions.csproj
* Added Web.Extensions to the VS solution.
* Prepare for strict coherency
Strict coherency means that if your repo declares a dependency with a CPD attribute, the CPD parent must have a direct dependency on that dependency.
This means for aspnetcore that it should add a dependency on System.Resources.Extensions because aspnetcore-tooling needs it.
Reasons for this approach over the current approach:
- This eliminates some ambiguous tie-breaking scenarios that are very problematic and dangerous in servicing
- Those tie breaking scenarios require the use of BAR to break the ties. If the DB data were to be lost then the tie-breaking would do unexpected things.
* Add framework support for lazy-loading assemblies on route change
* Configure lazy-loaded assemblies in WebAssemblyLazyLoadDefinition
* Move tests to WebAssembly-only scenarios
* Refactor RouteTableFactory and add WebAssemblyDynamicResourceLoader
* Address feedback from peer review
* Rename 'dynamicAssembly' to 'lazyAssembly' and address peer review
* Add sample with loading state
* Update Router API and assembly loading tests
* Support and test cancellation and pre-rendering
* Apply suggestions from code review
Co-authored-by: Steve Sanderson <SteveSandersonMS@users.noreply.github.com>
* Spurce up API and add tests for pre-rendering scenario
* Use CT instead of CTS in NavigationContext
* Address feedback from peer review
* Remove extra test file and update Router
Co-authored-by: Steve Sanderson <SteveSandersonMS@users.noreply.github.com>
All rules are currently disabled, except for one that I enabled for
src/Http via a new ".editorconfig" file I added there.
Other changes:
* Allow editorconfigs in MVC and Razor to flow to the root
* Consolidate a few editorconfig settings
* Tweak Ruleset config in Azure/AzureAD where it clashed.
Addresses the beginning of #9620, but it's a fair chunk of work to
enable most rules through the whole repo. That can be done directory by
directory and rule by rule by dropping .editorconfig files though.
* Tweaks to make dotnet-watch run faster
* Previously dotnet-watch calculated the watch file list on every run by invoking MSBuild. This
changes the tool to only calculate it if an MSBuild file (.targets, .props, .csproj etc) file changed
* For dotnet watch run and dotnet watch test command, use --no-restore if changed file is not an MSBuild file.
* Add opt-out switch
* Update src/Tools/dotnet-watch/README.md
* Fixup typo
* Update src/Tools/dotnet-watch/README.md