Temporarily fix VB App Framework Logging.

[KlausLoeffelmann]

The runtime PR dotnet/runtime#73087 broke the Visual Basic Application Framework Logging.

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

The original assumption that this would work was, 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.

After discussing this with the WinForms Team and the VB PM, we're fixing this temporary in the runtime, by returning false unconditionally for Logging.Log.HasBeenConfigured. This assumes, that the trace source has NOT been configured by a config file. Configuring by a config file remains a broken scenario for VB My.Logging, until we will be getting a fix from the Runtime.

Microsoft Reviewers: Open in CodeFlow

[Tanya-Solyanik]

CS applications don't need this switch, why not put it into the VB assembly?

[KlausLoeffelmann]

I wouldn't say this is language related?
It's not that the Application Framework can only be used by VB. So, for example, take a look at this:

https://stackoverflow.com/questions/59268557/where-is-the-winforms-application-framework-in-c-sharp-that-exists-in-vb-net

Also, I often saw even C# WPF apps using a few features from the VB App Framework to ease their life. It's a valid approach!

[Tanya-Solyanik]

Application that benefits from this quirk, references AppFramework, right? Why doesn't this quirk belong to Applicationframework then?

[Tanya-Solyanik]

I would had returned false here for the RC and would have worked on the proper fix, i.e. how to get if this was initialized from the config file.

[KlausLoeffelmann]

I thought about this first. But then I thought, there is a good chance it will stay like this, and then we could have it right away.

[Tanya-Solyanik]

there is a good chance it will stay like this,

Maybe runtime can add a protected property for us to look up?

[RussKie]

I don't quite understand the use cases, developer and user experiences. It would be great if you could provide more details explaining those. E.g., this is how a .NET Framework app worked, now ported to .NET 7 it'd work like this. Would a developer or use need to opt-in or opt-out?
Thank you

[KlausLoeffelmann]

I pretty much explained the breaking change in the runtime which led to this.
I added a few lines of explanation in the introduction, what we did.
This needs to go in quick, to unblock us.

[Tanya-Solyanik]

I would prefer returning a false unconditionally because:
1 quirks are public APIs and it will be difficult to remove them when we have the fix
2. if an application enables logging in the config file, it has also to define a quirk in json file, this is inconvenient
3. we had not exhausted possibilities of a correct fix,

[dreddy-work]

Squash merge please. Or enable auto-merge (that is squash default)

[Tanya-Solyanik]

Did you open a follow up bug to get this fixed?

[RussKie]

@KlausLoeffelmann is this a breaking change that we need to document?

[merriemcgaw]

@RussKie yeah, probably. It would be a minute number of customers impacted but it's good to document it of course.

[Tanya-Solyanik]

app config was not enabled in the previous versions, so this is a regression from .NET framework but not from the previous release of Core