[main] Update dependencies from dotnet/runtime

[dotnet-maestro]

This pull request updates the following dependencies

From https://github.com/dotnet/runtime

• Subscription: d9f5b309-084f-43b5-02de-08d8b80548e4
• Build: 20220814.6
• Date Produced: August 15, 2022 9:35:05 AM UTC
• Commit: e680411c22e33f45821f4ae64365a2970b2430a6
• Branch: refs/heads/main

• Updates:
  • Microsoft.Internal.Runtime.WindowsDesktop.Transport: from 7.0.0-rc.1.22410.1 to 7.0.0-rc.1.22414.6
  • Microsoft.NET.Sdk.IL: from 7.0.0-rc.1.22410.1 to 7.0.0-rc.1.22414.6
  • Microsoft.NETCore.App.Ref: from 7.0.0-rc.1.22410.1 to 7.0.0-rc.1.22414.6
  • Microsoft.NETCore.App.Runtime.win-x64: from 7.0.0-rc.1.22410.1 to 7.0.0-rc.1.22414.6
  • Microsoft.NETCore.ILAsm: from 7.0.0-rc.1.22410.1 to 7.0.0-rc.1.22414.6
  • Microsoft.NETCore.ILDAsm: from 7.0.0-rc.1.22410.1 to 7.0.0-rc.1.22414.6
  • Microsoft.NETCore.Platforms: from 7.0.0-rc.1.22410.1 to 7.0.0-rc.1.22414.6
  • Microsoft.Win32.Registry.AccessControl: from 7.0.0-rc.1.22410.1 to 7.0.0-rc.1.22414.6
  • Microsoft.Win32.SystemEvents: from 7.0.0-rc.1.22410.1 to 7.0.0-rc.1.22414.6
  • Microsoft.Windows.Compatibility: from 7.0.0-rc.1.22410.1 to 7.0.0-rc.1.22414.6
  • runtime.win-x64.Microsoft.NETCore.ILAsm: from 7.0.0-rc.1.22410.1 to 7.0.0-rc.1.22414.6
  • runtime.win-x86.Microsoft.NETCore.ILAsm: from 7.0.0-rc.1.22410.1 to 7.0.0-rc.1.22414.6
  • System.CodeDom: from 7.0.0-rc.1.22410.1 to 7.0.0-rc.1.22414.6
  • System.Configuration.ConfigurationManager: from 7.0.0-rc.1.22410.1 to 7.0.0-rc.1.22414.6
  • System.Diagnostics.EventLog: from 7.0.0-rc.1.22410.1 to 7.0.0-rc.1.22414.6
  • System.Diagnostics.PerformanceCounter: from 7.0.0-rc.1.22410.1 to 7.0.0-rc.1.22414.6
  • System.DirectoryServices: from 7.0.0-rc.1.22410.1 to 7.0.0-rc.1.22414.6
  • System.Drawing.Common: from 7.0.0-rc.1.22410.1 to 7.0.0-rc.1.22414.6
  • System.IO.Packaging: from 7.0.0-rc.1.22410.1 to 7.0.0-rc.1.22414.6
  • System.Reflection.MetadataLoadContext: from 7.0.0-rc.1.22410.1 to 7.0.0-rc.1.22414.6
  • System.Resources.Extensions: from 7.0.0-rc.1.22410.1 to 7.0.0-rc.1.22414.6
  • System.Security.Cryptography.Pkcs: from 7.0.0-rc.1.22410.1 to 7.0.0-rc.1.22414.6
  • System.Security.Cryptography.ProtectedData: from 7.0.0-rc.1.22410.1 to 7.0.0-rc.1.22414.6
  • System.Security.Cryptography.Xml: from 7.0.0-rc.1.22410.1 to 7.0.0-rc.1.22414.6
  • System.Security.Permissions: from 7.0.0-rc.1.22410.1 to 7.0.0-rc.1.22414.6
  • System.Text.Encodings.Web: from 7.0.0-rc.1.22410.1 to 7.0.0-rc.1.22414.6
  • System.Text.Json: from 7.0.0-rc.1.22410.1 to 7.0.0-rc.1.22414.6
  • System.Threading.AccessControl: from 7.0.0-rc.1.22410.1 to 7.0.0-rc.1.22414.6
  • System.Windows.Extensions: from 7.0.0-rc.1.22410.1 to 7.0.0-rc.1.22414.6
  • VS.Redist.Common.NetCore.SharedFramework.x64.7.0: from 7.0.0-rc.1.22410.1 to 7.0.0-rc.1.22414.6

Microsoft Reviewers: Open in CodeFlow

[ghost]

Go, you big red fire engine!

[RussKie]

It is building on the CI as well, but looks like a VB related test Microsoft.VisualBasic.Logging.Tests.LogTests.Write is failing:

Error message
System.NullReferenceException : Object reference not set to an instance of an object.


Stack trace
   at Microsoft.VisualBasic.Logging.Tests.LogTests.Write() in /_/src/Microsoft.VisualBasic/tests/UnitTests/Microsoft/VisualBasic/Logging/LogTests.cs:line 24
   at System.RuntimeMethodHandle.InvokeMethod(Object target, Void** arguments, Signature sig, Boolean isConstructor)
   at System.Reflection.MethodInvoker.Invoke(Object obj, IntPtr* args, BindingFlags invokeAttr)

[Tanya-Solyanik]

@steveharter , it seems that winforms test failure is related to dotnet/runtime#73087 - if TraceSource is initialized from the config file, it does not initialize the default file listener, and test expects the default listener to be initialized. I suspect winforms should come up with a different way to detect initialization from a config fie, could you please suggest one?

[KlausLoeffelmann]

@steveharter, @Tanya-Solyanik:
To be more precise, it is something in the Application Framework for/in Visual Basic, that's causing this, because it does an assumption, which I frankly don't understand:

https://source.dot.net/#Microsoft.VisualBasic.Forms/Microsoft/VisualBasic/Logging/Log.vb,170

This assumption is that when GetSupportedAttributes gets called in a class derived from TraceSource that then would tell that the trace source was configured from a config file. This is not only what DefaultTraceSource does, it seems to be the only reason for it existence. Now, as far as I understand it, after the change, GetSupportAttributes gets called unconditionally, so HasBeenConfigured in the VB AppFramework's DefaultTraceSource returns always true, and so a FileLogTraceListener gets never added, since the Log class assumes, the trace source was configured by a config file. And that's why there will never be a value other than nothing for the DefaultFileLogWriter property.

Now, what I don't understand: Why would (previously) GetSupportedAttributes only have been called, when the trace source was configured by a config file?

[dreddy-work]

/azp run

[azure-pipelines]

Azure Pipelines successfully started running 2 pipeline(s).