The fix for this is to use more ExceptionDispatchInfo! Basically
everwhere that we handle an exception is now an EDI. It's easy to pass
these around and they do the right thing as far as perserving the stack
in.
I de-factored this code a little bit to make all of this work, but it's
now pretty unambiguously correct upon inspection.
I started out wanting to get rid of the continue-with because we've
found that pretty error prone overall. However making this method
async-void started to ask more questions than it answered. What happens
if serialization of the exception fails?
\n\nCommit migrated from 0a27fd3ad6
- Also moved the fetching of ANY HTTP header fields until AFTER the most stringent
- Check to see if logging is on (thus deferring work if the logger is sampling).
- Added transfer of TraceState from http header to Activity
- Added tests to insure that we were reading traceparent and tracestate headers as expected.
This resolves the issue blocking use of component parameters from our
ref assemblies. Making properties public with private get is our
recommended guidance for wanting documentation to work in the IDE.
We also now need to manually generate the ref-assembly types for these
so they will show up for tooling with setters. I've logged an issue to
track whether we want to keep this long term, it seems like a suitable
workaround for now.
* Move to BYOC queues
- aspnet/AspNetCore-Internal#2033
- use conditions matching aspnet/Extensions and dotnet/Arcade
- e.g. 05cb24592a/azure-pipelines.yml (L49-L54)
- install necessary Build Tools for Visual Studio 2019 components and workloads on CI
- revert part of 85ae18c723 because multiple editions of VS 2019 are now publicly available
- that is, restore support for multiple editions in InstallVisualStudio.ps1
- update InstallVisualStudio.ps1 to
- support BuildTools edition of VS 2019
nit: merge a couple of Windows build steps
- support automatically updating latest version of a VS edition on the machine
- include `-Quiet` option for a completely non-interactive installation
* Install SQL Server 2017 Express LocalDB in Windows test job
* Drop back to SQL Server 2016 Express LocalDB
* Instead: Install SQL Server 2017 Express LocalDB and its cumulative update
* Don't move Microsoft.AspNetCore.Blazor.Templates.dll into output directory
- assembly is not of interest and should not be signed
* Revert most of "Don't move Microsoft.AspNetCore.Blazor.Templates.dll into output directory"
- didn't help odd attempt to sign this file and it was only a warning
This reverts commit b55d69c370.
* Back to using SQL Server 2016 Express LocalDB again
- installing cumulative update was taking extra time and not reliably updating the LocalDB install
- reverts part of 70d8d125f9, leaving direct download and some reordering
* Do not assume vsjitdebuger.exe exists
- component is not available in BuildTools edition of VS
- installing cumulative update was taking extra time and not reliably updating the LocalDB install
- reverts part of 70d8d125f9, leaving direct download and some reordering
- aspnet/AspNetCore-Internal#2033
- use conditions matching aspnet/Extensions and dotnet/Arcade
- e.g. 05cb24592a/azure-pipelines.yml (L49-L54)
- install necessary Build Tools for Visual Studio 2019 components and workloads on CI
- revert part of 85ae18c723 because multiple editions of VS 2019 are now publicly available
- that is, restore support for multiple editions in InstallVisualStudio.ps1
- update InstallVisualStudio.ps1 to
- support BuildTools edition of VS 2019
nit: merge a couple of Windows build steps
- support automatically updating latest version of a VS edition on the machine
- include `-Quiet` option for a completely non-interactive installation
* Better support for _Imports.razor
* Special case component imports when generating code
* Prevent a future VS crash
* Rebased and updated
* update
* Removed unnecessary newline
\n\nCommit migrated from abbfe00bdc
- When adding additional C# 8 tests found that we didn't fully support this.
- Updated the C# 8.0 test to fully encompass everything C# 8.0.
- Added a feature flag to control using variable declaration errors when not top level.
- Added using variable declaration specific tests.
aspnet/AspNetCoredotnet/aspnetcore-tooling#5092
\n\nCommit migrated from ac08ad3659
Updates the bindtaghelperdescriptorprovider to use the changed event property type name on the bound attribute instead of the value property type attribute.\n\nCommit migrated from 3009045206
- Expanded the `ProjectWorkspaceStateGenerator` to extract the C# language version when building the `ProjectWorkspaceState`. This approach enables all platforms to get nullability support without any changes (as long as they support `ProjectWorkspaceState`, which they do). Also, Roslyn suggested that we avoid dealing with LangVersion directly because there are several factors that impact its "effective" value on a project when run in tooling.
- Updated the `LinePragma` code generation to include `#nullable restore` and `#nullable disable` lines to allow for project restored nullability state for user code.
- Added a new `RazorProjectEngineBuilderExtensions` class that adds Roslyn specific project engine modifications. In this case it allows us to set the C# language version for a project engine and configure underlying features accordingly.
- Added a `SuppressNullabilityEnforcement` flag that only turns on if C# < 8 is specified.
- Updated LiveShare, VS4Mac and RazorGenerate to understand CSharpLanguageVersion.
- Added a single test output to show the change.
dotnet/aspnetcore-tooling#5092
\n\nCommit migrated from 1df8128b87
Chris Ross
Mikael Mengistu
Stephen Halter
Daniel Marbach
Ryan Nowak
Steve Sanderson
Vance Morrison
Doug Bunting
Doug Bunting
Adrian Wright
Ryan Nowak
Ryan Brandenburg
Ajay Bhargav Baaskaran
Pranav K
John Luo
谭九鼎
Justin Kotalik
dotnet-maestro[bot]
Javier Calvarro Nelson
N. Taylor Mullen
Hao Kung