* Revert "Hoist activity fields to the logging scope (#11211)"
This reverts commit f7a2d3c26c.
* Remove tests with Activity
* Remove ActivityId from HostingLogScope
* Enable propogation in CreateDefaultBuilder
* Clean up
* s/logging/loggingBuilder
* Enable Activity propogation for generichost
* Replace with runtime/pull/37892
* Enable `/warnAsError` in Windows builds
- already enabled in non-Windows builds because override existed only in build.ps1
* Allow some warnings related to closed issues
- common `<NoWarn>$(NoWarn);CS1591</NoWarn>` case unchanged
- /Directory.Build.props ensures that warning remains a warning but doesn't hide it
* !fixup! Root build.sh _does_ disable warnings as errors
- variable eng/common/tools.sh uses named `warn_as_error`
HTTP/2 over TLS is not compatible with Windows versions strictly older than Windows 10 or Windows Server 2016. Update kestrel to:
- Downgrade to HTTP/1.1 when Http1AndHttp2 is configured.
- Throw NotSupportedException when Http2 is configured.
- Allow HTTP/2 over TLS to be enabled if AppContext switch Microsoft.AspNetCore.Server.Kestrel.EnableWindows81Http2 is set. This allows users who have configured cipher suites on Windows 8.1 and Windows Server 2012 R2 to continue using HTTP/2 over TLS.
* nit: Remove useless `$(HasReferenceAssembly)` settings
- set in /Directory.Build.targets
- `true` only in `$(IsAspNetCoreApp)` projects
* nit: Remove useless `$(CompileUsingReferenceAssemblies)` settings
- no current versioning differences between ref/ and src/ assemblies when targeting default TFM
* Add more `$(GenerateDocumentationFile)` settings
- increases the number of generated doc files, mostly without problems
- !fixup! correct typo in `DebugProxyHost` doc comments
- was not generating a doc file before
- remove previous (ineffective) src/Components/Directory.Build.targets setting
- nit: remove a duplicate `$(GenerateDocumentationFile)` setting
* nit: Remove useless `$(IsPackable)` settings
- only analyzers and implementation projects are packable by default
- main use case for explicit setting is projects shipping only in shared framework
- conditional setting in src/Mvc/Directory.Build.props just subset logic in /Directory.Build.targets
* nit: Remove useless `$(IsProjectReferenceProvider)` settings
- only implementation projects are providers by default
* nit: Remove useless `$(IsTestAssetProject)` settings
- set in src/Mvc/test/WebSites/Directory.Build.props
* !fixup! Looks like `InProcessNewShimWebSite` must compile w/o ref/ assemblies
- restore `$(CompileUsingReferenceAssemblies)` in this one project
- Enabled Helix for:
- `Microsoft.AspNetCore.Mvc.Razor.Extensions.Test`
- `Microsoft.AspNetCore.Mvc.Razor.Extensions.Version1_X.Test`
- `Microsoft.AspNetCore.Mvc.Razor.Extensions.Version2_X.Test`
- These tests depended on our MVC shim project's deps.json's to exist in the test bin directory during publish. Therefore added an additional target copy over those assets at publish time.
- There were some tests that were relying on source positions from a string to match a runtime generated source position. In Helix dll's are built on Windows (string's get compiled with \r\n) and then deployed to potentially non-Windows boxes resulting in mismatches of expectations. To address this I changed the test that had this dependency to dynamically generate the input string.
- Our common language test project used to rely on test files being on disk. At some point in the past those test files started being embedded in the assembly but we maintained directory checking logic to ensure various directories existed on disk (no longe required). Changed the logic to not enforce directories to be on disk (they aren't in Helix) and instead only rely on the embedded TestFiles.
dotnet/aspnetcore#22100
* Update PhoneNumberTokenProvider.cs
Add license header.
Hyphenate two-factor authentication in documentation.
Add line breaks before return statements.
Use string interpolation instead of string concatenation.
The second `VarInt` example has `0x80 0x25` is represented as (`%10000000 %00101001`) which when decoded becomes 0x1480 (5248)
When trying to implement `VarInt` encoding and decoding myself I found that `0x25` is actually `%00100101` instead of `%00101001` which causes the final decoded `VarInt` to be incorrect.
The proper hex value for the binary `%00101001` is `0x29`
* Add an option to configure the NewtonsoftJson buffer size
Contributes to https://github.com/dotnet/aspnetcore/issues/21245
* Update src/Mvc/Mvc.NewtonsoftJson/src/MvcNewtonsoftJsonOptions.cs
Co-authored-by: Stephen Halter <halter73@gmail.com>
Co-authored-by: Stephen Halter <halter73@gmail.com>
This additionally gets rid of an extra whole buffer allocation in the ParserContext. The most complex bit of the change is around avoiding TextLineCollection.GetLocation.
Overall, I'm seeing a pretty big win here, about 35% less time spent in RazorSyntaxTree.Parse for the typing scenario I was doing in a very large file.
We've already shipped a 3.2.0 version of the package. The build's currently producing
3.1.6 version of the package. This changes the package version to 3.2.1
This method allocated multiple strings on every invocation when they were rarely needed. With this change, I see a reduction in memory allocated during RazorProjectEngine.ProcessDesignTime of 1.4%.
This is the last of the easy wins that I could find for typing in large razor files (minus the logged bug to move the divergence checker code off the UI thread). In the profile for the large document editing, these changes reduce allocated memory during RazorSyntaxTree.Parse by about 25%. CPU wise, the win isn't quite as dramatic, only a couple percent improvement under RazorSyntaxTree.Parse.
* Razor SDK build ordering issues
* Build the SDK completely regardless of the MSBuild runtime type
* Split SDK integration tests into a separate project. Clean up project file
* Add project to sln
* Update Microsoft.NET.Sdk.Razor.csproj
* Fixup tests
* Avoid rebuilding dependencies if they appear up to date. Fixup tests
* Fixup
* Update CSharp.Common.props
* Cleanup the build
* Workaround for DomException when invoking cache.put
Invoking cache.put could sometimes result in exceptions being thrown. While this seems to have been fixed in Chromium - https://bugs.chromium.org/p/chromium/issues/detail?id=968444,
we've had several reports of this in our repo. The fix here is to write defensively when working with the cache apis since they appear to behave in unexpected ways..
Fixes https://github.com/dotnet/aspnetcore/issues/20256
* Fixup
* Add mechanism where IR token generation can defer allocation of it's content.
It turns out that many IR tokens access their content, and thus allocating it is unnecessary. In particular, with this change against a large file, I've seen allocations under SyntaxNodeExtensions.GetContent reduced by about 33%. Performance wise, I've seen the number of CPU samples in the profile under GetContent reduce by about 40% (in my sample I typed 26 characters and there was about 600 ms less spent in GetContent)
* ContentGetter => ContentFactory
* Make tests happy with the switch from IntermediateToken to IntermediateTokenWithDeferreedContentAllocation
* IntermediateTokenWithDeferredContentAllocation => LazyIntermediateToken
Sourabh Shirhatti
Steve Sanderson
Artak
Hao Kung
Chris Ross
Pranav K
Safia Abdalla
Filip Staffa
John Luo
Doug Bunting
Stephen Halter
Justin Kotalik
N. Taylor Mullen
dotnet-maestro[bot]
ZeBobo5
David Melendez
Ken Dale
Dan Friedman
Adam Sitnik
James Newton-King
Luke Pfeiffer
Brennan
brianchance
Huei Feng
Todd Grunke
Pavel Voronin
Sébastien Ros
Scott Addie
William Godbe
Javier Calvarro Nelson
msftbot[bot]
David Fowler
Ryan Brandenburg