Merged
Conversation
No reason it can't just be with the other integration-test-only fault handlers.
There's a few things this piece of code is trying to do: 1. If we have an aggregate exception, try to update the bucket parameters to represent the stuff inside. Rather than doing that it's much easier to just do a report for each inner exception, which will not interfere with other targeted notification policies. 2. If we have a remote exception, try to bucket on some other information. What I don't get is the information there is the stack trace (which is the client stack trace) and the message which we'd already include anyways -- nothing there is any more actionable than just falling into the default error reporting logic. 3. Trying to report inner exceptions over the outer exception if ever one exists. I can't say that's a great idea unless we actually know the type of exception more directly. Just deleting this all seems much easier.
This brings updated support for collecting heaps when faults happen. We use the VS-shipped version in-proc and our ServiceHub process that runs on .NET Framework, but we still need to upgrade this for .NET Core-based ServiceHub processes.
Simplify fault reporting
It appears that some dependency of our MSBuild.UnitTests.csproj project is bringing in 5.0.0 of System.Drawing.Common, while the 6.0 SDK is referencing binaries that reference 6.0.0 of System.Drawing.Common, without carrying a proper reference to the 6.0.0 NuGet package. MSBuild can't resolve that, but adding an explicit reference to 6.0.0 of System.Drawing.Common fixes that. Upgrading to System.Drawing.Common then causes the platform analyzers to realize that we're calling a Windows-only API on a cross-platform DLL. We use HasValidFonts to work around a bug in some of our old CI infrastructure, but the only place it's already used is already restricted to Windows only, so we can just duplicate that check to make everything happy again.
Collaborator
Author
|
⚠ This PR has merge conflicts. @Cosifne |
…t error if struct has field initializers but no constructors (#58581)
Upgrade Microsoft.VisualStudio.Telemetry to 16.4.22
Reduce the number of duplicate ProjectId instances found in OOP
…dicatorMarginByDefault Set the default value of Combine With Indicator Margin to false
This file contains hidden or bidirectional Unicode text that may be interpreted or compiled differently than what appears below. To review, open the file in an editor that reveals hidden Unicode characters.
Learn more about bidirectional Unicode characters
Sign up for free
to join this conversation on GitHub.
Already have an account?
Sign in to comment
7 participants
Add this suggestion to a batch that can be applied as a single commit.This suggestion is invalid because no changes were made to the code.Suggestions cannot be applied while the pull request is closed.Suggestions cannot be applied while viewing a subset of changes.Only one suggestion per line can be applied in a batch.Add this suggestion to a batch that can be applied as a single commit.Applying suggestions on deleted lines is not supported.You must change the existing code in this line in order to create a valid suggestion.Outdated suggestions cannot be applied.This suggestion has been applied or marked resolved.Suggestions cannot be applied from pending reviews.Suggestions cannot be applied on multi-line comments.Suggestions cannot be applied while the pull request is queued to merge.Suggestion cannot be applied right now. Please check back later.
This is an automatically generated pull request from release/dev17.1 into main.
Once all conflicts are resolved and all the tests pass, you are free to merge the pull request. 🐯
Troubleshooting conflicts
Identify authors of changes which introduced merge conflicts
Scroll to the bottom, then for each file containing conflicts copy its path into the following searches:
Usually the most recent change to a file between the two branches is considered to have introduced the conflicts, but sometimes it will be necessary to look for the conflicting lines and check the blame in each branch. Generally the author whose change introduced the conflicts should pull down this PR, fix the conflicts locally, then push up a commit resolving the conflicts.
Resolve merge conflicts using your local repo
Sometimes merge conflicts may be present on GitHub but merging locally will work without conflicts. This is due to differences between the merge algorithm used in local git versus the one used by GitHub.
git fetch --all git checkout -t upstream/merges/release/dev17.1-to-main git reset --hard upstream/main git merge upstream/release/dev17.1 # Fix merge conflicts git commit git push upstream merges/release/dev17.1-to-main --force